Boa prática para gerenciar atualizações de pacotes para muitos servidores CentOS

Question

Como parte do meu trabalho, gerencio algumas dezenas de servidores CentOS 5, usando o fantoche para a configuração principal. Cerca de metade dos nossos servidores têm uma configuração padronizada para hospedar vários sites de django, enquanto o resto é uma mistura de aplicativos.

Estou gradualmente resolvendo nossas práticas de hospedagem, e agora chego ao ponto de descobrir como gerenciar atualizações de segurança no nível do sistema operacional. Eu tenho receio de ter apenas um cron job fazendo um yum -y update , mas também não quero ter que dar a volta a cada servidor a tempo e revisar cada pacote com atualizações disponíveis, pois isso levaria um tempo.

Por isso, estou me perguntando se existem atalhos ou práticas de trabalho que minimizem os riscos envolvidos e minimizem a quantidade de tempo que preciso gastar. Ou, para colocar de outra forma, existem ferramentas ou práticas que podem automatizar muito do trabalho enquanto ainda dá controle.

Etapas que decidi até agora:

• desabilite todos os repositórios de terceiros e configure nosso próprio repositório para que eu possa controlar as atualizações que passam por lá.
• temos servidores temporários para (a maioria) nossos servidores de produção onde eu poderia fazer testes (mas quanto teste é suficiente para testar?)

Observe também que eu examinei o plug-in de segurança do yum mas não funciona no CentOS .

Então, como você gerencia atualizações para um número significativo de servidores CentOS que executam uma matriz heterogênea de aplicativos?

    

Answer 1

Na maioria dos meus ambientes, geralmente é um script de kickstart e pós-instalação para atualizar o sistema principal e atualizá-lo no momento. Eu geralmente tenho um repositório local que sincroniza com um espelho do CentOS diariamente ou semanalmente. Eu tenho a tendência de congelar o pacote do kernel no que for atual a partir do momento da instalação e atualizar os pacotes individualmente ou conforme necessário. Muitas vezes, meus servidores têm periféricos que têm drivers intimamente ligados às versões do kernel, então isso é uma consideração.

O CentOS 5 amadureceu até o ponto em que atualizações constantes não são necessárias. Mas também tenha em mente que o CentOS 5 está diminuindo. A taxa de atualizações diminuiu um pouco, e a natureza das atualizações é mais inline com correções de bugs e menos sobre as principais mudanças na funcionalidade.

Portanto, neste caso específico, a primeira coisa que você poderia fazer é criar um repositório / espelho local. Use seu gerenciamento de configuração existente para controlar o acesso a repositórios de terceiros. Talvez agendar uma política para yum atualizar serviços críticos ou públicos (ssh, http, ftp, dovecot, etc.). Tudo o mais exigirá testes, mas tenho a impressão de que a maioria dos ambientes não é executada com sistemas totalmente atualizados / corrigidos.

    

Answer 2

Existem muitas ferramentas que podem ajudar com isso! É geral o sistema de pacotes e quais pacotes vão para onde são gerenciados pelo gerenciamento de configuração. Essas ferramentas geralmente cobrem mais do que apenas o yum e os rpms, e economizarão tempo e evitarão muitas dores de cabeça!

A ferramenta com a qual eu estou mais familiarizado é o fantoche, que uso para gerenciar praticamente todas as configurações do meu ambiente. Aqui estão alguns exemplos de fantoches para gerenciar especificamente o yum:

link

Existem várias ferramentas de gerenciamento de configuração disponíveis no momento. Elas têm grupos de usuários muito grandes:

• Cfengine link
• Puppet link
• link do Chef (Algumas das pessoas que conheço implementaram e adoram isso recentemente)

Implementá-los em um ambiente adicionará anos à sua vida. Reduz o número de dores de cabeça de sistemas mal configurados e permite fácil atualização / atualização. A maioria dessas ferramentas também pode fornecer algumas funcionalidades de nível de auditoria, o que pode reduzir bastante o tempo de reparo de erros de configuração.

No que diz respeito à sua pergunta sobre testes, tenho usado um ambiente de preparação para o qual direcionamos alguns clientes (geralmente clientes beta ou um pequeno subconjunto de tráfego de produção). Geralmente, permitimos que esse cluster execute um novo código por pelo menos dois dias, até uma semana (dependendo da gravidade da alteração) antes de implementá-lo na produção. Normalmente, acho que essa configuração funciona melhor se você tentar descobrir quanto tempo a maioria dos erros leva para descobrir. Em sistemas muito usados isso pode ser uma questão de horas, na maioria dos ambientes que eu vi uma semana é longa o suficiente para descobrir até mesmo erros incomuns na preparação / controle de qualidade.

Uma parte realmente importante sobre o teste é a replicação de dados / uso. Você mencionou que tem versões de teste da maioria de seu hardware de produção. Eles também têm cópias idênticas dos dados de produção? Você pode reproduzir qualquer carga de produção? Você pode fazer parte do cluster de produção usando o espelhamento de tráfego? Isso geralmente se torna um trade-off direto entre a quantidade de recursos que a empresa está disposta a gastar em testes / controle de qualidade. Quanto mais testes, melhor, tente não limitar-se (dentro da razão) e ver o que a empresa irá suportar (então encontre uma maneira de fazer 10% a mais).