O Puppet é, na verdade, apenas um utilitário de gerenciamento de configuração, não uma ferramenta de automação. Se você quer uma automação adequada, então você vai querer estar olhando para o coletivo que começou como uma ferramenta de terceiros, e agora foi trazido sob o guarda-chuva de puppetlabs. Não tendo trabalhado com o coletivo, eu não posso realmente falar com o quão bem ele poderia lidar com isso, mas meu entendimento é que ele funciona melhor como um mecanismo arbitrário de execução de tarefas, que não funciona tão bem ao tentar executar tarefas repetidas regularmente. .
Acredito que a melhor maneira de fazer isso seria desenvolver os scripts e processos pelos quais você deseja atualizar e, em seguida, usar o fantoche para enviar as configurações. Então, faça a si mesmo as seguintes perguntas.
- Com que frequência eu quero que as máquinas sejam atualizadas?
- Desejo que eles sejam reinicializados automaticamente quando um novo kernel for instalado ou desejo apenas uma notificação?
- Devemos estar executando algum comando especial durante as atualizações?
- Tenho sistemas suficientes para que as atualizações sejam escalonadas?
Quando você começar a criar a configuração e responder a essas perguntas, provavelmente encontrará mais coisas que sairão do seu ambiente específico. Para um exemplo específico, o que faço é isto:
- A maioria das atualizações dos meus sistemas é feita uma vez por semana, por meio do cron job. Dependendo da finalidade e do ambiente, alguns sistemas são muito mais frequentes.
- A maioria dos sistemas é reinicializada automaticamente, alguns sistemas (dependendo da finalidade) enviam um lembrete para a reinicialização. Isso é tratado por meio de uma tarefa cron que verifica o arquivo vmlinuz numerado com a versão mais alta em
/bootna saída deuname -r - Depois de ser queimado pela atualização glibc do RHEL 5.3- > 5.4, asseguro-me de atualizar o yum, depois o glibc e depois todo o resto.
- Como tudo isso é executado por tarefas cron, eu durmo com tempos aleatórios entre cada execução do yum. Cada host pode levar entre 5 minutos e 45 minutos para ser concluído, o que faz um trabalho razoável de espalhar a carga.
Tudo isso está contido em dois arquivos, as duas entradas do cron (atualizações e verificação do kernel) armazenadas em /etc/cron.d e o script de atualização. Eu estou fazendo isso com um shell script cada vez mais confuso que pega argumentos de linha de comando para executar a atualização ou verificação do kernel e se deve ou não reiniciar. O Puppet então gerencia esses dois arquivos. Como você está lidando com sistemas baseados em rpm e dpkg, eu provavelmente criaria dois scripts ou faria funções do_update separadas para os dois tipos e cada um deles teria que ser chamado com uma opção de linha de comando diferente. Em seguida, você pode enviar o script correto verificando o operatingsystem fact na sua declaração de arquivo ou modelar a entrada do cron e usar o mesmo fato para decidir qual opção usar.
Usando um script bem testado, esse método funcionou muito bem. Bem, na verdade, essa configuração foi usada com sucesso por alguns anos para lidar com centenas de sistemas. Ocasionalmente, veremos os soluços quando os empacotadores do kernel começarem a adicionar mais e mais níveis de versões secundárias aos arquivos e a rotina de comparação sufocar.