Как интегрировать Capistrano с Docker для развертывания?

Я не уверен, что мой вопрос уместен, поскольку я могу попытаться использовать инструменты (Capistrano и Docker), которые не должны смешиваться.

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

Так выглядит мой проект (файлы приложений не отображаются):

Capfile
docker-compose.yml
docker-compose.staging.yml
config/
    deploy.rb
    deploy
        staging.rb

Файлы Docker Compose создают все необходимые контейнеры (Nginx, PHP, MongoDB, Elasticsearch и т.д.) для запуска приложения в среде разработки или промежуточного процесса (отсюда некоторые конкретные параметры, определенные в docker-compose.staging.yml).

Приложение развертывается в промежуточной среде с помощью этой команды:

cap staging deploy

Архитектура папок на сервере - это Capistrano:

current
releases
    20160912150720
    20160912151003
    20160912153905
shared

В каталоге current промежуточного сервера выполняется следующая команда для создания всех необходимых контейнеров для запуска приложения:

docker-compose -f docker-compose.yml -f docker-compose.staging.yml up -d

Пока все хорошо. В следующем развертывании все сложнее: символическая ссылка current укажет на новый каталог каталога releases:

Если deploy.rb определяет команды, которые должны выполняться внутри контейнеров (например, docker-compose exec php composer install для PHP), Docker сообщает, что контейнеры еще не существуют (поскольку существующие были созданы в предыдущей папке выпуска).
Если в процессе развертывания Capistrano выполняется команда docker-compose up -d, я получаю некоторые ошибки из-за конфликтов портов (предыдущие контейнеры все еще существуют).

У вас есть идея о том, как решить эту проблему? Должен ли я отойти от Капистрано и сделать что-то другое?

Идея заключалась в том, чтобы сохранить (близкое) развертывание с нулевым временем простоя, которое предлагает Capistrano с гибкостью контейнеров Docker (например, несколько версий PHP для различных приложений на одном сервере).

Ответ 1

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

Пока вы делаете это в основном, при запуске кепки развертывания

создайте приложение (на основе текущей базы, которую вы нанесли на хост) - возможно, даже включает в себя задачи gulp/grunt/build
тогда вы "упаковываете" его в свои контейнеры с помощью "томов"
во время запуска/замены контейнеров

Вы делаете это, чтобы получить "почти" нулевое время простоя.

Если вы действительно заботитесь о времени простоя и о формализации процесса развертывания, вы должны сделать это правильно, используя правильную реализацию конвейера для

упаковка /ci
развертывание/распространение

Я не думаю, что capistrano может/должен быть одним из инструментов, которые вы можете использовать во время этой стратегии. Capistrano предназначен для развертывания приложения непосредственно на сервере с использованием ssh и git в качестве транспорта. Используя cap для создания целых изображений на целевом сервере, чтобы затем запускать их в качестве контейнеров, на самом деле стоит верх, IMHO.

упаковка/здание

Используйте CI/CD-сервер, например jenkins/bamboo/gocd, для создания образа-образа для вашего приложения. Предполагая, что только приложение настроено с точки зрения "выпуска", скажем, у вас есть db и app в качестве контейнеров/сервисов, приложение будет включать ваш исходный код и будет регулярно изменяться во время релизов.

Таким образом, это процесс CD/CI для создания нового приложения-образа (выпуска) за пределами вашего сервера CI. Потянув исходный код приложения, упакуйте его в свое изображение, используя COPY, а затем любой оператор RUN для компиляции ваших активов (npm/gulp/grunt whatever). Все это происходит не на производственном сервере, а на агенте CI/CD.

Затем вы нажимаете этот образ-релиз, вызывая этот образ yourregistry.com/yourapp в свой частный реестр в качестве новой "версии" для развертывания.

Развертывание

с простой (простой)

Для развертывания на вашем производственном или промежуточном сервере С простоями вы просто выполните docker-composer stop && docker-composer up - это автоматически выведет новое изображение, а затем запустит его в вашем стеке - ваше приложение будет обновлено

Конечно, сервер может извлечь из вашего частного репозитория.

с временем простоя (больше усилий)

Достигнув развертывания с нулевым временем простоя, вы должны использовать концепцию blue-green. Таким образом, вы добавляете прокси-сервер в свою установку и больше не выставляете публичный порт из приложения, а используете этот публичный публичный порт. Ваша текущая система в реальном времени может работать на случайном порту 21231, прокси-сервер пересылает от 443 до 21231.

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

При повторном развертывании вы только запускаете "новый" контейнер на основе нового приложения-изображения в дополнение (к старому), он получает новый случайный порт 12312 - если хотите, запустите свои интеграционные тесты снова 12312 напрямую (не используйте прокси). Если вы закончили и счастливы, переконфигурируйте прокси-сервер, чтобы теперь перейти на 12312, - затем удалите старый контейнер (21231).

Если вам нравится автоматизировать перенаправление прокси-сервера, которое подробно выходит за рамки этого вопроса, вы можете использовать сервис-обнаружение и регистратор, который делает случайные порты более практичными и упрощает перенастройку вашего прокси-сервера, пусть это nginx/haproxy, пока они работают. Инструменты будут, например.

consul
consul watch + consul-template или tiller прокси для обновления прокси-config
Registator для централизованной регистрации или режим клиента консула с service-configuration.json (зависит от вашего выбора) -

Ответ 2

Я не думаю, что Капистрано - правильный инструмент для работы. Это было недавно обсуждено в PR для SSHKit, который лежит в основе Capistrano.

https://github.com/capistrano/sshkit/pull/368

@EugenMayer лучше справляется с объяснением "нормального" способа использования Docker.