Você está pensando sobre isso da maneira errada, Salt não foi projetado para fornecer a você um histórico das mudanças que você fez em uma máquina, mas sim ditar um estado "alto" em que a máquina deveria estar. mudanças feitas localmente, registro de alterações feitas localmente no git, enquanto o sal faz com que suas caixas sigam quaisquer mudanças no repositório do git. Se o lacaio tiver alguma mudança local, ela será mostrada quando você fizer um highstate. Você consegue adivinhar qual deles é escalável?
Então aqui está um exemplo simples de como fazer isso (isso acontece para usar bitbucket para git):
1) Configure seu mestre de sal / etc / salt / master com:
file_roots: base: - /srv/salt fileserver_backend: - git - roots gitfs_remotes: - [email protected]:user/your-salt-repo.git pillar_roots: base: - /srv/pillar
2) Na raiz do seu repositório git, crie um top.sls simples:
base: '*.domain.com': - core
3) Crie alguns diretórios adicionais dentro do seu repositório git:
mkdir core mkdir servers mkdir servers/default mkdir servers/minion01
4) Crie um arquivo core / init.sls simples:
/etc/ssh/ssh_config: file.managed: - source: - salt://servers/{{ grains['id'] }}/ssh_config - salt://servers/default/ssh_config
5) Crie um ssh_config padrão em servers / default / ssh_config.
6) Crie um ssh_config específico para o minion em servers / minion01 / ssh_config
7) Confirme e envie as alterações de volta para o seu repositório git (bitbucket).
8) A partir da execução do mestre de sal: sudo salt '*' state.highstate test=true
para ver quais alterações serão aplicadas.
Quando o minion01 entra em contato com o salt master, ele obtém servidores / minion01 / ssh_config, mas qualquer outro minion (digamos minion02), onde não há nenhum arquivo ssh_config em /servers/minion.id.whatever/ e passa para a próxima lista. fonte (servidores / padrão). Em vez de fazer isso por minion_id, você também pode fazer isso com base em outros grãos como os, fqdn, domain, etc (veja uma lista de grãos em um minion com salt 'minion-id' grains.items
).
Depois de capturar o estado inicial desses arquivos, você pode fazer alterações em um local central (o repositório do git) e, em seguida, executar o state.highstate para executar outras alterações. Essa dor inicial vale o esforço. Você pode automatizar algumas delas, mas o que você realmente quer fazer é encontrar outliers que, por definição, exigem alguma intervenção manual para identificar. Eu recomendo que você comece com algo como ssd_config e execute state.highstate test=true
um minion por vez. Se houver alterações do padrão, você mostrará o diff e poderá julgar se isso justifica uma exceção ao padrão.
Nota: Você precisará configurar chaves ssh para o usuário root no mestre de sal para ter permissão para ler seu repositório git (o bitbucket chama essas chaves de implementação).