Как сопоставить субдомены с несколькими контейнерами докеров (как веб-серверы), размещенные с использованием эластичного бин-стека на AWS

Question

Я видел пример использования сервера nginx и php-сервера, работающего на отдельных контейнерах докеров в экземпляре.

Я хочу использовать эту инфраструктуру для размещения нескольких контейнеров докеров (каждый из которых является собственным веб-сервером на другом уникальном порту).

Каждое из этих уникальных веб-приложений должно быть доступно в Интернете с уникальным субдоменом.

Поскольку одного экземпляра будет недостаточно для всех контейнеров Docker, я буду нуждаться в них для распространения по нескольким экземплярам.

Как можно разместить сотни контейнеров докеров в нескольких экземплярах, в то время как один контейнер nginx-proxy выполняет маршрутизацию для сопоставления субдомена с каждым контейнером веб-приложения с использованием уникального порта?

E.g. 

app1.mydomain.com --> docker container exposing port 10001 
app2.mydomain.com --> docker container exposing port 10002 
app3.mydomain.com --> docker container exposing port 10003 
.... 
... 

Если я использую Nginx прокси контейнер, можно было бы легко отобразить каждый номер порта на другой подобласти. Это справедливо для всех контейнеров Docker в том же экземпляре, что и контейнер nginx-proxy.

Но могу ли я сопоставить его с контейнерами докеров, которые размещены на другом экземпляре. Я планирую использовать эластичный beanstalk для создания новых экземпляров для дополнительных контейнеров докеров.

Теперь nginx работает на одном экземпляре, в то время как есть контейнеры в разных экземплярах.

Как достичь конечной цели сотен веб-приложений, размещенных на отдельных контейнерах докеров, сопоставленных уникальным субдоменам?

Answer 1

Чтобы быть честным, вы не совсем поняли мне вопрос. Кажется, вы можете развернуть контейнер Nginx в каждом экземпляре, имеющий конфигурацию прокси для каждого контейнера приложения, который у вас на нем, и по мере того, как кластер масштабируется, все они также будут иметь Nginx. Таким образом, вы можете просто установить ELB поверх него (Elastic Beanstalk поддерживает его изначально), и вам будет хорошо.

Тем не менее, я думаю, вы намерены сильно подтолкнуть эластичный бобовый штангу. Я имею в виду, он не должен использоваться таким образом, как большой и общий кластер Docker. Эластичный Beanstalk был создан для облегчения развертывания приложений, и в настоящее время контейнеры являются лишь одной из доступных, допустим, платформ (хотя это не язык или рамки, конечно) для людей, чтобы это делать. Но Elastic Beanstalk не является менеджером контейнеров.

Итак, на мой взгляд, имеет смысл развернуть один контейнер в приложении Beanstalk с помощью ELB поверх него, поэтому вам не нужно беспокоиться об основных машинах и их IP-адресах. Таким образом, вы можете легко настроить сторонний прокси для маршрутизации запросов, потому что у вас есть постоянный адрес для пула приложений. И будучи независимыми пулами, они могут масштабироваться независимо и так далее.

Есть несколько более сложных решений, которые пытаются решить эту проблему развертывания контейнеров в широком одном кластере, например Google's Kubernetes, и отслеживать их и предоставлять конечные точки для каждой группы приложений. Кроме того, есть решения для динамических обратных прокси, таких как this one, недавно выпущенных, и, вероятно, множество других решений появляются каждый день, но все они потребуют большой настройки. Но в этом случае мы не говорим о решении AWS.