кстати, про CD к https://t.me/saltstack/16229

чят, а чем потенциально плох вариант обновлять через любимый CI/CD ext_pillar'ы (версию, енвы)?
в consul, например

из того, с чем сам сталкивался:
- при недоступности консула наверняка прилетить некая дичь, и от этого надо бы добавлять валидацию. как вариант, сделать макрос для получения значений и там сверяться
- надо ещё прикинуть, как лучше дёрнуть ручку запуска после обновления версии — хайстейт может быть неприлично долгим, а стейты могут называться по-разному. можно в CI/CD захардкодить стейт для конкретного сервиса и какой-то селектор для таргетов

чот получается всё равно кубер на коленке

с jenkins прекрасно работает

небольшой объем данных вполне можно передавать прям "в рантайме", при вызове api можно передавать pillar так же как и при вызове salt из cli

но это, увы, не персистентно. при запуске по расписанию поломается

эм, а зачем по расписанию запускать то, что должно запускаться из ci/cd?

ну, вы бы описали хоть в общих чертах как именно оно у вас работает

https://ru.wikipedia.org/wiki/Pepper_X?

с друзьями-программистами проще тогда через CD-систему работать. соль под CD не шибко удобный инструмент. как-то тут уже обсуждались подобные кейсы и, емпин, ни к чему особо не пришли

docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым

# /etc/systemd/system/<servicename>.service
[Unit]
Description=<servicename>
[Service]
ExecStart=/usr/local/bin/docker-compose -f /path/to/docker-compose.yml up
ExecStop=/usr/local/bin/docker-compose -f /path/to/docker-compose.yml down
ExecReload=/usr/local/bin/docker-compose -f /path/to/docker-compose.yml kill -s HUP
[Install]
WantedBy=default.target (ну или network-online.target, как больше нравится)

- управление запуском-перезапуском через salt.state.service

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

кстати, про CD к https://t.me/saltstack/16229

чят, а чем потенциально плох вариант обновлять через любимый CI/CD ext_pillar'ы (версию, енвы)?
в consul, например

из того, с чем сам сталкивался:
- при недоступности консула наверняка прилетить некая дичь, и от этого надо бы добавлять валидацию. как вариант, сделать макрос для получения значений и там сверяться
- надо ещё прикинуть, как лучше дёрнуть ручку запуска после обновления версии — хайстейт может быть неприлично долгим, а стейты могут называться по-разному. можно в CI/CD захардкодить стейт для конкретного сервиса и какой-то селектор для таргетов

чот получается всё равно кубер на коленке

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

В смысле - сольт обычно ляжет раньше, чем консул, если последний особо сильно не шатать, конечно. В консуле меня больше пугает другое. Скажем, тебе надо менять пачку ключей одновременно. Есть такая опция? Я не нашел. Выход есть. Пишешь в один ключ номер версии, а в набор ключей /path/version/... сами значения. Такая как бы относительная косвенная адресация

хм, ну если не включать стейты наката разрабских сервисов в top.sls, то да, мешать не будет