ждёт

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

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

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, хотя тут возможно тот случай, когда можно и крон

ERROR: S client not available

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

у меня exec

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда надо запустить и забыть

Но обновляться все таки должно

Очень специфический случай, у нас так geoip работает, например

Не бейте меня дяденьки, но я б это в хелсчеки впихнул....

хай)

а как вам кажется более правильным сделать - загружать статику в облачное хранилище на этапе сборки контейнера (как часть процесса сборки этого образа контейнера docker build в команде RUN) (вариант а.)) или же отдельно после сборки контейнера (но тоже в процессе билда, в bash-скрипте, который вызывает этот docker build) (вариант б.)), есть ещё вариант в.) - загружать на этапе деплоя билда на тестовый сервер (ну, статика всё равно нужна для тестов, без неё не получится, такой вот lazy вариант)

а статика генерируется в контейнере?

Не в контейнере во время билде, это точно

хай)

Пришел засвидетельствовать нам существование Rkt?

Если воспринимать статику как один из артефактов приложения, то и деплой артефактов вероятно должен происходить во время деплоя приложения.

ну я имею ввиду. а надо ли вообще эти два процесса связывать?

Миша ! Спасибо за билет ! Привет )

а статика генерируется в контейнере?

ну да, она там, оттуда её можно вытащить либо путём запуска контейнера и копирования оттуда статики в локальную папку, а оттуда в облако или прямо через RUN там

привет ) Пожалуйста )

Пришел засвидетельствовать нам существование Rkt?

Rkt существует

ну да, она там, оттуда её можно вытащить либо путём запуска контейнера и копирования оттуда статики в локальную папку, а оттуда в облако или прямо через RUN там

тогда я согласен с тем, что надо во время деплоя ее заливать

Если воспринимать статику как один из артефактов приложения, то и деплой артефактов вероятно должен происходить во время деплоя приложения.

статика - это половина приложения) если приложение - одностраничный сайт на js