Как правильно/лучше использовать развертывание стека докеров с независимо обновляемыми службами?

У нас есть несколько приложений, которые являются частью более крупного приложения.

Каждое из этих приложений имеет образ Docker, созданный для каждого коммита.

Я хотел бы, чтобы вы использовали режим роя докеров и стеки докеров для автоматического развертывания/обновления этого более крупного приложения.

Давайте притворимся, что у меня есть этот компоновочный файл (неактуальные части опущены)

version: '3'
services:
    product_service:
       image: myregistry.com/product_service:c8372d
       ..
    cart_service:
       image: myregistry.com/cart_service:ee7f32
       ..

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

Какие у меня варианты в этом случае?

Что я могу придумать:

  • делать некоторые причудливые вещи и регенерировать файл компоновки при фиксации и изменять только те части, которые мне нужны.
  • не используйте docker stack deploy и вместо этого используйте старый docker service create
  • какой-то тип переменной среды, передаваемой в файл компоновки (проблема здесь в том, что каждая служба все равно должна знать текущую версию других служб, верно?)
  • использовать другой стек для каждой службы (что-то не так с этим или проблемы?)

Я что-то упускаю из виду? Разве такое строительство не было задумано? Какой подход здесь лучше?


docker docker-compose docker-swarm-mode
person Kyle Gobel    schedule 10.02.2017    source источник
comment
В порядке предпочтения 1, 4, 2, 3 я думаю пожимает плечами   -  person johnharris85    schedule 10.02.2017

Ответы (1)


arrow_upward
1
arrow_downward

Я считаю, что проще всего выбрать последний вариант, разделить каждую службу на отдельный стек, не трогая ничего другого. Затем вы продвигаете стек одного сервиса. Для этого я бы добавил два предварительных условия:

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

  • Запустите свой собственный реестр. Для меня это безопаснее, чем просто полагаться на закрепленные версии. Закрепление гарантирует, что вы получите одну и ту же версию на всех узлах в рое, но если вы переходите от разработки к тестированию и к производству, это будут отдельные стеки и, возможно, полностью отдельные рои. И для меня гораздо проще полагаться на тег в репозитории, который обновляется только контролируемым образом (скрипты CI/CD).

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

person BMitch    schedule 10.02.2017
comment
Спасибо, BMitch, сейчас попробовал такую ​​настройку, сервисы находятся в одной оверлейной сети, но не могут определить, какие имена хостов использовать. т.е. http://cart_service не работает из product_service - person Kyle Gobel; 10.02.2017
comment
Внутри контейнеров вы используете имя службы, если они находятся в одной сети. Вне контейнеров вам необходимо открыть порт и подключиться к хосту докера на этом порту. - person BMitch; 10.02.2017
comment
bahh, я только что назвал сервис неправильно. Это 2 часа, которые я никогда не верну :). Спасибо за помощь - person Kyle Gobel; 10.02.2017