Хочу ли я, чтобы контейнер обрабатывал несколько запросов?
Этот вопрос относится не к сети или хостингу, а к тому, как я создаю свое приложение: если я настраиваю контейнер docker в качестве веб-узла PHP, правильно ли я настраиваю его таким образом, чтобы он мог обрабатывать несколько подключений?
В качестве альтернативы, было бы лучше настроить его таким образом, чтобы он обрабатывал запросы по одному за раз, а затем, если я хочу обрабатывать больше подключений одновременно, запускать несколько экземпляров одного и того же изображения?
3 answers
Контейнер Docker обычно предназначен для запуска одного (логического) приложения и ограничения ресурсов, используемых этим приложением (память, дисковый ввод-вывод, пропускная способность сети и т.д.). Это не обязательно означает запуск одного процесса; у него могут быть вспомогательные функции, такие как монитор процессов, но в целом контейнер PHP будет запускать только интерпретатор PHP. И это приведет к запуску нескольких копий самого себя.
Как мы знаем, nginx и php-fpm оба прекрасно способны передавать несколько одновременных запросов, вплоть до доступных ограничений ресурсов. Таким образом, один контейнер может обслуживать несколько запросов. То же самое может сделать Apache с mod_php, хотя в этом случае PHP встроен в Apache и ограничивает возможности Apache. Таким образом, вы вполне можете захотеть разделить веб-сервер и PHP на отдельные (связанные) контейнеры в любом случае.
Итак, что произойдет, так это то, что в конечном итоге вы получите достаточно трафика, чтобы один контейнер не мог обработать все это достаточно быстро или вообще. В этот момент вы будете либо вы хотите увеличить контейнер, либо запустить новый. Как правило, nginx может обрабатывать тысячи одновременных запросов, а PHP может обрабатывать десятки (это приблизительные цифры). Таким образом, в масштабе у вас может быть 800 контейнеров PHP, обслуживаемых четырьмя контейнерами nginx, с двумя контейнерами балансировщика нагрузки haproxy перед ними, все обрабатывающие от 10 000 до 40 000 запросов в секунду.
Однако все эти 800 PHP-контейнеров не обязательно будут находиться на 800 хостах. Это может быть так, если вы используя, скажем, экземпляры t2.small AWS, где вы просто заставите контейнер использовать все ресурсы виртуальной машины, но если ОН будет развернут на голом металле, у которого обычно гораздо больше ресурсов, чем у одной виртуальной машины, у вас почти наверняка будет несколько контейнеров на этом хосте, чтобы использовать все его ресурсы. PHP, как правило, привязан к процессору, поэтому ОН также может запускать ваши контейнеры бок о бок с совершенно не связанными контейнерами, которые не используют много процессора, но, например, используют много оперативной памяти или диска.
Все это это означает, что да, ваш отдельный контейнер может и будет обрабатывать несколько одновременных запросов, и ваша программа должна знать, что это происходит. Обычно это не проблема, но это означает, что вам следует избегать проблем, которые могут вызвать разногласия, таких как блокировка базы данных, или все ваши контейнеры могут резко остановиться.
Во-первых, пожалуйста, взгляните на docker.io и учебник - важно иметь четкое представление о том, как это предполагается использовать, прежде чем приступать к решению конкретных архитектурных проблем.
Теперь, в мире PHP, у вас был бы Apache с mod_php (или nginx/php_fpm или другим), запущенный в вашем контейнере. Этот контейнер будет обслуживать все входящие запросы.
Если вам нужно сбалансировать нагрузку вашего приложения, то у вас будет другой контейнер (вероятно, на другом хосте) с обратным прокси-сервером (например, HAProxy), который обработает это для вас. Вы также можете настроить DNS для циклического обмена данными между экземплярами вашего веб-сервера с помощью HAProxy или без него.
Если вы считаете контейнер похожим на процесс, это будет соответствующим образом определять ваш выбор.
Следуя рекомендациям по лучшей практике "одно приложение в контейнер", это будет процессом, хотя и с определенными присоединенными пространствами имен, chroot-ed, в определенных контрольных группах.