Упростите развертывание Docker Swarm с помощью драгоценного камня Swarm Orca

Фон

Swarm Orca - это простой драгоценный камень Ruby, который помогает развернуть на нескольких кластерах Swarm так же, как развертывается локально.

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

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

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

Развертывание с помощью Swarm очень простое и может быть описано в следующих шагах:

  • Определите стеки Swarm, используя docker-compose файлы
  • Создайте стек Docker с помощью команды docker stack
docker stack deploy --compose-file docker-compose.yml ${stack_name}

После выполнения команды docker stack deploy Swarm создаст службы, определенные в файлах стека, затем позаботится о поиске свободного узла в кластере для развертывания (создания контейнеров) каждой из определенных служб и убедитесь, что конфигурации служб соответствуют .

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

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

  • Службы Docker можно настроить, указав переменные среды. Значения этих переменных можно определить в стеках Docker. Это нормально для большинства переменных; однако для конфиденциальной информации нам необходимо предоставить инструмент для шифрования / дешифрования этих переменных.
  • Автоматизация процесса развертывания: для упрощения развертывания Docker необходимо автоматизировать этапы развертывания сервисов - например, копирование файлов стека в узлы диспетчера Swarm, получение образов Docker, необходимых для развертывания, если это необходимо, и выполнение Docker. команды для создания сервисов.
  • Поддержка нескольких сред требует отделения значений конфигурации служб от файлов стека, чтобы иметь возможность использовать один и тот же стек с несколькими средами без дублирования этих файлов.
  • Для поддержки нескольких сред требуется преобразование файлов стека компоновки в шаблоны, чтобы мы могли иметь разные конфигурации для разных сред - например, в случае необходимости развертывать службы в двух средах с разными драйверами ведения журнала и одними и теми же файлами стека.
  • Для приложений, сохраняющих данные в RDMS, таких как MySql, необходимо выполнить миграцию схемы базы данных перед развертыванием нового выпуска, чтобы обеспечить развертывание с нулевым временем простоя. К сожалению, мы не можем определить миграцию базы данных как другую услугу, потому что контейнеры для миграции базы данных Swarm перестанут работать после завершения миграции, и, как следствие, Swarm всегда будет пытаться их перезапустить. Другая причина состоит в том, что мы хотим заблокировать развертывание путем миграции базы данных, чтобы новый код был развернут только после успешного завершения миграции базы данных - в противном случае процесс развертывания завершится неудачно.
  • Необходимо хранить все значения конфигурации в системе управления версиями, чтобы мы могли отслеживать, кто вносит изменения, когда эти изменения вносятся и почему они вносятся?
  • Поддерживайте локальное развертывание в средах разработки так же, как и в производственной среде.

На рынке есть решения для решения некоторых из вышеперечисленных задач, такие как Portainer и Rancher.

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

Особенности драгоценных камней

Поскольку я работаю в основном с приложениями Rails, меня интересовало внедрение этого инструмента для поддержки развертывания приложений Rails. Однако этот инструмент можно использовать для развертывания сторонних сервисов, таких как Nginx, MySQL и Redis. Его также можно использовать для развертывания приложений, отличных от Rails.

Основные функции, которые я хотел включить в первую версию инструмента, подробно описаны ниже:

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

Чтобы создать этот инструмент с этими функциями, я решил создать гем Ruby, который может обрабатывать развертывание Swarm, а также решил воспользоваться Capistrano, инструментом удаленной автоматизации и развертывания серверов, написанным на Ruby. Capistrano поможет мне здесь в достижении большинства функций, которые я хочу развить.

Я назвал гем развертывания Swarm Orca, , и его легко найти на GitHub и RubyGems.org . Не стесняйтесь пробовать и оставлять отзывы.

Создайте пример проекта с помощью Swarm Orca

В следующем разделе я попытаюсь показать, как мы можем настроить новый проект с помощью Swarm Orca и развернуть его в локальной среде разработки. Созданный мной проект orca будет включать (только для простоты) три услуги, а именно:

  • MySQL
  • Nginx
  • образец-рельсы-приложение

Первым шагом в этом проекте является установка драгоценного камня локально с помощью следующей команды.

➜  ~/ gem install swarm_orca

После установки драгоценного камня будет установлена ​​orca командная строка, и вы сможете создать новый проект с помощью следующей команды:

#orca new ORCA_DIRECTORY_NAME GIT_FORK DOCKER_NETWORK
➜  ~/ orca new  orca_test wshihadeh orca_test_network
  • ORCA_DIRECTORY_NAME - это имя папки проекта
  • GIT_FORK - ваше имя в Git Fork
  • DOCKER_NETWORK - это имя сети Docker, в которой будут развернуты службы.

Приведенная выше команда создаст образец проекта Orca со всеми необходимыми файлами для запуска локального развертывания и с некоторыми предопределенными стеками.

Ниже приведен список файлов, которые будут созданы по умолчанию. такие как Nginx, MySQL Redis и т. д.

➜  ~/ orca new  orca_test wshihadeh orca_test_network                                                                                                                                                                      
Start Generating orca files
      create  .gitignore
      create  .ruby-version
      create  README.md
      create  capistrano/Capfile
      create  nginx/Dockerfile
      create  nginx/nginx.conf
      create  redis/Dockerfile
      create  redis/redis.conf
      create  capistrano/config/deploy/template_stage.rb
      create  capistrano/Gemfile
      create  .ruby-gemset
      create  capistrano/config/deploy.rb
      create  application_stack/docker-stack-elasticsearch.yml.erb
      create  application_stack/docker-stack-errbit.yml.erb
      create  application_stack/docker-stack-mysql.yml.erb
      create  application_stack/docker-stack-nginx.yml.erb
      create  application_stack/docker-stack-rabbitmq.yml.erb
      create  application_stack/docker-stack-redis.yml.erb
  • Поддерживаемые файлы Docker-stack можно найти в папкеapplication_stack. Ожидается, что эти стеки будут шаблоном ERB-стека.
  • Поддерживаемые элементы конфигурации среды можно найти в capistrano/config/deploy/${env}.rb.
  • Конфигурацию общего развертывания можно найти в capistrano/config/deploy.rb.
  • Пользовательские образы Docker и файлы конфигурации можно найти в ${service_name} - например, Nginx или Redis.

Новый вывод команды также будет включать инструкции для следующих шагов.

Complete!
Next step is to create development stage file from the
 template file use the following commands to do it
cd orca_test/capistrano
gem install bundler
bundle install
cd orca_test/capistrano/config/deploy
cp template_stage.rb local.rb
Replace all ${VAR} with a valid value
Read Readme for more information

Чтобы иметь возможность развертывать наши службы локально, нам нужно выполнить приведенную выше инструкцию, а затем выполнить следующие действия:

  • Создайте локальную сцену.
➜  ~/ pwd
orca_test/capistrano/config/deploy
➜  ~/ cp template_stage.rb local.rb
  • Поскольку мы не собираемся поддерживать только MySQL и Nginx из приложений по умолчанию, я очистил local.rb, включив только эти конфигурации. Мы должны определить обслуживающую организацию и пользователя в верхней части файла и оставить только роли Nginx, MySQL и swarm_manager. deploy_to необходимо добавить, потому что deploy_to по умолчанию не существует на моем локальном компьютере (мы также можем создать папку по умолчанию deploy_to, то есть /home/deploy/orca).
  • Поскольку наш проект не называется orca и у нас другой путь локального развертывания, нам нужно перезаписать некоторые конфигурации по умолчанию в deploy.rb.
  • Зафиксируйте изменения и поместите их в свою вилку.
  • Теперь мы готовы к развертыванию и можем просто выполнить развертывание с помощью одной из следующих команд:
# For deploying all stacks 
s➜  ~/  bundle exec cap local deploy:setup deploy:all
# For deploying only mysql
s➜  ~/  bundle exec cap local deploy:setup deploy:mysql
# For deploying only nginx
s➜  ~/  bundle exec cap local deploy:setup deploy:nginx
# For deploying only nginx and mysql 
s➜  ~/  bundle exec cap local deploy:setup deploy:nginx deploy:mysql
# For deploying only nginx and mysql
s➜  ~/ DEPLOYED_STACKS='nginx mysql' bundle exec cap local deploy:auto
  • Вы также можете выполнить локальное развертывание со стратегией копирования вместо Git, добавив следующую переменную среды в командную строку развертывания:
s➜  ~/ SCM=copy bundle exec cap local deploy:setup deploy:all

Следующим шагом будет добавление приложения Rails в Orca и попытка развернуть его в локальной среде. Предполагая, что у нас есть приложение Rails со следующим образом Docker, wshihadeh/simple_rails можно настроить со следующими переменными среды: RAILS_ENV, RAILS_LOG_TO_STDOUT, DATABASE_URL и LOG_LEVEL.

  • Первым шагом для интеграции этого приложения является создание шаблона стека Docker для нового приложения и сохранение его под именем файла application_stack/docker-stack-simple_rails.erb. Содержимое файла должно быть примерно таким, как показано ниже:
  • Следующим шагом является обновление capistrano/config/deploy.rb simple_rails информацией о приложении, представленной ниже.

db_apps_stacks_mapping - это хэш-объект, который определяет список поддерживаемых стеков и приложений, подключенных к базам данных. Ключи хэша - это имена стека, которые должны соответствовать имени файла шаблона стека. Например, ожидается, что стек simple_railS будет определен в application_stack/docker-stack-simple_rails.erb. Значения ключей могут быть пустым массивом из списка приложений в стеках, которые используют базы данных. Поскольку simple_rails имеет только одно приложение Rails, мы можем установить то же значение, что и simple_rails.

  • Обновите локальную сцену с конфигурацией приложения simple_rails. Единственная необходимая переменная среды - stack_name. ${application}_database_url требуется только в том случае, если вы хотите получить поддержку для миграции баз данных. Остальные переменные зависят от приложения и его файла шаблона стека.

Нам также необходимо обновить локальную сцену, чтобы в ней были роли приложения.

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

  • Чтобы развернуть simple_rails локально, нам нужно сначала создать базу данных и начальные числа, а затем развернуть приложение. Эти действия можно выполнить с помощью следующих команд:
bundle exec cap local deploy:setup
bundle exec cap local deploy:create_simple_rails_dbs
bundle exec cap local deploy:migrate_simple_rails_dbs
bundle exec cap local deploy:seed_simple_rails_dbs
bundle exec cap local deploy:simple_rails

Задача deploy:simple_rails выполнит миграцию базы данных автоматически, поэтому она нужна только при первом развертывании.

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

С помощью приведенной ниже команды мы можем сгенерировать новый ключ шифрования. Убедитесь, что вы защищаете этот ключ и не публикуете его.

➜ : orca gen_enc_key                                                                                                                                     
Encryption Key: 6764f56ee9e24f3bf5903a394ce1081a7921f212bf017182149219fdc82f21d4

Чтобы зашифровать элементы конфигурации, мы можем использовать следующую команду:

➜ : orca encrypt $KEY mysql2://root:mysql@mysql/simple_rails_local
OQ8VXMq5Hz/xlygPmphrtVVpOcE

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

Единственное необходимое изменение в конфигурации приложения - это переименовать конфигурацию simple_rails_database_url в encrypted_imple_rails_database_url и присвоить ей зашифрованное значение. Swarm Orca позаботится о расшифровке этого значения во время развертывания.

encrypted_simple_rails_database_url: 'OQ8VXMq5Hz/xlygPmphrtVVpOcE',
  • Теперь, когда мы закончили реконфигурировать приложение simple_rails, мы можем повторно развернуть его в локальной среде. Единственное, что на этот раз отличается - нам нужно предоставить ключ шифрования в командной строке развертывания, чтобы иметь возможность расшифровать значения на хостах Docker. Развертывание может быть выполнено с помощью следующей командной строки:
➜ : export ENCRYPTION_KEY=$key
➜ : export SCM=copy
➜ : bundle exec cap local deploy:setup deploy:simple_rails
  • Интегрировать новые среды можно просто путем создания новых файлов сцены в capistrano/config/deploy. Это можно просто сделать, скопировав файл конфигурации и обновив необходимые конфигурации в новом файле, например IP-адреса серверов или даже конфигурации приложений.
  • Последний шаг, который можно сделать для улучшения и автоматизации решения, - это создание конвейера Jenkins для автоматизации развертывания из Jenkins. Следующий файл Jenkins представляет собой образец файла для определения конвейеров развертывания с помощью Swarm Orca.

Заключение

Контейнеры Docker и Swarm упростили процесс развертывания программного обеспечения, но они не решили всех проблем, с которыми мы сталкиваемся, когда дело доходит до управления развертыванием программного обеспечения, основанного на микросервисной архитектуре.

На рынке есть несколько решений для решения некоторых из этих проблем, но для большинства из них требуется немного усилий, чтобы настроить серверы или установить их в Swarm.

Swarm Orca - это простой гем на Ruby, который помогает развертывать кластеры Swarm так же, как локально. Гем обеспечивает поддержку таких функций, как развертывание на нескольких кластерах, шифрование элементов конфигурации и выполнение миграции базы данных.