Поиск по сайту:

3 стратегии автоматизированного производственного развертывания с помощью Docker

Docker — популярный инструмент разработки, поскольку он упрощает запуск изолированных экземпляров вашего приложения с воспроизводимой конфигурацией. Его также можно использовать в рабочей среде, где он гарантирует, что живые развертывания идентичны вашей среде разработки.

Запустить контейнер в производство не всегда так просто, как запустить docker run на локальном компьютере. Не рекомендуется вручную загружать образы в реестр, подключаться к удаленному хосту Docker и запускать свои контейнеры. Это зависит от вмешательства человека, поэтому требует много времени и подвержено ошибкам.

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

1. Docker Compose через SSH

Docker Compose позволяет запускать несколько контейнеров с помощью одной команды. Более того, Compose настраивается через файл YAML, который помогает вам изменять версии и гарантировать воспроизводимое развертывание.

Возможно, вы уже использовали Compose в качестве локального инструмента разработки. Вам нужно создать файл docker-compose.yml в рабочем каталоге, а затем добавить один или несколько services, определяющих запускаемые контейнеры:

version: 3
services:
  app:
    image: example.com/app:latest
    ports:
      - 80:80
  database:
    image: mysql:8.0
    expose:
      - 3306

Получив файл Compose, используйте команду docker-compose up -d для запуска ваших контейнеров. Если вы изменили файл, повторите команду, чтобы применить изменения. Compose обновит или заменит контейнеры для достижения нового заявленного состояния.

Добавление флага --pull указывает Compose попытаться загрузить обновленные изображения перед запуском контейнеров. Вы также можете использовать --force-recreate для принудительного создания новых контейнеров, даже если их базовая конфигурация не изменилась.

Как все это связано с производственными развертываниями? Это означает, что вы можете использовать Compose как часть конвейера непрерывной интеграции, чтобы легко запускать контейнеры, соответствующие состоянию, которое вы указали в файле docker-compose.yml. Запуск docker-compose up -d --pull в каждом конвейере даст вам набор контейнеров, каждый из которых запускает последнюю версию своего образа.

Есть несколько способов реализовать этот метод. Самый простой и безопасный способ — установить Docker и Compose на рабочем хосте, а затем подключиться к нему через SSH. Вам нужно будет использовать настройки вашего поставщика CI для хранения учетных данных SSH в виде переменных, доступных для вашего конвейера. Затем вы настроите клиент SSH в своем конвейере, скопируете файл docker-compose.yml на удаленный хост и выполните команду  docker-compose up.

Вот пример сценария:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo $SSH_PRIVATE_KEY | ssh-add -
echo $SSH_HOST_KEY > ~/.ssh/known_hosts
scp docker-compose.yml:ci-user@example.com:/home/ci-user/docker-compose.yml
ssh -t ci-user@example.com docker-compose up -d

В качестве альтернативы вы можете использовать контексты Docker для локального запуска двоичного файла Compose в среде вашего конвейера. Это потребует от вас открыть сокет Docker на удаленном хосте; поскольку это может быть угрозой безопасности, подход, как правило, менее благоприятен в ситуациях, когда также можно использовать SSH.

Следуя этому методу, вы должны установить Docker и Compose на хосте, на котором запущены ваши конвейеры. В сценарии конвейера вы должны зарегистрироваться и выбрать контекст Docker, который указывает на ваш удаленный производственный хост. Детали подключения должны быть предоставлены в виде переменных, установленных на панели настроек вашего поставщика CI. С выбранным контекстом вы запустите docker-compose up -d в среде вашего конвейера, но увидите, что команда выполняется на удаленном сервере.

2. Использование платформы как услуги (PaaS)

Внедрение предложения «Платформа как услуга» (PaaS) — это еще один подход к запуску контейнеров Docker в производственной среде. Вы можете самостоятельно разместить свои решения с помощью таких решений, как Dokku, или выбрать хостинговое предложение, такое как Amazon ECS, DigitalOcean App Platform или Heroku.

PaaS абстрагируется от сложности создания образов, поддержания подробных конфигураций и предоставления собственных хостов Docker. Вы либо используете Git, чтобы напрямую отправить свой репозиторий на платформу, либо запускаете команду CLI для загрузки своих изменений. PaaS обрабатывает создание контейнера из ваших исходных ресурсов, файлов Dockerfile или файла конфигурации для конкретной платформы.

Решения PaaS — отличный способ быстро выйти в интернет с минимальным практическим взаимодействием с Docker. Их легко интегрировать в ваш конвейер CI, и большинство крупных поставщиков предлагают образцы сценариев для начала работы. Однако PaaS можно перерасти, что может означать необходимость переосмысления вашей инфраструктуры в будущем.

Действия по автоматизации развертывания на выбранной вами платформе зависят от поставщика. Если вы используете Dokku или аналогичную PaaS с интеграцией Git, ваш CI-скрипт может состоять из двух строк:

git remote add dokku dokku@example.com:app-name
git push dokku master

Скрипт добавляет ваш сервер Dokku в качестве удаленного Git и загружает содержимое репозитория. Dokku автоматически создаст образ из вашего Dockerfile и запустит экземпляры контейнера. Чтобы это работало, вам нужно добавить открытый SSH-ключ вашего CI-сервера в Dokku; в противном случае ваш сценарий CI не сможет пройти аутентификацию на платформе.

3. Оркестровка с Kubernetes/Docker Swarm

Использование оркестратора, такого как Kubernetes или Docker Swarm, возможно, является наиболее распространенным способом запуска живых экземпляров контейнера. Эти инструменты специально созданы для развертывания и масштабирования контейнеров в производственных средах.

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

Kubernetes — самый популярный оркестратор. Одним из способов взаимодействия с кластерами Kubernetes является Kubectl, официальный инструмент управления CLI. Kubectl позволяет применять файлы манифеста в формате YAML, которые определяют ресурсы контейнера для создания в вашем кластере.

Вот простой манифест, который создает один экземпляр контейнера:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: example.com/image:latest

Вы можете использовать Kubectl для применения этого манифеста к кластеру:

kubectl apply -f manifest.yaml

Последующие изменения в файле применяются повторением команды. Kubernetes автоматически предпринимает необходимые действия для достижения нового заявленного состояния.

Это делает Kubernetes отличным вариантом для автоматизированного производственного развертывания. Вы можете использовать kubectl apply в своих пайплайнах, чтобы брать манифесты из своего репозитория и применять объявленное состояние к вашему кластеру. Создание нового тега изображения для каждой фиксации приведет к тому, что Kubernetes извлечет этот образ и запустит новые контейнеры для развертывания.

Чтобы настроить это, вам нужно указать содержимое файла конфигурации Kubeconfig в качестве переменной конвейера. Это дает Kubectl учетные данные для подключения к вашему кластеру. Затем локальный двоичный файл Kubectl будет работать с вашим удаленным кластером.

Docker Swarm — это еще один вариант оркестровки, интегрированный с Docker. Вы можете настроить стек Swarm, используя тот же файл docker-compose.yml, как описано ранее. Затем можно использовать аналогичные подходы к развертыванию: либо подключение к хосту Swarm через SSH, либо использование контекста Docker для изменения цели локальных двоичных файлов Docker.

Оркестраторы намного сложнее, чем использование простого Compose или управляемой PaaS. В случае с Kubernetes вам необходимо изучить новые абстракции, терминологию и форматы файлов конфигурации, прежде чем вы сможете развернуть свои контейнеры. Однако кластеры также предоставляют дополнительные возможности, упрощающие обслуживание приложений в долгосрочной перспективе. Вы можете легко масштабировать реплики на нескольких хостах, встраивать избыточность и агрегировать журналы и метрики.

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

Краткое содержание

Мы рассмотрели три различных способа запуска контейнеров в качестве рабочей нагрузки. Детали реализации будут различаться в зависимости от выбранной вами стратегии, набора вспомогательных инструментов и среды CI, поэтому мы не приводим точное описание того, как вы можете настроить автоматизацию как часть своего рабочего процесса. Однако все три могут быть легко интегрированы в конвейер CI, который запускается каждый раз, когда вы объединяете или отправляете свой код.

Оркестрация с использованием такого инструмента, как Kubernetes, быстро стала предпочтительным методом масштабируемого развертывания систем, работающих с несколькими контейнерами. Хотя он может значительно упростить работу сервисов, для которых он разработан, он также требует значительного обучения и накладных расходов на обслуживание, поэтому вам не следует прыгать, не рассматривая альтернативы.

Небольшие системы, состоящие из нескольких компонентов, могут получить лучшие результаты при использовании Compose для запуска контейнеров с воспроизводимой конфигурацией на существующем хосте Docker. Это дает некоторые преимущества Kubernetes, такие как декларативная конфигурация, без дополнительной сложности. Вы можете «облегчить» оркестровку позже, добавив поддержку Docker Swarm в существующий файл Compose, что позволит запускать несколько распределенных реплик контейнеров.

Наконец, варианты «Платформа как услуга» ускоряют развертывание приложений, не заставляя вас думать о деталях контейнера. Эти услуги предлагают возможность полной автоматизации инфраструктуры при минимальной конфигурации. Они могут быть ограничительными в долгосрочной перспективе, поэтому подумайте о том, как ваше решение будет расти со временем, прежде чем брать на себя обязательства.

При развертывании любых контейнеров в рабочей среде вам также необходимо учитывать хостинг изображений и внедрение конфигурации. Вы можете использовать общедоступную службу реестра, чтобы сделать ваши образы доступными в производственной среде. В качестве альтернативы вы можете запустить свой собственный частный реестр и предоставить учетные данные как часть конвейера CI. Значения конфигурации обычно предоставляются в виде переменных среды, которые вы можете определить на экране настроек вашего поставщика CI.