GG
2. описываешь контейнеры в солте. Не делаешь их запуск никак. Просто описываешь их наличие. И где-то сбоку через тот же orch делаешь или cmd.run последовательно их стартуешь с проверкой кода возврата или хелсчека
Size: a a a
2020 June 01
GG
первое мне кажется более элегантным решением
E
Ок, спасибо
KN
А что так сложно, почему просто не использовать docker-compose из коробки ?
E
А что так сложно, почему просто не использовать docker-compose из коробки ?
каким образом? есть примеры?
KN
1. через file.managed деплоишь содержимое docker-compose манифеста
2. через https://github.com/saltstack-formulas/systemd-formula создаёшь сервис подобного вида:
3. Далее с даным systemd сервисом можно работать стандартным салтовым service.running стейтом
2. через https://github.com/saltstack-formulas/systemd-formula создаёшь сервис подобного вида:
[Unit]
Description=My Awesome Service
Requires=docker.service
After=docker.service
[Service]
Restart=always
RestartSec=3
ExecStartPre=/usr/local/bin/docker-compose -f {{ docker_compose_file }} pull --parallel --ignore-pull-failures
ExecStart=/usr/local/bin/docker-compose -f {{ docker_compose_file }} up -d
ExecStop=/usr/local/bin/docker-compose -f {{ docker_compose_file }} down
[Install]
WantedBy=multi-user.target
3. Далее с даным systemd сервисом можно работать стандартным салтовым service.running стейтом
E
Ок, спасибо!
KN
Плюсы:
- ты не зависишь от salt'а и можешь продолжать управлять сервером в ручную
Минусы:
- раскажет @gecube, если у него будет желание :))
- ты не зависишь от salt'а и можешь продолжать управлять сервером в ручную
Минусы:
- раскажет @gecube, если у него будет желание :))
GG
докер компоуз. Не хочу обсуждать
E
вообще очень странно все это: у докера есть годное апи, что бы в него не говорить
GG
можете считать, что у меня травма от него )
GG
1. через file.managed деплоишь содержимое docker-compose манифеста
2. через https://github.com/saltstack-formulas/systemd-formula создаёшь сервис подобного вида:
3. Далее с даным systemd сервисом можно работать стандартным салтовым service.running стейтом
2. через https://github.com/saltstack-formulas/systemd-formula создаёшь сервис подобного вида:
[Unit]
Description=My Awesome Service
Requires=docker.service
After=docker.service
[Service]
Restart=always
RestartSec=3
ExecStartPre=/usr/local/bin/docker-compose -f {{ docker_compose_file }} pull --parallel --ignore-pull-failures
ExecStart=/usr/local/bin/docker-compose -f {{ docker_compose_file }} up -d
ExecStop=/usr/local/bin/docker-compose -f {{ docker_compose_file }} down
[Install]
WantedBy=multi-user.target
3. Далее с даным systemd сервисом можно работать стандартным салтовым service.running стейтом
а чего каждый контейнер не обернуть в systemd - это же годнее ))))
GG
как минимум - у тебя на удаленном сервере нет лишнего элемента в виде бинаря #компост и докер-компоуз ямла
GG
несомненно @Konstantin_Nikolaev (спасибо тебе) рассказал один из вариантов КАК МОЖНО СДЕЛАТЬ. Хорошо или плохо это - пускай решает конкретный инженер, который это будет внедрять
KN
докер компоуз. Не хочу обсуждать
я так же не хочу уже раз в третий поднимать тему +/- )))
KN
несомненно @Konstantin_Nikolaev (спасибо тебе) рассказал один из вариантов КАК МОЖНО СДЕЛАТЬ. Хорошо или плохо это - пускай решает конкретный инженер, который это будет внедрять
👍
E
от меня ускользвет мысль: ну вот у нас есть контейнеры, Нам нуждно аккуратно всем им сказать docker run и передать им все необходимые параметры. А локер, сам запустит, посмотрит что они поднялись и перезапустит, если надо. Но нет. системд и вот это вот все
GG
Eugeny
от меня ускользвет мысль: ну вот у нас есть контейнеры, Нам нуждно аккуратно всем им сказать docker run и передать им все необходимые параметры. А локер, сам запустит, посмотрит что они поднялись и перезапустит, если надо. Но нет. системд и вот это вот все
докер перезапускает контейнеры ВНЕ очередности. Понимаешь?
GG
если ты делаешь restart: always
GG
просто пачкой. И все.