Size: a a a

2021 January 18

c

citius in Saltstack
Roman
Я сам биконы не использовал, не было необходимости, просто ознакомил человека с наличием такой возможности.
Вешать на все биконы и в самом деле не выглядит как адекватное решение, но точечно, на какие-то важные вещи - почему нет.
highstate по расписанию - если есть потребность, почему бы нет. Но по хорошему не должно быть ситуации чтоб пакет кто-то руками удалил, или конфиг поправил. Для этого нужны скорее административные меры, а не Солтом (любой другой SCM) это как-то компенсировать
Я не совсем про удаление пакетов, скорее про условный релиз новой версии стейта, который бы автоматом заезжал на все нужные миньоны.
Это ведь тоже как-то инициировать нужно.
Но я солт пока раскурил очень слабо, возможно что-то упускаю.
источник

c

citius in Saltstack
Выглядит просто как замена крона, не?
источник

R

Roman in Saltstack
выкатка релиза это разовая операция, зачем тут расписание? Просто дернуть нужный стейт / оркестратор через банальный ssh или через Salt API
источник

KP

Kirill Proskurin in Saltstack
citius
Выглядит просто как замена крона, не?
не
источник

KP

Kirill Proskurin in Saltstack
Roman
выкатка релиза это разовая операция, зачем тут расписание? Просто дернуть нужный стейт / оркестратор через банальный ssh или через Salt API
выкатка релиза должно быть континиус процессом ^_^
источник

c

citius in Saltstack
Roman
выкатка релиза это разовая операция, зачем тут расписание? Просто дернуть нужный стейт / оркестратор через банальный ssh или через Salt API
Чтобы не морочиться с CI и сопутствующим всем.
источник

R

Roman in Saltstack
citius
Чтобы не морочиться с CI и сопутствующим всем.
звучит как костыль / не целевое использование
источник

KP

Kirill Proskurin in Saltstack
2021 - CI стал не нужен. Так и вымрем все
источник

V

Victor in Saltstack
привет
кто-нибудь пробовал создавать пользователей через states.mysql_user.present на mysql 8+
задавая пароль только password_hash
Явно указываю плагин  mysql_native_password, так же явно указываю password_column (хотя судя по логам mysql салт это никак не использует)
но все равно он преобразует хеш в sha и использует его
источник

KP

Kirill Proskurin in Saltstack
Версия соли?
источник

V

Victor in Saltstack
3002.2
источник

KP

Kirill Proskurin in Saltstack
печаль - я видел там фиксы для mysql8 в районе 3000-3001
источник

KP

Kirill Proskurin in Saltstack
сами на 5.7 так что хз
источник
2021 January 19

V

Victor in Saltstack
с паролем через password все хорошо
источник

GG

George Gaál in Saltstack
space armor
а еще вопрос,  умеет солт фиксить изменения без апплая? те например у меня в стейте есть пакет который я руками удалю с сервера, сможет ли солт поддерживать то состояние которое я описал и поставить этот пакет или мне нужно таки заново делать state.apply?
я бы state.apply гонял по крону, но это вкусовщина
источник

GG

George Gaál in Saltstack
Roman
Я сам биконы не использовал, не было необходимости, просто ознакомил человека с наличием такой возможности.
Вешать на все биконы и в самом деле не выглядит как адекватное решение, но точечно, на какие-то важные вещи - почему нет.
highstate по расписанию - если есть потребность, почему бы нет. Но по хорошему не должно быть ситуации чтоб пакет кто-то руками удалил, или конфиг поправил. Для этого нужны скорее административные меры, а не Солтом (любой другой SCM) это как-то компенсировать
+++ вынужден согласиться
источник

GG

George Gaál in Saltstack
на самом деле  high state по крону не самый тупой вариант, если еще и дифф складывать куда то для аудита
источник

GG

George Gaál in Saltstack
citius
Я не совсем про удаление пакетов, скорее про условный релиз новой версии стейта, который бы автоматом заезжал на все нужные миньоны.
Это ведь тоже как-то инициировать нужно.
Но я солт пока раскурил очень слабо, возможно что-то упускаю.
ну, есть про и контра
ПРО - если у тебя гит с описанием стейтов, и приложение самодостаточное, то применения стейта будет достаточно по расписанию. Оно само евенчуаалли рассосется наа все узлы
КОНТРА - тебе нужно подумать о том, что в момент фактического обновления (КОТОРОЕ ТЫ НЕ КОНТРОЛИРУЕШЬ) - у тебя может пропасть доступность сервиса + тебе нужно навешать мониторинг на то, что у тебя обновления доехали повсюду
К тому же, еще отдельный вопрос - что будет если ты захочешь накатить обновление до версия + 2 не дожидаясь окончания обновы до версия +1
источник

GG

George Gaál in Saltstack
вариант же с оркестрацией более стабилен, но тебе тогда нужно придумать способ фиксировать ту конфигурацию, которая получилась итоговая, либо вообще разбить системный конфиг от прикладного
источник

c

citius in Saltstack
George Gaál
ну, есть про и контра
ПРО - если у тебя гит с описанием стейтов, и приложение самодостаточное, то применения стейта будет достаточно по расписанию. Оно само евенчуаалли рассосется наа все узлы
КОНТРА - тебе нужно подумать о том, что в момент фактического обновления (КОТОРОЕ ТЫ НЕ КОНТРОЛИРУЕШЬ) - у тебя может пропасть доступность сервиса + тебе нужно навешать мониторинг на то, что у тебя обновления доехали повсюду
К тому же, еще отдельный вопрос - что будет если ты захочешь накатить обновление до версия + 2 не дожидаясь окончания обновы до версия +1
> Оно само евенчуаалли рассосется наа все узлы
вот это меня (пока) больше всего и интересует.
контра моменты понятны, тут в общем ничего нового.
в общем пробовать надо, война план покажет.
источник