Prática recomendada para atualizações automatizadas do Linux

Estamos trabalhando para realizar atualizações automáticas para nossos servidores baseados em RHEL / RHEL.

Ideia inicial: Usando o Puppet, desabilitamos os repositórios padrão e apontamos para os nossos. Em seguida, usamos ensure => latestos pacotes que queremos atualizar automaticamente.

Problema: Estamos vendo que alguns serviços são reiniciados após uma atualização (duh).

Pergunta: Alguém tem algum conselho sobre como automatizar melhor as atualizações e estratégias do Linux para mitigar o reinício automático dos serviços? Preferimos uma solução que inclua o Puppet, mas, se precisarmos usar outro serviço, isso não é um diferencial.

Editar

Solução possível: enviei uma solução que implementa muitos dos itens sugeridos por @ voretaq7 e @ewwhite. Parece que esse é o caminho que estou seguindo no momento. Se você tiver outras sugestões, comente ou envie uma resposta.

Sua estratégia geral de atualização é sólida: você tem um repositório local (que suponho que você teste em um ambiente de desenvolvimento) e atualiza tudo com base nele (presumo que seja conhecido).

A coisa de reiniciar o serviço é inevitável: se o código subjacente foi alterado, você precisa reiniciar o serviço para que essa alteração entre em vigor. Não fazer isso pode levar a piores consequências (executar o código fora de sincronia com uma biblioteca compartilhada, causando uma falha do aplicativo).
No meu ambiente, considero que as janelas de correção trimestrais são trimestrais "Reinicie todas as coisas!" janelas também. A vantagem de tal política um é que você sabe que seus servidores vão voltar-se após um reinício, e você sabe que vai funcionar corretamente (porque você testá-los regularmente).

Meu melhor conselho para você é agendar as versões do software (talvez isso signifique que você precisará acioná-las "manualmente" com fantoches) e aconselhar seus usuários sobre a manutenção / tempo de inatividade planejados.
Como alternativa (ou como parte disso), você pode configurar a redundância em seu ambiente, para que algumas máquinas ou serviços sejam reiniciados e ainda forneçam serviço aos usuários finais. Isso pode não eliminar completamente quaisquer interrupções, mas pode ajudar a minimizá-las.

A redundância adicional também protege você no caso de falhas de hardware, inevitáveis ​​em uma escala de tempo suficiente.

Existe necessariamente um problema ao reiniciar um serviço após uma atualização do pacote? Teste em pequena escala antes de implantar para verificar se há algum problema. Recentemente, tive um problema feio com o pacote rpmforge do DenyHosts . Na verdade, ele mudou o local de seus diretórios de configuração e trabalho entre as revisões de uma atualização do yum. Esse é um comportamento totalmente indesejado. Normalmente, na mesma revisão do RHEL, não há muitos problemas, mas você nunca pode ter certeza sem testar e observar os efeitos de perto.

Outra opção é atualizar seletivamente os serviços. Você sempre precisa dos pacotes mais recentes, por exemplo? Isso volta a entender seus motivos para executar atualizações. Qual é o verdadeiro objetivo?

A vantagem de executar seu próprio repositório é que você pode organizar lançamentos ou lançamentos e gerenciar o agendamento. E se você tiver um periférico de hardware ou fornecedor de software que exija o RHEL 5.6 e esteja abaixo de 5.7? Esse é um dos benefícios de gerenciar seus próprios pacotes.

@Beaming Mel-Bin

A simplificação eliminará a necessidade de usar ssh para ferramentas de loop, para iniciar / parar o fantoche.

Primeiro, você precisará alterar seus manifestos para incluir uma variável chamada "noop", cujo valor é proveniente do ENC.

Então você teria algo parecido com isto em uma classe:

noop => $noop_status

Onde noop_statusestá definido no seu ENC. Quando você define o valor de noop_statuscomo true, o manifesto será executado apenas no modo noop.

Se você possui centenas ou milhares de hosts, pode usar um ENC como o Dashboard ou o Foreman que permite alterar parâmetros em massa para muitos hosts, herdando-os no nível "Hostgroup" ou "Domain". Você pode definir o valor como "false" para um pequeno número de hosts de teste, substituindo o valor do Hostgroup.

Com isso, quaisquer alterações são aplicadas apenas aos hosts selecionados.

Alterar um parâmetro em um local central pode afetar qualquer número de hosts, sem a necessidade de ativar / desativar o fantoche com ssh para ferramentas de loop. Você pode dividir seus hosts em vários grupos para segurança / gerenciamento.

Observe também que, em vez de codificar os números de versão do pacote em manifestos, você pode colocá-los no ENC. E, assim como acima, você pode aplicar seletivamente alterações e gerenciar lançamentos.

Se você deseja mais granularidade (e complexidade), pode até ter parâmetros por classe, como noop_status_apacheClasse assim por diante.

Pode ser mais difícil de gerenciar se você fizer includeaulas em outras aulas.

Solução possível com base na resposta de @ voretaq7:

1. Números de versão de código fixo dos pacotes nos puppetmanifestos e mantêm os pacotes em nosso próprio repositório.

2. Quando exigimos que uma nova versão de um pacote faça algo que ele oferece (por exemplo, aprimoramentos de segurança, recursos exigidos por nossos clientes, etc.), baixamos o pacote para o repositório.

3. Teste o pacote atualizado em um servidor de teste.

4. Depois que a atualização for testada, use algo como funcou psshpara desligar o puppetagente nos nós afetados.

5. Atualize os puppetmanifestos para garantir que a nova versão do pacote esteja instalada nos nós afetados.

6. Por fim, execute puppet agent --onetime && rebootno servidor usando funcoupssh

Comente e informe-me se detectar alguma deficiência nesta solução ou algo que possa ser simplificado.