Se você executar atualizações automáticas

14

Estou executando servidores web de produção do Centos. Quero saber qual é a prática recomendada para executar atualizações. Devo automatizar isso com yum-cron ou yum-updatesd? Ou existe o perigo de atualizações quebrando sites, então 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 definir o yum para usar somente o Atomic para os módulos PHP? Eu não quero tudo atualizando para o material de ponta em Atomic, eu confiaria em vez Centos (ou realmente Red Hat) para manter meus servidores estáveis e seguros.

    
por ollybee 27.04.2012 / 12:51

2 respostas

11

Existem prós e contras para os dois lados, e você realmente precisa trabalhar na arquitetura do seu sistema para saber qual é o melhor caminho para você. Seja qual for o caminho que você tomar, você deve entender por que você escolheu esse método e quais são as desvantagens para que você possa compensá-lo.

Aqui estão algumas coisas a serem consideradas:

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

  • As atualizações de distro costumam ser boas, especialmente se forem de fontes oficiais. Se você se sentir desconfortável em aplicá-las, talvez não esteja usando a melhor distro para suas necessidades. Você deve estar usando uma distro que corresponda à sua metodologia. Em outras palavras, uma que você pode confiar nas atualizações para ser de seu interesse. Se eles se movem muito rápido ou fazem alterações de software que quebram suas coisas, você provavelmente deveria estar usando uma distro diferente.

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

  • Se você usar os recursos de atualização automática, deverá sempre ter uma maneira de reverter para configurações de trabalho conhecidas. Instantâneos completos do sistema 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, esta não é uma decisão que alguém possa fazer por você. Você é o administrador. Conheça seus sistemas. Conheça sua distro.

    
por 27.04.2012 / 14:40
6

Concordo 100% com o que o Caleb já disse. Mais alguns pontos específicos do CentOS de mim:

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

MAS: Embora nós apliquemos todos os patches diariamente automaticamente em servidores que executam apenas coisas de distribuição, nós inicializamos servidores de produção (após glibc ou atualização de kernel) somente depois de termos nossos sistemas de teste rodando naquela configuração alguns dias.

Para outros repositórios, os espelhamos em um diretório temporário. Essas correções são aplicadas primeiro aos servidores de teste. Se for comprovado que nada quebra, ativamos o diretório temporário e o copiamos para um repositório de produção.

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

    
por 27.04.2012 / 22:40