Gerenciando atualizações em centenas de servidores Debian


20

Quais são as melhores práticas para manter dezenas (senão centenas) de servidores debian atualizados? Tendo em mente que:

  • Existem grupos de servidores (ou seja, servidores da web idênticos, servidores de banco de dados, ...)
  • Pode haver vários problemas do Debian (lenny, etch)
  • Executar um loop em todos os servidores e executar o apt-get update && upgrade não é aceitável (porque é o que estou fazendo no momento :)) Deve ser melhor que isso!

Atualmente, quando finalmente termino todas as atualizações, uma nova atualização de segurança é publicada e preciso fazer tudo de novo.

Agradecemos antecipadamente à comunidade serverfault!


11
Tenha um servidor local para armazenar os pacotes mais recentes e usá-lo como um repositório apt; isso economizará largura de banda e tempo; use o repositório local para distribuir atualizações para os servidores locais. Ah, e use o aptitude em vez do apt-get.
28409 Karolis T.

3
Sim para espelho e não para aptidão. Nenhum benefício hoje em dia. Nem sequer tem super poderes de vaca.
David Pashley

Respostas:


12

Eu uso o apt-dater para gerenciar a atualização de todas as minhas caixas Debian. Parece fazer o truque bem o suficiente. Ainda não tentei escalá-lo para centenas de hosts.


11
Produto interessante, embora eu nunca tivesse ouvido falar.
Wzzrd 28/10/09

É muito bom ! Eu promoveria essa resposta se o apt-dater não tivesse um pacote local para instalar em cada host ... e eu não entendo por que é necessário.
Falken

Após o teste, esta ferramenta é incrível! Mas funciona para dezenas de servidores, não para centenas. Ao manusear muitas máquinas, tudo fica esquisito e lento ... muito ruim.
Falken

11
Eu promovo esta resposta porque finalmente consegui usá-la, mas outras soluções também são boas, dependendo de suas preferências / ambiente!
Falken

2
Foi o agente ssh padrão no ubuntu que fez tudo errado. Eu simplesmente o removi e usei o fácil "ssh-add". Toda a lentidão desapareceu!
Falken


3

Estávamos testando usando o fantoche para atualizar correções de segurança em pacotes não essenciais. Executaríamos o apticron para enviar por e-mail uma lista de atualizações para todos os servidores e, em seguida, executar diariamente um script que mesclasse essas atualizações em um arquivo de manifesto de fantoche que fornecesse o pacote e a versão para cada distribuição. Isso atualizaria vários arquivos nos servidores individuais e iniciava um script de atualização quando um pacote precisava de atualização. Isso funcionou razoavelmente bem, mas não o testamos tanto quanto eu gostaria. Esse esquema contornou a limitação do Puppet de não ter o mesmo recurso definido em vários locais.

Eu também não estava confortável em fazer atualizações automáticas de coisas como MySQL ou PostgreSQL, onde uma atualização aleatória interromperia um serviço, possivelmente no meio do dia. Isso ainda exigiria atualizações manuais.

Spacewalk e Debmarshall parecem alternativas adequadas para o nosso esquema de marionetes.


Nenhum comentário sobre a resposta, apenas um grito tardio de "feliz 10K".
Evan Anderson

1

Aparentemente, o Spacewalk agora tem suporte preliminar para o Debian. Talvez, juntos, com Puppet, esse seja o meu ponto de partida. Eu tenho certeza que o cara que está desenvolvendo o suporte ao Debian para Spacewalk o amará por trabalhar com ele para levar o suporte ao Debian a um nível superior.


1

Na maneira de sistemas de configuração baseados em pull, como o Puppet, também existem o bcfg2 e o cfengine. Um ou outro deles pode atender bem às suas necessidades. Estou lançando o bcfg2 no meu laboratório agora.


1

Uma solução pode ser dada por func


Eu não faria func. É uma maneira de imaturo para uso em produção, embora eu admita que seja promissor.
Wzzrd 29/10/09

func é usado por sapateiro, não é IMHO imaturo. O sapateiro é muito utilizado por especialistas em RH e essas tecnologias serão incluídas na próxima versão do RHEL. Talvez não esteja "formalmente" pronto para produção, mas está quase perto de ser verdade.
drAlberT 29/10/09

0

Não tenho certeza de que tipo de solução você está esperando. Você provavelmente conhece os trabalhos cron, mas eu não atualizaria os sistemas às cegas, pois são necessárias intervenções humanas (e é por isso que eles pagam para você fazer isso, certo?)

Se você tivesse sistemas completamente idênticos, poderia considerar o uso de algo como o rsync para trazer as diferenças, mas descobrir quais arquivos não são para o rsync pode ser difícil, e eu não faria isso enquanto os serviços estão em execução. Pelo menos os scripts de atualização são configurados para gerenciar a reinicialização dos serviços e a mesclagem nas diferenças do arquivo de configuração.

Talvez se você explicar qual é o problema com os comandos apt-get, poderemos ver o que você deseja evitar.

Se o problema for largura de banda e tempo para fazer o download, talvez você deva configurar uma caixa para atuar como seu repositório Debian local. Existem guias Debian sobre como fazer isso.

Aqui estão algumas dicas sobre como minimizar o número de coisas que você precisa atualizar.

Ao instalar o Debian, não instale o Desktop, a menos que você realmente precise usar o X nesse console. A maioria dos servidores não precisa do X instalado. Isso pode diminuir significativamente o número de pacotes no sistema e, portanto, você não precisa atualizar tantos pacotes.

Verifique se o sources.list está incluindo apenas os repositórios que você realmente precisa. Se você já experimentou algum repositório e esqueceu disso, pode estar trazendo atualizações que não precisa ou não deseja.

Se você tiver problemas ao fazer atualizações às cegas em um servidor de produção, tenha cuidado em consultar os guias de atualização do Debian quando houver uma grande atualização (4.0 a 5.0). Eles passarão muito bem se você seguir as instruções de atualização. Não é tão fácil quanto executar o apt-get dist-upgrade e ir embora. Às vezes, nas instruções, existem dicas sobre quando executar o aptitude em vez do apt-get - existem pequenas diferenças nelas.



-1

ClusterSSH. Você faz logon em todos os servidores e dá a eles exatamente os mesmos comandos, para poder também reagir às caixas de diálogo. Se um servidor receber uma pergunta extra, basta clicar nele e ele será o único que responderá.

Usei-o para atualizar 25 servidores da web do etch para o lenny. Funcionou como um encanto.

http://sourceforge.net/projects/clusterssh/


O agente SSH realmente morre se você tentar fazer coisas estranhas, como conectar-se a ~ 50 máquinas de uma só vez. Caso contrário, eu gosto do ClusterSSH, embora precise de outro nível de agrupamento.
LapTop006 28/10/09

-1

O cluster ssh é uma boa sugestão.

O debmarshal ainda não faz parte do debian - nem tenho certeza se será um pacote - parece ser um sistema completamente diferente com um repositório especializado. Como o orador disse, atualmente isso é hostil ao usuário, não amigável.

O Spacewalk parece ser um clone da Redhat Network, pelo menos na interface da web. Eu tive maus resultados ao usar o Redhat Network para atualizar sistemas. Certa vez, ele desligou, sem motivo aparente, e causou uma interrupção do serviço. Fiz uma atualização do yum imediatamente depois e ela lidou com isso muito bem, então só posso assumir que o problema era de algo que vomitava no lado da RHN. A outra coisa que eu não gosto nas atualizações do RHN é que você não sabe quando a atualização acontecerá, para observar os problemas.


-1 Falso: as atualizações do RHN não são automáticas, a menos que você as faça automáticas. Além disso: como alguém que usa o RHN diariamente, ainda não o vi vomitar em mim.
Wzzrd 28/10/09

Não disse que o RHN era automático. Mas se você configurar as atualizações do RHN, não há como dizer quando elas acontecerão, então parece o mesmo. Sua sorte aparente não desfaz minha experiência real, pois ela falha e deixa os usuários sem serviço. Até a atualização yum pode falhar. Quem pensa que você pode simplesmente atualizar e ir embora não está sendo cuidadoso ou simplesmente não está preocupado porque não é um servidor de produção (produção = existem clientes que dependem dos serviços).
Labradort
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.