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