Como parte do meu trabalho, gerencio algumas dezenas de servidores CentOS 5, usando fantoches na configuração principal. Cerca de metade de nossos servidores possui uma configuração padronizada para hospedar vários sites de django, enquanto o restante é uma mistura de aplicativos.
Estou gradualmente resolvendo nossas práticas de hospedagem e agora cheguei ao ponto de descobrir como gerenciar atualizações de segurança no nível do sistema operacional. Eu tenho receio de apenas ter um trabalho cron fazendo um, yum -y updatemas também não quero ter que percorrer cada servidor a tempo e revisar todos os pacotes com atualizações disponíveis, pois isso levaria um tempo.
Por isso, estou me perguntando se existem bons atalhos ou práticas de trabalho que minimizem os riscos envolvidos e a quantidade de tempo que preciso gastar. Ou, dito de outra forma, existem ferramentas ou práticas que podem automatizar grande parte do trabalho e ainda assim dar o controle.
Etapas que eu decidi até agora:
- desative todos os repositórios de terceiros e configure nosso próprio repositório para que eu possa controlar quais atualizações passam por lá.
- temos servidores de teste para (a maioria) nossos servidores de produção nos quais eu poderia fazer testes (mas quantos testes são suficientes?)
Observe também que examinei o plug - in de segurança yum, mas ele não funciona no CentOS .
Então, como você gerencia atualizações para um número significativo de servidores CentOS executando uma matriz heterogênea de aplicativos?
fonte
Respostas:
Na maioria dos meus ambientes, geralmente é um script de kickstart e pós-instalação para atualizar e atualizar o sistema principal nesse momento. Normalmente, terei um repositório local sincronizado com um espelho do CentOS diariamente ou semanalmente. Costumo congelar o pacote do kernel no momento atual da instalação e atualizar os pacotes individualmente ou conforme necessário. Muitas vezes, meus servidores têm periféricos que possuem drivers intimamente ligados às versões do kernel, então isso é uma consideração.
O CentOS 5 amadureceu a ponto de não serem necessárias atualizações constantes. Mas lembre-se também de que o CentOS 5 está acabando. A taxa de atualizações diminuiu um pouco, e a natureza das atualizações está mais alinhada com as correções e menos com as principais alterações de funcionalidade.
Portanto, neste caso específico, a primeira coisa que você pode fazer é criar um espelho / repositório local. Use seu gerenciamento de configuração existente para controlar o acesso a repositórios de terceiros. Talvez agende uma política para atualizar serviços críticos ou voltados para o público (ssh, http, ftp, dovecot etc.) Todo o resto exigirá testes, mas sinto que a maioria dos ambientes não é executada com sistemas totalmente atualizados / corrigidos.
fonte
Existem muitas ferramentas que podem ajudar com isso! Geralmente, o sistema de pacotes e quais pacotes vão para onde são tratados 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 estou mais familiarizado é o fantoche, que eu uso para gerenciar praticamente todas as configurações do meu ambiente. Aqui estão alguns exemplos de fantoches para gerenciar o yum especificamente:
http://people.redhat.com/dlutter/puppet-app.html
Atualmente, existem várias ferramentas de gerenciamento de configuração, que possuem grupos de usuários bastante grandes:
Implementá-las 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 no nível de auditoria, o que pode reduzir bastante o tempo de reparo para erros de configuração.
Em relação à sua pergunta sobre testes, eu tenho usado um ambiente de preparação que direcionamos alguns clientes para carregar (geralmente clientes beta ou um pequeno subconjunto de tráfego de produção). Geralmente, deixamos esse cluster executar novo código por pelo menos alguns dias, até uma semana (dependendo da gravidade da mudança) antes de implementá-lo na produção. Normalmente, descobri 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 levar algumas horas. Na maioria dos ambientes que vi uma semana, é tempo suficiente para descobrir até bugs incomuns na preparação / controle de qualidade.
Uma parte realmente importante sobre o teste é a replicação de dados / uso. Você mencionou que possui versões intermediárias 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 alguma carga de produção contra ela? Você pode fazer parte do cluster de produção usando o espelhamento de tráfego? Isso geralmente se torna uma troca direta entre a quantidade de recursos que a empresa está disposta a gastar em testes / controle de qualidade. Quanto mais testes, melhor, tente não se auto-limitar (dentro do razoável) e veja o que a empresa oferecerá suporte (em seguida, encontre uma maneira de fazer 10% a mais).
fonte