Какие шаги предпринимает docker swarm при последовательном обновлении с start-first?

Когда docker swarm выполняет скользящее обновление с stop-first для нескольких запущенных экземпляров контейнера, он выполняет, среди прочего, следующие шаги по порядку для каждого контейнера в строке:

  1. Удалите контейнер из его внутреннего балансировщика нагрузки.

  2. Отправьте сигнал SIGTERM контейнеру.

  3. Относительно льготного периода остановки отправьте сигнал SIGKILL.

  4. Запустить новый контейнер

  5. Добавьте новый контейнер в его внутренний балансировщик нагрузки.

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

Будут ли старый и новый контейнеры одновременно доступны через балансировщик нагрузки (пока старый не остановится и не будет удален из lb)?

Или новый контейнер будет сначала запущен и не будет добавлен в балансировщик нагрузки, пока старый контейнер не будет остановлен и удален из балансировщика нагрузки?

Последнее необходимо для процессов, привязанных к конкретному экземпляру службы (контейнеру).


docker swarm
person Johan Vogelzang    schedule 06.10.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Это в основном наоборот. Новый контейнер запускается, добавляется в LB, затем старый удаляется из LB и отправляется сигнал на отключение.

Будут ли старый и новый контейнеры одновременно доступны через балансировщик нагрузки (пока старый не остановится и не будет удален из lb)?

Да.

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

person Bret Fisher    schedule 07.10.2018
comment
Спасибо, Брет! Действительно, мы хотим, чтобы время простоя было нулевым, и у нас есть проверки работоспособности. К сожалению, в нашем рое есть сервис, который нельзя масштабировать. Эта служба может работать только как один экземпляр. Поэтому для этого мы не можем использовать start-first. У нас могло бы быть больше нулевого времени простоя, если бы мы могли сделать: запустить новый контейнер, удалить старый контейнер из LB, добавить новый контейнер в LB, отправить сигнал о завершении работы в старый контейнер. - person Johan Vogelzang; 08.10.2018
comment
Да нет такой опции. Каково реальное ограничение? Состояние сеанса HTTP? - person Bret Fisher; 08.10.2018