Этот вопрос относится не к сети или хостингу, а к тому, как я спроектирую свое приложение: если я настраиваю докер-контейнер как веб-узел PHP, это правильное соглашение, которое я настроил бы так, чтобы он мог обрабатывать несколько соединений ?
В качестве альтернативы, было бы лучше настроить его так, чтобы он обрабатывал запросы по одному, а затем, если я хочу обрабатывать больше соединений одновременно, раскрутить несколько экземпляров одного и того же изображения?
Контейнер Docker обычно предназначен для запуска одного (логического) приложения и ограничения ресурсов, которые это приложение использует (память, дисковый ввод-вывод, пропускная способность сети и т. Д.). Это не обязательно означает запуск одного процесса; у него могут быть вспомогательные вещи, такие как монитор процесса, но в целом контейнер PHP будет запускать только интерпретатор PHP. И это будет запускать несколько копий себя.
Как мы знаем, nginx и php-fpm отлично способны обрабатывать несколько одновременных запросов, вплоть до доступных ограничений ресурсов. Таким образом, один контейнер может обслуживать несколько запросов. Так может Apache с mod_php, хотя в этом случае PHP встроен в Apache и ограничивает возможности Apache. Так что вы все равно можете разделить веб-сервер и PHP на отдельные (связанные) контейнеры.
Так что в итоге вы получите достаточно трафика, чтобы один контейнер не смог справиться со всем достаточно быстро или вообще. В этот момент вы либо захотите увеличить контейнер, либо запустите новый. Как правило, nginx может обрабатывать тысячи одновременных запросов, а PHP может обрабатывать десятки (это приблизительные цифры). Таким образом, в масштабе у вас может быть 800 контейнеров PHP, обслуживаемых четырьмя контейнерами nginx, с двумя контейнерами балансировки нагрузки haproxy перед ними, все из которых обрабатывают от 10000 до пиковых 40000 запросов в секунду.
Все эти 800 контейнеров PHP не обязательно будут на 800 хостах. Это может быть в том случае, если вы используете, скажем, t2.small экземпляры AWS, где у вас просто будет контейнер использовать все ресурсы виртуальной машины, но если ИТ развертывается на голое железо, которое обычно имеет гораздо больше ресурсов, чем один ВМ, вы почти наверняка будете иметь несколько контейнеров на этом хосте, чтобы использовать все его ресурсы. PHP, как правило, привязан к процессору, поэтому ИТ-отдел может также запускать ваши контейнеры бок о бок с совершенно не связанными контейнерами, которые не используют много ЦП, но используют, например, много оперативной памяти или диска.
То есть, да, ваш единственный контейнер может обрабатывать несколько одновременных запросов, и ваша программа должна знать, что это происходит. Обычно это не проблема, но это означает, что вам следует избегать проблем, которые могут привести к конфликтам, таким как блокировка базы данных или все Ваши контейнеры могут перевернуться.
Во-первых, пожалуйста, посмотрите на docker.io и руководство — важно иметь четкое представление о том, как это предполагается использовать, прежде чем приступать к решению конкретных архитектурных задач.
Теперь в мире PHP у вас будет Apache с mod_php (или nginx / php_fpm, или другим), работающим в вашем контейнере. Этот контейнер будет обслуживать все входящие запросы.
Если вам нужно сбалансировать нагрузку на ваше приложение, то у вас будет другой контейнер (вероятно, на другом хосте) с обратным прокси-сервером (например, HAProxy), который будет обрабатывать это для вас. Вы также можете настроить DNS для циклического перебора между экземплярами веб-сервера с HAProxy или без него.
Если вы думаете, что контейнер похож на процесс, это поможет вам сделать правильный выбор.
Следуя рекомендациям «одного приложения в контейнер», будут быть процессом, хотя и с определенными присоединенными пространствами имен, chroot-ed, в определенных контрольных группах.