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

Question

Estamos trabalhando em uma maneira de executar atualizações automáticas para nossos servidores baseados em RHEL / RHEL.

Idéia inicial: Usando o Puppet, desabilitamos os repositórios padrão e apontamos para os nossos. Então, usamos ensure => latest para os 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? Preferiríamos uma solução que incluísse Puppet, mas, se precisarmos usar outro serviço, isso não é um problema.

Editar

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

    

Answer 1

Sua estratégia de atualização geral é boa: você tem um repositório local (que eu suponho que você teste em um ambiente de desenvolvimento), e você atualiza tudo com base nesse repositório (eu presumo que seja bom).

A reinicialização do serviço é inevitável: se o código subjacente tiver sido alterado, será necessário reiniciar o serviço para que a alteração entre em vigor. Não fazer isso pode levar a conseqüências piores (executando código fora de sincronia com uma biblioteca compartilhada levando a uma falha do aplicativo). No meu ambiente, considero que as janelas de patch trimestrais sejam trimestrais "REBOOT ALL THE THINGS!" janelas também. A vantagem de tal política é que você sabe que seus servidores voltarão após uma reinicialização, e você saberá que eles funcionarão corretamente (porque você os testa regularmente) .

Meu melhor conselho para você é agendar os lançamentos de software (talvez isso signifique que você terá que acioná-los "manualmente" com fantoches) e aconselhar seus usuários sobre a manutenção planejada / o tempo de inatividade.
Como alternativa (ou como parte disso), você pode configurar a redundância em seu ambiente, de modo que possa ter algumas máquinas ou serviços sendo reiniciados e ainda fornecer serviço aos usuários finais. Isso pode não eliminar completamente qualquer interrupção, mas pode ajudar a minimizá-las.

A redundância adicionada também protege você no caso de falhas de hardware, que são inevitáveis em uma escala de tempo suficiente.

    

Answer 2

Existe necessariamente um problema com a reinicialização de um serviço após uma atualização de pacote? Teste em pequena escala antes de implantar para ver se há algum problema. Eu recentemente tive um problema feio com o pacote rpmforge de DenyHosts . Ele realmente mudou a localização de sua configuração e os diretórios de trabalho entre as revisões de uma atualização do yum. Isso é um comportamento totalmente indesejado. Normalmente, dentro da 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 remonta a entender seus motivos para a execução de atualizações. Qual é o objetivo real?

A vantagem de executar seu próprio repositório é que você pode preparar versões 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 que seja quebrado em 5.7? Esse é um dos benefícios de gerenciar seus próprios pacotes.

    

Answer 3

@Beaming Mel-Bin

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

Antes de mais nada, você precisará alterar seus manifestos para incluir uma variável chamada "noop" cujo valor é originado da ENC.

Você teria algo assim em uma aula:

noop => $noop_status

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

Se você tiver centenas ou milhares de hosts, poderá 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 grupo de hosts.

Com isso, todas as alterações são aplicadas apenas a 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 o 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_apacheClass e assim por diante.

Isso pode ser mais difícil de gerenciar se você include de classes em outras classes.

    

Answer 4

Possível solução com base na resposta do @ voretaq7:

1. Números de versão do código rígido de pacotes no puppet manifests e mantêm os pacotes em nosso próprio repositório.

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

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

4. Após a atualização ser testada, use algo como func ou pssh para desligar o puppet agent nos nós afetados.

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

6. Por fim, execute puppet agent --onetime && reboot no servidor usando func ou pssh

Por favor, comente e deixe-me saber se você detectar quaisquer deficiências nesta solução ou qualquer coisa que possa ser simplificada.