Usando o Chef para operações com vários nós

7

Eu tenho um aplicativo que gostaria de configurar usando o Chef que abrange vários nós. Digamos que o processo de fazer isso consiste em

  1. Faça uma coisa no nó A capturando a saída
  2. Faça outra coisa no nó B com essa saída
  3. Voltar ao nó A agora para alguma operação
  4. Agora no nó B novamente
  5. ...

Uma maneira de fazer isso seria escrever uma receita que armazenasse o estágio em que estava em cada nó e continuar executando-a nos dois nós repetidamente até que, eventualmente, tivesse a chance de fazer todas as operações em todos os nós. Mas isso é desajeitado e não será dimensionado se houver um nó C, D etc. Eu obv sei sobre notificar para sequenciar dependências dentro de um único nó, mas isso não funcionará em vários nós. Não posso ser a única pessoa que precisa disso, então existe um mecanismo ou um padrão de design / melhores práticas / TTP para esse estilo de atividade?

chef Gaius
fonte

Respostas:

6

Em resumo, o Chef pode não ser a ferramenta a ser usada aqui.

Chef é um modelo convergente, portanto, você deve escrever suas receitas de maneira idempotente, como após algumas execuções, ela estará no estado desejado, de acordo com os outros nós ao redor.

Sua abordagem sobre o armazenamento do estado parece o caminho a percorrer, e você terá que usar um orquestrador externo para agendar o chef-cliente executa, em alternativa, A e B.
Se você tem um chef-servidor, os trabalhos de pressão poderia ser o caminho a ir colando no ecossistema do chef, a principal vantagem que vejo em relação a outros orquestradores é um modelo pull que não precisa de uma porta administrativa de entrada nem de ssh nos nós de destino.

Tensibai
fonte
3

Este é um exemplo de manual de orquestração de servidores e é algo que o Chef inerentemente não se destina a fazer. Conforme observado por Tensibai, um servidor executando o Chef é um sistema convergente que alcança seu próprio estado desejado com base nas definições de configuração definidas por receitas, atributos, data bags, etc. Sem entrar em detalhes específicos sobre sua infraestrutura, algumas abordagens ser capaz de tomar são:

Crie operações independentes independentes

Como você afirmou em sua pergunta, a criação de um estado de operação em que seus nós possam ser executados repetidamente até que todas as tarefas sejam concluídas não é dimensionado corretamente. No entanto, pode ser possível redesenhar seus nós para que isso não importe. Se os nós a e b executam tarefas para produzir seus logs em paralelo, e b é concluído antes de a, ele pode executar a tarefa que o nó a normalmente executaria e vice-versa.

Use um orquestrador externo para delegação

O uso de um nó delegador definitivamente será muito melhor se você pretender ter muitos nós para orquestrar. No entanto, isso pode criar conflitos com a execução do cliente chef nos nós que estão sendo gerenciados pelo delegador. Seria muito difícil verificar se as configurações do nó e as tarefas do nó do delegador não entram em conflito. Uma maneira inteligente de gerenciar isso pode ser incorporar as tarefas na configuração de cada nó e fazer com que o delegador defina um valor em um pacote de dados ou atributo do servidor para sinalizar como ele deve se configurar (ou seja, quais tarefas ele precisa executar) )

Combine sua infraestrutura

Se cada nó executar tarefas em série, dependendo dos outros nós, e você não terá dependências técnicas / de custo em tarefas em execução em nós diferentes, convém considerar a combinação de suas configurações de nó em um único nó. Isso eliminaria quaisquer conflitos de configuração que você teria entre qualquer um dos seus nós. Eu imagino que haja intenções claras para executar suas tarefas em nós diferentes, mas essa é definitivamente uma opção a considerar (talvez mesmo com o tempo gasto para reescrever tarefas para nós diferentes).

PrestonM
fonte
Talvez. Costumo pensar em orquestração mais como executar coisas do que executar a configuração inicial delas.
Gaius