Você deve executar atualizações automáticas


15

Estou executando servidores de produção Centos. Quero saber quais são as melhores práticas para executar atualizações. Devo automatizar isso com yum-cron ou yum-updatesd? Ou existe o risco de as atualizações quebrarem os sites, por isso seria melhor atualizar em um servidor de teste e executar atualizações manualmente semanalmente?

A maioria dos servidores está usando apenas os repositórios oficiais, mas alguns têm o repositório atômico para módulos PHP que não estão disponíveis de outra forma. O que é melhor neste caso? posso configurar o yum para usar apenas o Atomic nos módulos PHP? Eu não quero que tudo atualize para o material mais avançado do Atomic, eu confiaria no Centos (ou realmente Red Hat) para manter meus servidores estáveis ​​e seguros.

Respostas:


11

Existem prós e contras nos dois sentidos, e você realmente precisa trabalhar na arquitetura do sistema para saber qual o melhor caminho para você. Qualquer que seja o caminho a seguir, você deve entender por que escolheu esse método e quais são as desvantagens para poder compensá-las.

Aqui estão algumas coisas a considerar:

  • As atualizações de segurança sempre devem ser aplicadas de uma maneira ou de outra e mais cedo ou mais tarde. Se seu servidor não estiver recebendo atualizações de segurança aplicadas em tempo hábil por qualquer motivo, corrija seus hábitos de administrador de sistema.

  • As atualizações de distribuição geralmente são boas, principalmente se forem de fontes oficiais. Se você se sentir desconfortável em aplicá-las, talvez não esteja usando a melhor distribuição para suas necessidades. Você deve usar uma distribuição que corresponda à sua metodologia. Em outras palavras, você pode confiar nas atualizações de seu interesse. Se eles se moverem muito rápido ou fizerem alterações no software que quebram suas coisas, provavelmente você deve usar uma distribuição diferente.

  • As atualizações podem quebrar suas coisas. Uma mudança para um software mais recente pode quebrar seu código se você usar recursos obsoletos ou apenas escrever coisas ruins. Você deve considerar uma arquitetura do sistema que permita testar seu produto nas atualizações antes de executá-las nos sistemas de produção.

  • Se você usa os recursos de atualização automática, sempre deve ter uma maneira de reverter para as configurações de trabalho conhecidas. As capturas instantâneas de sistema completas podem salvar vidas se alguma atualização interromper seu produto em um sistema de produção.

Esta não é uma lista exaustiva, apenas algumas coisas para você pensar. No final, essa não é uma decisão que alguém mais possa tomar por você. Você é o administrador. Conheça seus sistemas. Conheça a sua distribuição.


7

Eu concordo 100% com o que Caleb já disse. Mais alguns entalhes específicos do CentOS:

A distribuição é baseada no RedHat e seus patches. Esses patches foram testados muito bem e nos últimos 4 anos em que usamos o CentOS 5 com mais de 50 servidores, nunca houve um patch ruim.

MAS: Embora apliquemos todos os patches diariamente automaticamente aos servidores que executam apenas itens de distribuição, inicializamos os servidores de produção (após a atualização da glibc ou do kernel) somente depois que nossos sistemas de teste estão sendo executados nessa configuração por alguns dias.

Para outros repositórios, nós os espelhamos em um diretório intermediário. Esses patches são aplicados aos servidores de teste primeiro. Se for comprovado que nada quebra, ativamos o diretório intermediário e o copiamos para um repositório de produção.

O patch automático tem o efeito colateral de que os componentes corrigidos sejam frequentemente reiniciados - portanto, se você os configurou incorretamente após a inicialização, a reinicialização falhará.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.