Esta é provavelmente uma pergunta simples para aqueles que já estão executando ferramentas de gerenciamento de configuração. As ferramentas de gerenciamento de configuração, como Puppet ou Chef, são a abordagem correta para manter os pacotes instalados atualizados?
Suponha que eu execute um número de servidores, principalmente baseado no Debian e no Ubuntu. As ferramentas de gerenciamento de configuração facilitam a atualização dos pacotes instalados dos repositórios quando as atualizações de segurança ou correções de bugs aparecem?
Atualmente, executo "atualizações autônomas" para permitir que os sistemas instalem automaticamente atualizações de segurança, mas ainda preciso conecte-se aos servidores e execute aptitude update && aptitude safe-upgrade de tempos em tempos. Naturalmente, isso fica chato, entediante e propenso a erros quanto mais servidores houver.
As ferramentas como Puppet ou Chef são a abordagem correta para manter os pacotes instalados atualizados? Algum de vocês usa essas ferramentas para evitar a execução manual de aptitude ou um equivalente em 15 servidores? Tenho certeza de que a resposta a essas perguntas é "Sim, claro!"
Mas onde posso encontrar mais informações sobre esse caso de uso específico? Ainda não tive tempo para estudar Puppet ou Chef em profundidade, e os livros de receitas ou classes de exemplo mostram apenas exemplos mais ou menos triviais de instalação de um pacote específico, como o ssh. Você tem algum recurso para recomendar, além da documentação oficial (eu vou, é claro, estudar os documentos assim que souber quais ferramentas são certas para mim).
O Puppet (tenho certeza que o chef também faz) está ligado aos seus repositórios de software apt-get / yum . Como eles fazem o trabalho pesado de descobrir quais pacotes estão disponíveis, isso significa que ensure => latest apenas funciona para o Ubuntu / CentOS / Debian. Contanto que você configure os arquivos apropriados corretamente ( /etc/apt/sources.list , etc).
Você pode fazer isso com fantoches, ou você faz:
ensure => latest,
ou
ensure=> "1.0.2",
para especificar a versão mais recente / exigida. ou seja,
package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }
Isso significa, pelo menos, que você pode especificar a mesma versão em todos os sistemas, além de impedir que os servidores façam atualizações (potencialmente perigosas) automaticamente. Eu usei esse método em produção em vários sites e funciona muito bem.
A execução de atualizações autônomas me assusta um pouco, especialmente se eles estiverem atualizando pacotes de missão crítica, kernels, bibliotecas mysql, apache, etc. Especialmente se o script de instalação quiser reiniciar o serviço!
Eu acho que esta é provavelmente a pergunta errada. Certamente, o uso de ferramentas de gerenciamento de configuração, como o Puppet e o Chef, para manter sua infraestrutura é um enorme passo em frente ao tentar fazer tudo manualmente. A questão de manter suas versões de pacotes atualizadas e em sincronia não é uma que qualquer dessas ferramentas resolva diretamente. Para automatizar isso corretamente, você precisa colocar os próprios repositórios de pacotes sob seu controle.
A maneira que eu faço isso é manter um repositório Yum dedicado (para Redhat / Fedora / CentOS; um repositório APT para Debian / Ubuntu) que contém os pacotes que eu gosto para um site em particular. Geralmente, essas são as dependências do próprio aplicativo (Ruby, PHP, Apache, Nginx, bibliotecas e assim por diante) e pacotes críticos para a segurança.
Uma vez que você tenha esta configuração (normalmente você pode apenas espelhar os pacotes requeridos do repositório upstream para começar), você pode usar a sintaxe "ensure = > latest" do Puppet para garantir que todas as suas máquinas estejam atualizadas com o repo.
Seria sensato usar um repositório de "teste" para permitir que você teste versões atualizadas de pacotes antes de transferi-los para a produção. Isso é feito facilmente com o Puppet sem qualquer duplicação de código usando modelos de repositório.
Automatizar a versão do seu pacote encoraja você a colocar todos os seus sistemas de produção em sincronia, já que a manutenção de múltiplos repositórios e pacotes para diferentes distribuições de SO, versões e arquiteturas de máquina é muito demorada e pode levar a todos os tipos de problemas obscuros. incompatibilidades.
Todos esses conselhos se aplicam igualmente às gemas Ruby, ovos Python e outros sistemas de pacotes que você pode usar.
Eu escrevi um pequeno tutorial Puppet , que deve ajudá-lo a se levantar e correr com o Puppet rapidamente. Você poderia implantar uma definição de repositório personalizado em suas máquinas usando o Puppet como o primeiro passo para controlar as versões dos pacotes.
Essa pergunta é antiga, mas achei que responderia de maneira atualizada, já que uma resposta existente no momento não estava disponível.
Se você estiver usando fantoche ou chef, procure em coletivo. É uma ferramenta muito legal pelos caras da puppetlabs que permite enviar comandos para grupos de servidores. link
Ele também tem um plugin apt, que pode ser usado para fazer uma atualização apt em qualquer número de servidores: link
Embora Puppet / Chef sejam candidatos possíveis para essa funcionalidade, para torná-los manter tudo no sistema, é necessário usar tipos personalizados ou listar todos os pacotes (incluindo bibliotecas de sistema subjacentes como libc6) como recursos com ensure => latest . Para o caso específico de atualizações automatizadas de pacotes, talvez você queira examinar o pacote cron-apt , que também faz o que você quer.
Eu percebo que isso é um pouco tarde para a sua pergunta original, mas aqui está no espírito de "mais tarde do que nunca".
Eu uso o Cfengine 3 para fazer isso em vários servidores. Eu especifico uma lista explícita de pacotes para atualização automática, evitando assim atualizar todos pacotes sem ser um pouco cuidadoso sobre isso. Ele funciona muito bem e o cfengine 3 é muito leve.
Aqui está um snippet de promessa da configuração do meu cfengine:
packages: "apache2" package_method => "apt", package_policy => "update";
Espero que isso ajude.
Eu concordo com o Jonathan. A abordagem do Cfengine 3 é interessante porque você pode controlar todos os aspectos do gerenciamento de pacotes sem precisar recodificar em um nível baixo.
Nós usamos puppet + apt-dater.
Você também pode usar ferramentas de gerenciamento de pacotes como o Canonicals Landscape, que é projetado para gerenciar e monitorar sistemas Ubuntu / Debian. Ele gerencia vários sistemas, permite que você os atualize simultaneamente e fornece alguns recursos básicos de monitoramento.
Geralmente, acho mais simples usar o Ansible ou semelhante para configurar as robustas atualizações autônomas pacote para Ubuntu / Debian (ou yum-cron para RHEL / CentOS). Você pode usar Puppet, Chef ou outras ferramentas, mas vou discutir Ansible aqui.
unattended-upgrades pode ser usado para fazer atualizações que não sejam de segurança ao mesmo tempo, se você preferir, o que é muito mais fácil do que executar um comando via Ansible todos os dias.
unattended-upgrades cuida de atualizações automáticas todos os dias e normalmente é restrito apenas a atualizações de segurança (para aumentar a estabilidade). Se o servidor precisar de uma reinicialização após a atualização, essa ferramenta poderá ser reinicializada automaticamente em um determinado momento.
Se as reinicializações forem mais complexas, unattended upgrades poderá enviar e-mails para você e também criar /var/run/reboot-required , para que Ansible (ou similar) possa gerenciar as reinicializações em um momento adequado (por exemplo, reinicializações contínuas de um cluster da Web ou Servidores de BD para evitar tempo de inatividade, esperando que cada servidor fique disponível em uma determinada porta TCP antes de continuar).
Você pode usar funções Ansible, como jnv.unattended-upgrades para sistemas Ubuntu / Debian, ou o simples mas eficaz geerlingguy.security , que também cobre o RHEL / CentOS (e endurece a configuração do SSH).
Se atualizações de segurança rápidas forem menos importantes, você poderá colocá-las em um processo de teste em servidores menos importantes primeiro e executar o comando unattended-upgrade depois que os testes mostrarem que não há problemas, mas é muito raro para correções de segurança orientadas ao servidor para causar problemas, na minha experiência.
Atualizações diferentes da segurança devem passar por um processo normal de integração e testes contínuos, para garantir que as coisas não sejam interrompidas.
Já vi aptitude safe-upgrade causar problemas sérios em servidores no passado, por isso é melhor não executar isso automaticamente, enquanto as atualizações de segurança geralmente são bastante seguras.