Как заменить контейнер балансировки нагрузки Docker без простоев простым способом

Question

Я использую около 30 различных сайтов на одном хосте, каждый из которых управляется с помощью docker -compose. Некоторые из них используют Nginx, некоторые используют Apache. Затем есть контейнер обратного прокси, доступный для inte rnet, который работает Nginx, имеет кучу vhosts и перенаправит трафик c в нужный контейнер. Эти 30 разных сайтов - это просто я пробую разные идеи, и у них не так много клиентов.

Я знаю, что использование docker -compose неразумно для производственного использования, потому что отключение и выключение Контейнер снова включается с использованием новой версии по-прежнему занимает время (<3 секунд). Я знаю о docker Swarm и K8S, которые я буду использовать, если какой-либо из этих 30 различных сайтов станет достаточно большим. К этому моменту я, вероятно, реструктурирую все, чтобы добиться развертывания без простоев. Но то, что я спрашиваю, отличается. </p>

Я хочу по-прежнему управлять обычными контейнерами, используя docker compose, потому что это очень удобно и потому, что у меня только 1 узел, поэтому запуск K8S будет излишним и бесполезным на самом деле нет нулевого времени простоя развертывания. Тем не менее, я хочу время от времени заменять контейнер обратного прокси-сервера (может быть 1-3 раза в неделю), и я не хочу иметь простоев с этим единственным контейнером, потому что будут затронуты все эти 30 сайтов. Я могу принять время простоя <3 секунд для отдельных сайтов, потому что большинство сайтов вообще не меняются, а те, которые работают, являются экспериментальными, но я начинаю чувствовать себя некомфортно, имея время простоя <3 секунд для обратного прокси-сервера. </p>

Так есть ли способ заменить контейнер обратного прокси без простоя? Что-то действительно простое и легкое? Не обязательно использовать docker compose, но все равно следует использовать контейнеры в целом. Я рассматриваю следующее:

• Используйте KIND (Kubernetes IN Docker), который работает на одном хосте и создает контейнеры, чтобы они выглядели как узлы. Это занимает 800 МБ-1 ГБ ОЗУ, поэтому нежелательно
• Держать контейнер обратного прокси на неопределенное время, изменять его конфиги, перезапускать Nginx (время простоя <1 секунды), но это серьезно нарушает назначение контейнеров и я не могу больше не заботиться о контейнерах, и это первая причина, по которой я хочу контейнировать приложения. </li>

Есть ли другие варианты?

Answer 1

Используйте Kubernetes. Даже на одном узле он предназначен для решения большинства этих проблем за вас, и когда вы захотите перейти на несколько хостов, 99% будут готовы. Кривая обучения будет, но она того стоит.

Я бы порекомендовал использовать управляемый сервис ( DigitalOcean , EKS , GKE , AKS ), но кластер с одним узлом, который включает в себя управление, можно быстро настроить с помощью microk8s .

Конфигурации docker compose можно легко перенести с помощью kompose .

A Контроллер входа Kubernetes , обычно nginx заменит функциональность обратного прокси-сервера и редко требует замены, за исключением обновлений. Входная конфигурация автоматическая c из входных определений . В редком случае обновления Kubernetes может управлять им без простоев, если настроен на. Входной контроллер - это просто еще одно развертывание.

Answer 2

Я закончил тем, что разместил другой балансировщик нагрузки (назовите его A) перед 2 копиями (назовите их B и C) текущего балансировщика нагрузки. Предполагая, что у A никогда нет времени простоя и его не нужно обновлять, я могу обновить B (в то время как traffi c будет go до A, а затем C затем приложение), затем я могу обновить C (между тем, traffi c будет go до A, затем B, затем приложение). Я знаю, что Deployments и ReplicaSets в K8S делают именно это, но использование K8S все еще не может быть оправдано в моей ситуации, потому что это сложно и тяжело.

Для всех, кто читает это, я все еще рекомендую использовать K8S, потому что K8S является le git и поможет вам безболезненно управлять своими сайтами.