B
А чуть более нативно это как?
Size: a a a
2020 May 12
B
Я бы с радостью вынес это в pillar, но друзья программисты используют docker-compose, и не хотят дублировать 100500 раз версии контейнеров. Поэтому я подумал было бы логично просто читать имеющийся файл.
с друзьями-программистами проще тогда через CD-систему работать. соль под CD не шибко удобный инструмент. как-то тут уже обсуждались подобные кейсы и, емпин, ни к чему особо не пришли
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
# /etc/systemd/system/<servicename>.service- управление запуском-перезапуском через salt.state.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, как больше нравится)
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
AZ
с друзьями-программистами проще тогда через CD-систему работать. соль под CD не шибко удобный инструмент. как-то тут уже обсуждались подобные кейсы и, емпин, ни к чему особо не пришли
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
# /etc/systemd/system/<servicename>.service- управление запуском-перезапуском через salt.state.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, как больше нравится)
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
Спасибо, я видел такой вариант, он если честно не сильно отличается от того что я выше скинул.
AZ
А тут использовать загрузку в env я правильно понял?
AZ
Я пока сделал запуск dockercompose.up, и паралельно подумаю как бы всё покрасивее сделать, не мешая разрабам :)
B
Спасибо, я видел такой вариант, он если честно не сильно отличается от того что я выше скинул.
всегда было лень разбираться, какие вызовы в коде стейтов накручены и с какими особенностями) а с сервисами соль работает давно и корректно, можно не париться
B
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.grafana.html
бывают и такие стейты, но толку от них
бывают и такие стейты, но толку от них
AZ
всегда было лень разбираться, какие вызовы в коде стейтов накручены и с какими особенностями) а с сервисами соль работает давно и корректно, можно не париться
запуск стоп да. но надо же еще запустить обновление образов, опять использовать dockercompose.pull
B
запуск стоп да. но надо же еще запустить обновление образов, опять использовать dockercompose.pull
так можно сделать watch на compose-файл, само переподымется. причём, compose'ом
релоад так же делается. в каких-то стейтах катаются конфиги/файлики из шаблонов/да хоть копированием — если там есть изменения, то дёргается стейт перезапуска/релоада
релоад так же делается. в каких-то стейтах катаются конфиги/файлики из шаблонов/да хоть копированием — если там есть изменения, то дёргается стейт перезапуска/релоада
AZ
Пощупаю что это
B
А тут использовать загрузку в env я правильно понял?
в целом да
pillar — это как vars в ansible, грубо говоря. в репке солта пишутся переменные, в дальнейшем их можно в sls-файлах подставлять через jinja. или через salt.state.file темплейтить из этих переменных файлики на целевом хосте
если окружение ± статично (т.е. если не лень сделать коммит, чтобы поменять), то это как раз самый удобный и правильный способ описания переменных
pillar — это как vars в ansible, грубо говоря. в репке солта пишутся переменные, в дальнейшем их можно в sls-файлах подставлять через jinja. или через salt.state.file темплейтить из этих переменных файлики на целевом хосте
если окружение ± статично (т.е. если не лень сделать коммит, чтобы поменять), то это как раз самый удобный и правильный способ описания переменных
AZ
Сейчас я запущу на деве хотя бы так, и буду уже эксперементировать с подгрузкой в env
B
с друзьями-программистами проще тогда через CD-систему работать. соль под CD не шибко удобный инструмент. как-то тут уже обсуждались подобные кейсы и, емпин, ни к чему особо не пришли
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
docker-compose легко всунуть в соль:
- темплейт compose-файла через jinja
- темплейт небольшого systemd-юнита для запуска c примерно таким содержимым
# /etc/systemd/system/<servicename>.service- управление запуском-перезапуском через salt.state.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, как больше нравится)
в этой схеме минимум сложностей и нагромождений, но в данном случае всё равно встанет вопрос — откуда получать версию контейнера при её обновлении, если версию бампают разрабы, не хотящие идти в репу с солтом
кстати, про CD к https://t.me/saltstack/16229
чят, а чем потенциально плох вариант обновлять через любимый CI/CD
в consul, например
из того, с чем сам сталкивался:
- при недоступности консула наверняка прилетить некая дичь, и от этого надо бы добавлять валидацию. как вариант, сделать макрос для получения значений и там сверяться
- надо ещё прикинуть, как лучше дёрнуть ручку запуска после обновления версии — хайстейт может быть неприлично долгим, а стейты могут называться по-разному. можно в CI/CD захардкодить стейт для конкретного сервиса и какой-то селектор для таргетов
чот получается всё равно кубер на коленке
чят, а чем потенциально плох вариант обновлять через любимый CI/CD
ext_pillar'ы (версию, енвы)?в consul, например
из того, с чем сам сталкивался:
- при недоступности консула наверняка прилетить некая дичь, и от этого надо бы добавлять валидацию. как вариант, сделать макрос для получения значений и там сверяться
- надо ещё прикинуть, как лучше дёрнуть ручку запуска после обновления версии — хайстейт может быть неприлично долгим, а стейты могут называться по-разному. можно в CI/CD захардкодить стейт для конкретного сервиса и какой-то селектор для таргетов
чот получается всё равно кубер на коленке
AZ
Спасибо за опыт, но у меня задача проще, и нагромождение консулом будет явно лишнее. Мне надо тупо в кучке магазинов обновить приложении кассы, которое пускается композом
AZ
ни каких связей между кассами нет, поэтому файлика с енвами или пиллара хватит с головой
B
Спасибо за опыт, но у меня задача проще, и нагромождение консулом будет явно лишнее. Мне надо тупо в кучке магазинов обновить приложении кассы, которое пускается композом
это наброс к давнему топику) тебе это пока точно не нужно
AZ
На другом проекте нужно :) но я пока молод
AZ
доберусь в свободное время
LL
Кто-нибудь использует солт в ci/cd сценариях?
Может есть ссылки на истории успеха?
Может есть ссылки на истории успеха?
с jenkins прекрасно работает