Push de configuração de repetição automática com Ansible ou Saltstack?

Só posso responder isso pelo Ansible.

O próprio Ansible não lida com hosts que não são acessíveis. Ele tentará se conectar uma vez e, se isso não for possível, o host será expulso do jogo atual. Mas o Ansible oferece algumas ferramentas para você lidar com isso sozinho.

Primeiro, há o módulo wait_for . Com isso, você pode esperar com um tempo limite muito alto até que os hosts estejam disponíveis.

- wait_for:
    port: 22
    delay: 10
    timeout: 3600
    host: "{{ inventory_hostname }}"
  delegate_to: localhost

Isso por si só seria um problema quando você executa o jogo, porque o Ansible, por padrão, não processaria nenhuma outra tarefa até que todos os hosts passassem por essa tarefa. O que é contraproducente neste caso. De acordo com sua descrição, os primeiros hosts podem ficar novamente indisponíveis quando o último host finalmente estiver acessível.

Para isso resolver você precisa usar o Ansible 2, que possui um novo recurso chamado strategy . strategy: freepermite que você execute todas as tarefas o mais rápido possível, o que significa que executa todas as tarefas assim que o host estiver disponível.

Ainda assim, uma conexão pode cair e, nesse caso, não há uma maneira integrada de tentar novamente automaticamente. Se a conexão ssh não puder ser estabelecida, um erro fatal será lançado para este host e desde o Ansible ~1.9. não há como detectar esse tipo de erro de conexão. Isso não afeta outros anfitriões, porém, todos eles jogarão bem.

Você pode tentar novamente. Hosts com falha serão armazenados em um arquivo <playbook-name>.retrypróximo ao próprio playbook. Para repetir apenas hosts com falha, você pode executar:

ansible-playbook ... --limit @<playbook-name>.retry

Salt é executado em um modelo pull dos nós para o mestre. Você pode emitir comandos globais do mestre como

salt 'api*.domain.com` state.highstate

Isso executará um estado alto em todos os hosts que possuem um id (hostname) de api*.domain.com. Um estado elevado é como uma corrida completa de chef.

Normalmente, por padrão, as pessoas terão a programação principal de estado alto executada nos lacaios ou executarão a programação nos próprios lacaios para executar um estado alto a cada 10 minutos.

Portanto, se um nó estiver inativo e você executar um comando no mestre para executar um estado, o salt informará que o nó está inativo em sua saída de execução, que pode ser formatada de várias maneiras diferentes para você ingerir. Pode até ser registrado no mysql, por exemplo.

Por exemplo, se você executou o comando acima no servidor mestre para executar um estado alto em todos os api*.domain.comnós. Se 2 dos 5000 estivessem reiniciando no momento, uma salt-minionvez que voltassem online, eles receberiam o mesmo do mestre por meio do barramento de mensagens e executariam o estado alto.

Salt também tem uma coisa chamada nós de proxy para ajudar no carregamento de um mestre. Você pode ter um único mestre em algum lugar e um nó proxy em cada datacenter e todos os comandos enviados do mestre passam pelos nós proxy e os lacaios nesses datacenters atingem seu nó proxy e nunca o mestre

Para estender a resposta de Mike, você pode empurrar e puxar simultaneamente com Salt. Empurrar é tão fácil quanto

salt 'api*.domain.com` state.highstate

Ao mesmo tempo, seus lacaios podem fazer pull programado a cada X minutos ou horas por meio do agendador integrado . Meu método preferido é configurá-lo via pilar, mas adicioná-lo à configuração do minion também funciona. Algo como:

schedule:
  highstate:
    function: state.highstate
    maxrunning: 1
    hours: 1
    splay: 600