Автоматическое развертывание докеризованного приложения на одной машине

Question

У меня есть веб-приложение, состоящее из нескольких сервисов - веб, БД и очередь заданий / работник. Я размещаю все на одной виртуальной машине Google, и мой процесс развертывания очень прост и наивен:

• Я вручную устанавливаю все сервисы, такие как база данных на ВМ
• сценарий bash, запланированный crontab, опрашивает удаленный git-репозиторий на предмет изменений каждые N минут
• если бы произошли изменения, он просто перезапустил бы все службы, используя supervisord (очередь заданий, сеть и т. Д.)

Теперь я начинаю новый веб-проект, где мне нравится использовать docker-compose для локальной разработки. Тем не менее, я, кажется, впадаю в паралич анализа, выбирая доступные варианты развертывания производства - я смотрел на Kubernetes, Swarm, docker-compose, контейнерные реестры и т. Д.

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

Интересно, является ли docker-compose разумным выбором для простого веб-приложения. Люди используют его в производстве и если да, то как выглядит весь процесс, начиная с пустой виртуальной машины и заканчивая обновлением приложения? Используют ли люди Kubernetes или Swarm для простого развертывания на одной машине или это избыточное убийство?

Answer 1

Многие компании, с которыми я работал, смещают всю производственную среду в сторону Kubernetes. Это имеет смысл, потому что все облачные провайдеры в настоящее время подталкивают Kubernetes, и мы можем быть весьма уверены в том, что Kubernetes - это будущее облачного развертывания. Если ваше приложение предназначено для работы в каком-либо частном или общедоступном облаке, я бы лично выбрал Kubernetes в качестве операционной платформы для него. Если вы планируете добавить дополнительные сервисы, вы сможете легко подключить их и масштабировать свою инфраструктуру с ростом числа запросов к вашему приложению. Однако, если вы уже знаете, что не рассчитываете масштабировать свое приложение, оно может оказаться слишком мощным для использования кластера Kubernetes для его запуска, хотя Google Cloud и т. Д. Позволяют довольно просто настроить такой кластер с помощью нескольких щелчков мыши.

Что касается автоматизированного рабочего процесса разработки для Kubernetes, вы можете взглянуть на мой ответ на этот вопрос: Как наилучшим образом использовать Kubernetes / minikube DNS для локальной разработки

Answer 2

Интересно, является ли docker-compose разумным выбором для простого веб-приложения.

Может быть, конечно, если время разработки лучше всего потратить на веб-приложение, а меньше на не связанные с вебом материалы, такие как очередь заданий и база данных. Другая звездочка - нормально ли работает среда разработки с горячими перезагрузками или переадресацией портов и тому подобным джазом. Я говорю, что это разумный выбор, потому что 99% работы создания приложения, подходящего для использования в кластерной среде, - это работа по контейнеризации приложения. Так что, если приложение уже работает под docker-compose, то с большой вероятностью вы можете взять образ докера, созданный от имени docker-compose, и развернуть его в кластер.

Люди используют это в производстве

Я надеюсь, что нет; Я уверен, что есть люди, которые используют docker-compose для запуска в работе, точно так же, как есть люди, которые используют пакетные файлы Windows для развертывания, но не быть этим человеком.

Используют ли люди Kubernetes или Swarm для простого развертывания на одной машине или это избыточное убийство?

Точно так же не будьте человеком, который развертывает все приложение на одной виртуальной машине, и не будьте морально готовы к тому, что одна попытка уничтожить все, что вы цените. Это часть того, для чего предназначены технологии кластеризации: одна ошибка, которая сводит на нет все приложение, веб, очереди и постоянство - одним махом.

Теперь, является ли развертывание kubernetes для вашей ситуации "избыточным" или нет, зависит от того, получаете ли вы выгоду от других вещей, которые kubernetes приносит помимо простого масштабирования. Мы получаем выгоду от расширения прав и возможностей разработчиков, агрегации журналов, ограничений ЦП и ресурсов, возможности снятия одного узла без какой-либо драмы, управления секретами, управления конфигурацией, использования небольшого количества узлов для большого количества размещенных приложений (в отличие от создания одна виртуальная машина на каждое развернутое приложение, потому что развертывания не имеют дисциплины в отношении размещения файла конфигурации или портов или чего-либо еще). Я могу продолжать, потому что Кубернетес действительно волшебен; но, как отмечают многие, успешное управление кластером - это не ноль человеческих затрат.