A
Т.е. если я сделаю state apply то с большой долей вероятности в течении часа и даже дня машины онлайн не будет
Size: a a a
2021 April 19
GG
так делай его на стороне миньона
GG
МИНЬОН САМ ДЕЛАЕТ state apply
GG
другой вопрос, что ты можешь это триггернуть с мастера
A
Звучит действительно как ansible pull.. а есть где-нибудь дока по реализации именно такой pull архитектуры?
A
Puppet при моей схеме норм работает, но он мне не нравится
GG
наиболее подходящее
TL
если ты на мастере сделал
salt \* state.apply а миньон лежал, то когда он поднимется, он увидит, что у мастера опубликованы джобы? или они загарбеджколлектятся к тому времени, как миньон оживёт?GG
сдохнут к тому моменту, кмк
TL
то есть надо на миньонах костылякать
salt-call ...?A
Но мне вроде как нужно, чтобы эти машины куда-то рапортовали своё состояние, предполагал, что это будет база мастера и чтобы они конфиг всё-таки с него стягивали? Такой реализации в salt нет?
A
А так я получится на каждой машине сделаю какой-то
git pull + salt-call --local state.apply и это по-моему не совсем то.TL
Нафига?
Просто
Просто
salt-call state.applyбез всякого
--local и git pull же, не?A
--local я из доки взял https://docs.saltproject.io/en/latest/topics/tutorials/quickstart.html#salt-callA
по-моему не нужно мне это если он умеет с мастера стягивать, а не из git
TL
Normally the salt-call command checks into the master to retrieve file server and pillar data, but when running standalone salt-call needs to be instructed to not check the master for this data:
TL
выделил существенное
A
да, спасибо :)
TL
The --local flag tells the salt-minion to look for the state tree in the local file system and not to contact a Salt Master for instructions.