Atualizar a produção do Ubuntu define o que fazer e o que não fazer

Question

De vez em quando eu faço login nas caixas web/db/tools de produção e vejo a mensagem típica:

30 pacotes podem ser atualizados. 16 atualizações são atualizações de segurança.

Minha pergunta é: como vocês lidam com atualizações em suas caixas de produção do Ubuntu? Você automatiza essas atualizações? Você define um tempo de inatividade para eles? O problema é que você nunca sabe quando uma atualização irá quebrar alguma coisa, como talvez um arquivo de configuração existente, etc.

A outra parte deste problema é que acompanhar os patches é “uma coisa boa”, mas os patches são lançados quase diariamente. Quantas interrupções programadas são necessárias se houver um novo patch de segurança disponível todos os dias?

Acho que um tópico sobre respostas sobre como você gerencia suas atualizações seria muito útil.

Answer 1

Não há nada de especial em corrigir Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian, etc.

O estado de espírito básico que você precisa ter ao projetar seu procedimento de patch é presumir algovaiquebrar.

Algumas das diretrizes básicas que costumo usar ao projetar uma configuração de patch são:

• Sempre use um sistema local para centralizar internamente em sua rede de onde os patches são instalados

Isso pode incluir o uso do WSUS ou espelhos <your_os_here>para uma máquina interna de gerenciamento de patches. É preferível um que possa consultar centralmente e informar o status dos patches instalados em suas máquinas individuais.

• Pré-preparar as instalações - quando possível - nas máquinas.

Quando for possível, à medida que os patches forem lançados, o servidor central os copiará para as máquinas individuais. Na verdade, isso economiza tempo para que você não precise esperar que eles baixem e instalem, basta iniciar a instalação durante a janela do patch.

• Obtenha uma janela de interrupção para instalar os patches, talvez seja necessário reinicializar e algo provavelmente irá quebrar. Certifique-se de que as partes interessadas desses sistemas estejam cientes de que há patches sendo implantados. Esteja preparado para as chamadas "isto" não funciona.

Mantendo minha teoria básica de que os patches quebram as coisas, certifique-se de ter uma janela de interrupção para aplicar os patches por tempo suficiente para solucionar problemas críticos e, possivelmente, reverter o patch. Você não precisa necessariamente ter pessoas sentadas testando os patches. Pessoalmente, confio muito nos meus sistemas de monitoramento para saber que tudo está funcionando no nível mínimo que podemos alcançar. Mas também esteja preparado para que pequenos problemas incômodos surjam à medida que as pessoas começam a trabalhar. Você deve sempre ter alguém agendado para estar pronto para atender o telefone - de preferência, não o cara que ficou acordado até as 3 da manhã consertando as caixas.

• automatizar o máximo possível

Como tudo em TI, script, script e script um pouco mais. Faça o script do download do pacote, do início da instalação, do espelho. Basicamente, você deseja transformar janelas de patch em uma tarefa de babá que só precisa de um humano presente, caso algo quebre.

• Tenha várias janelas por mês

Isso lhe dá a capacidade de não corrigir alguns servidores se, por algum motivo, eles não puderem ser corrigidos na "noite marcada". Se você não puder fazê-los na noite 1, exija que eles sejam gratuitos na noite 2. Também permite manter o número de servidores corrigidos ao mesmo tempo.

Mais importanteacompanhe os patchs!Do contrário, você terá que fazer grandes janelas de patch de mais de 10 horas apenas para voltar ao ponto em que foi pego. Introduzindo ainda mais pontos onde as coisas podem dar errado e tornando muito mais difícil descobrir qual patch causou e problema.

---

A outra parte deste problema é que acompanhar os patches é “uma coisa boa”, mas os patches são lançados quase diariamente. Quantas interrupções programadas são necessárias se houver um novo patch de segurança disponível todos os dias?

Corrigir um servidor uma vez por mês ou a cada dois meses é - IMHO - uma meta muito alcançável e aceitável. Mais do que isso, e bem, você estará constantemente aplicando patches em servidores, muito menos e começará a entrar em situações em que há centenas de patches que precisam ser aplicados por servidor.

Quanto de quantas janelas você precisa por mês? Isso depende do seu ambiente. Quantos servidores você tem? Qual é o tempo de atividade necessário para seus servidores?

Ambientes menores que são 9x5 provavelmente podem ter uma janela de patch por mês. Grandes lojas 24 horas por dia, 7 dias por semana podem precisar de dois. Um sistema 24x7x365 muito grande pode precisar de uma janela contínua toda semana para ter um conjunto diferente de servidores corrigidos a cada semana.

Encontre uma frequência que funcione para você e seu ambiente.

Uma coisa a ter em mente é que 100% atualizado é umaimpossívelmeta a ser alcançada - não deixe que seu departamento de segurança lhe diga o contrário. Faça o seu melhor, não fique muito para trás.

Answer 2

Coisas para fazer:

1. Faça um backup
2. Certifique-se de que seja um backup restaurável (embora esses dois sejam pontos gerais)
3. Tente desviar o tráfego da caixa de produção enquanto você atualiza.
4. Tente ter um método de acesso fora de banda caso tudo dê errado, KVM, console serial, acesso local ou mãos remotas.
5. Teste em um servidor e certifique-se de que tudo funciona antes de implantar atualizações em mais servidores
6. Use o puppet se puder para garantir que os números de versão sejam os mesmos em vários servidores. (Você também pode usá-lo para forçar atualizações)
7. Em um servidor de teste, compare as versões dos arquivos de configuração com as novas (atualização instalada) e certifique-se de que nada irá prejudicar seriamente as coisas. Parece que me lembro do dpkg perguntando antes de instalar novas versões que sejam diferentes das instaladas atualmente.

Coisas a evitar:

1. Fazendo atualizações no meio do dia, ou às 09h00 de uma segunda-feira de manhã, ou às 17h00 de uma sexta-feira à tarde! (obrigado @3influence!)
2. Atualizando o MySQL em servidores de banco de dados realmente grandes (a reinicialização pode demorar muito)
3. Fazendo todos os seus servidores de uma vez (especialmente kernels)
4. Fazer qualquer coisa que possa alterar o /etc/networks (porque você pode perder a conectividade)
5. Atualizações automatizadas que podem fazer o que foi dito acima sem que você esteja presente para verificar se está tudo bem.

Answer 3

Outro ponto que vale a pena ressaltar: se você está acostumado com o Windows, ficará surpreso ao saber que a maioria das atualizações do Linux faz isso.nãorequer tempo de inatividade ou reinicialização. Alguns sim, como atualizações do kernel. Mas as atualizações que exigem reinicialização ou tempo de inatividade geralmente são sinalizadas como tal e podem ser tratadas em uma programação separada.

Answer 4

Lidamos com atualizações da seguinte maneira para sistemas Ubuntu LTS:

1. Manter um conjunto de testes de aceitação que verificam todos os caminhos críticos em nosso software
2. Instale atualizações de segurança sem supervisão às 4h todas as manhãs e execute imediatamente os testes de aceitação. Se alguma coisa falhar, um engenheiro será avisado e terá tempo de sobra para consertar as coisas ou reverter antes das 9h. Até agora, isso aconteceu apenas duas vezes em cinco anos - o LTS está bem testado e estável.
3. Reimplantamos automaticamente toda a nossa infraestrutura toda semana (no digitalocean) com implantações azul/verde, o que mantém todos os pacotes em suas versões mais recentes. Se uma nova implantação falhar nos testes de aceitação, a implantação ficará em espera até que um engenheiro possa depurar o problema.

A próxima etapa lógica para nós é eliminar as informações da sessão na memória para que possamos simplesmente reimplantar a infraestrutura todos os dias ou até mesmo várias vezes por dia sem impactar os clientes e eliminar a etapa (2).

Essa abordagem exige pouca manutenção e evita completamente as janelas de manutenção.