The —update-delay flag configures the time delay between updates to a service task or sets of tasks.

правильно ли я понимаю что 10 секунд это время, которое сворм ждем после успешного апдейта последнего контейнера

?

извините за нубство)

between — вроде между апдейтами

ну да, вопрос только в том, что ждет ли он успешного апдейта последнего, или сразу после команды UPDATE ждет 10 сек и запускает ее на 2 ноде, независимо от результата апдейта первой ноды?

вот как то так)))

ждёт

понял, спасибо

вы же дальше читайте

By default, when an update to an individual task returns a state of RUNNING, the scheduler schedules another task to update until all tasks are updated. If, at any time during an update a task returns FAILED, the scheduler pauses the update. You can control the behavior using the —update-failure-action flag for docker service create or docker service update.

https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/

если вы конечно на этой старнице читали предыдущее :)

да я вот только сейчас понял)))

--update-failure-action string Action on update failure (pause|continue) (default "pause")

то что надо спасибо

yep

а вот как вы забираете статус после обновления?

есть какая-то практика в этом у кого-либо?

пока не думал об этом

может просто грепнуть и авкнуть выводы ps ?

не по поцанске

тут ниже предлагают inspect

но это же надо костылить свой велосипед получается?

и еще вопрос: не думали про ручную откатку релизов? просто делать на тэгах?

Update status: State: completed Started: about a minute ago Completed: 13 seconds ago Message: update completed

в целом после обновления надо следить за этими строками и наверное будет достаточно

docker service inspect —format='{{.UpdateStatus.State}}'

да норма

о, привет!

Хело, чувак!

$ docker volume create —driver local —opt type=nfs —opt o=addr=192.168.1.1,rw —opt device=:/path/to/dir —name foo

а на практике работает?

а на практике работает?

хз. не тестил

хз. не тестил

диагноз - нуегонах вот работат как и раньше https://github.com/ContainX/docker-volume-netshare

Аргументируй плз?

эм.. ну у меня он просто не работает

ааа...

1) Уменьшить оверхед на коммуникацию между процессами 2) Гарантировать атомарность процессов как единого сервиса 3) логически иметь одну сущность а не размазаную по контейнерам

Откуда оверхед может быть?

Крон не забудь

А как быть с periodic jobs в контейнере?

никак

никак

Збс же. Внезапно оказывается, что запихать что-то в контейнер нельзя, потому что нет там крона :))

А как быть с periodic jobs в контейнере?

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

ибо оно там не надо

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

Не надо exec в контейнере

ибо оно там не надо

до тех пор пока не оказывается что надо

Не надо exec в контейнере

до тех пор пока не оказывается что надо

и тут мы такие, опаньки, а засунуть что то в докер (контейнер) не панацея, ты глядика

и тут мы такие, опаньки, а засунуть что то в докер (контейнер) не панацея, ты глядика

агада, до этого был отдельный kvm под такой процесс, и exec выглядел как ssh command

тсс.. не пали контору

это я к тому что exec збс работает уже достаточно давно

Главное его убивать

А лучше отдельный старт скрипт на том же имидже

У меня кое где он смешной прям. Типа command: sleep 3600; command

👍

И да, это костыль

Главное его убивать

ну когда нужно именно в том же контейнере...

👍

👍🏿

Почему нужно в том же?

Почему нужно в том же?

бывает такое

Он же без стейта

Он же без стейта

когда со стейтом контейнер

вообще сейчас я подрузумеваю всегда один конкретный пример - переиндекация сфинкса, там нужнопойти в контейнер , запустить indexer —rotate

вообще сейчас я подрузумеваю всегда один конкретный пример - переиндекация сфинкса, там нужнопойти в контейнер , запустить indexer —rotate

а не получится разве поднять другой контейнер на тот же named volume и запустить?

файлы надо перечиать

а не получится разве поднять другой контейнер на тот же named volume и запустить?

там один процесс отправляет сигналы другому,

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

там один процесс отправляет сигналы другому,

тогда не стоит, понял

там один процесс отправляет сигналы другому,

Exec, хотя тут возможно тот случай, когда можно и крон

инконтейнер крон - необоснованное усложенени имхо

у меня exec

инконтейнер крон - необоснованное усложенени имхо

я ушел от того что бы в контейнере был крон - это говно

я к нему и не приходил

А как быть с periodic jobs в контейнере?

Когда periodic job должен быть упакован внутри контейнера это скорее исключение, чем правило Если нужно использовать тот же образ, то просто отдельный контейнер

инконтейнер крон - необоснованное усложенени имхо

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

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

ребилд и редеплой

как правило это лучше чем крон в контейнере

Docker kill посылает сигнал кстати

Можно поменять сигнал без всяких exec

блин, я все время об этом забываю

ребилд и редеплой

Это не всегда вариант, например, если это просто вспомогательный сервис и ты не пользуешься кластером