У меня есть проект, запущенный с использованием нескольких контейнеров docker. Теперь я хочу автоматизировать развертывание с помощью Jenkins (push-триггеры). У меня есть три сценария, но мне не нравится ни один из них. Вот эти три разных сценария:
1) Я развертываю изменения на сервере, затем на сервере запускаю docker-compose build
, чтобы воссоздать потенциально измененные образы и затем запустить контейнеры.
минус - я не собираю эти новые образы на хосте, а только на сервере, поэтому я не могу быть уверен, что сборка пройдет успешно, она может быть глючной и вызвать несколько ошибок без предварительной проверки.
2) Я могу сначала проверить, что проект собирается успешно, но сначала запустить docker-compose build
на моем сервере Jenkins и развернуть после этого.
вниз - я запускаю docker-compose build
два раза. на моем сервере Jenkins и на производственном сервере.
3) Я могу собрать на своем сервере Jenkins, затем протолкнуть его на docker hub и вытащить на сервер. таким образом, я собираю только один раз.
вниз - как я уже сказал, у меня есть несколько изображений. поэтому в этом сценарии мне нужно загрузить, возможно, 6 изображений на docker hub, а затем вытащить их на сервер.
Как я уже сказал, я не хочу использовать ни один из этих вариантов из-за их недостатков. Так что, может быть, есть другие лучшие способы делать подобные вещи?
Обычно рекомендуется разделять этапы сборки и развертывания на отдельные задания.Таким образом, вы собираете / тестируете один раз и можете перенести версионный образ в свои среды, когда будете готовы. Вы также можете запускать сборку при каждом изменении кода, создавая при необходимости уникальные # версии изображения.
Ваше задание развертывания должно содержать возможность указать версию образа докера для развертывания, что также помогает при откате. Вариант № 3 IMO - лучший вариант.
Если вы не хотите возиться с dockerhub, вы можете легко создать локальный реестр докеров, который вы также можете использовать для хранения своих образов. См. docker_registry