Qual sistema de gerenciamento de pacotes devemos usar para fazer implantações?

Question

Somos uma pequena empresa de software com apenas um produto - um site (8 milhões de visitas por mês) com carga balanceada (cerca de 20 servidores para veiculação na Web).

No momento, fazemos lançamentos semanais, visando a implantação contínua.

Nossos servidores estão executando o Centos, nossos clientes Mac OS X.

Atualmente, estamos avaliando diferentes sistemas de embalagem:

• RPM
• subversion + algum script shell (criando uma "svn-tree-produção" separada da árvore do código fonte)
• nosso "empacotador" self-made que consiste em tar-archive mais alguns scripts - o problema atual é que não há lógica para desatualizar (instalar uma versão não atual) e nenhuma possibilidade de excluir arquivos - IMO incluindo essas coisas um pouco de trabalho

Gostaria de saber se alguns de vocês têm experiência com o uso de sistemas de empacotamento para implantações e poderiam fornecer algumas ideias.

    

Answer 1

Eu usei o pacote RPM para implantação e detestá-lo em comparação com o pacote Debian. Usando um pacote você recebe muitos benefícios, como configurar dependências, configuração do apache, logrotate, cronjobs, scripts post inst, etc, bem como apenas o código-fonte e as permissões. Poder usar o debconf para fazer perguntas ao usuário (por exemplo, em que URL eu devo servir este aplicativo da web?) E então modelar as respostas na configuração do apache é realmente útil. No entanto, tanto quanto eu posso dizer, não existe um equivalente do tipo debconf para o RPM, o que significa que você acaba tendo que editar os arquivos de configuração manualmente e não pode instalar facilmente novas versões do pacote.

Eu geralmente acho que apenas instalar a partir do controle de origem em servidores não é o caso, porque para uma aplicação complicada é apenas parte da história. Então, dadas as suas três opções acima, eu iria para 3.

    

Answer 2

Eu sugeriria Capistrano que, embora não seja um sistema de empacotamento, é especificamente projetado para implantar código em um ou vários servidores. Implanta diretamente do seu sistema de controle de versão (svn, git, mercurial, etc.) para os servidores, executa qualquer script que você precisa, executa migrações de banco de dados, etc.

Ele mantém um número de versões anteriores nos servidores, permitindo que você retroceda em segundos em caso de problemas inesperados.

Além disso, ele fornece implantações em vários servidores, implantando em vários servidores de uma só vez, transferindo-os de volta para a versão anterior se qualquer parte não for implementada adequadamente.

Capistrano é originário do mundo Ruby, mas é amplamente usado hoje em dia. Pode parecer simples, mas é uma ferramenta muito poderosa e é altamente recomendada. Minha empresa o utiliza para implantar dezenas de sites em vários servidores.

Como o Capistrano é uma ferramenta de linha de comando, usamos Webistrano , uma GUI da Web para gerenciar e executar o Capistrano em um maneira amigável.

    

Answer 3

Dada a simplicidade da sua situação, você provavelmente poderia usar montagens rsync ou NFS para distribuir o código e depois um pequeno trecho de código para "atualizar" da execução de uma versão para outra (é isso que eu suponho que você quer dizer pela opção # 2).

No entanto, se você quiser algo melhor do que isso, eu recomendo strongmente usar o sistema de empacotamento nativo para entregar o código (você obtém integração "gratuita" com todas as ferramentas de empacotamento nativas). Claro que isso leva alguma habilidade, para criar pacotes bons ... mas esse investimento deve se pagar. Do outro lado dessa moeda, usar um formato de embalagem não nativo é algo que você terá que pagar uma e outra vez.

Como outro pôster disse, você pode querer usar uma configuração. sistema de gerenciamento em cima disso (mas, novamente, qualquer bom sistema de gerenciamento de configuração deve se integrar com o empacotamento nativo ... então qualquer investimento lá ainda vai pagar).

Quanto a algumas das respostas que implicam em "regras do dpkg, o rpm é uma droga", sugiro que, se você estiver disposto a ouvi-las, mova seus servidores para o Debian e use o pacote nativo.

    

Answer 4

Eu seriamente aconselharia você a escolher um sistema de gerenciamento de configuração. Existem alguns projetos de código aberto para escolher: cfengine , fantoche , bcfg2 , ...

O Cfengine é o mais utilizado (17 anos de experiência, existem implementações de até +60000 servidores como o facebook). Não há suporte pago se você precisar cfengine.com

O Puppet é bastante popular entre os novatos no campo porque parece mais simples (isso é uma questão de gosto, IMO), mas tem um grande problema: depende do ruby, então você tem que instalar esse alvo em movimento. Veja este post no blog do mantenedor do debian ruby para obter uma opinião sobre se você deseja usar essa bagunça para gerenciar sua infraestrutura: link ; eles também pagaram o apoio.

Eu não conheço ninguém executando o bcfg2, parece legal.

O, sim, e há outra ferramenta Ruby, chef . Também uma bagunça para instalar.

O objetivo final é apenas kickstart (você usa centos) um novo servidor e deixá-lo autoconfigurar-se. O gerenciamento de configuração cuidará de tudo. Você precisa mudar alguma coisa em todos os servidores? Não tem problema, escreva uma política e ela será implantada durante a próxima execução do software. Demora um tempo para configurar (não extremamente longo, porém, mas como com todas as coisas novas, você precisa ter a sensação), mas você vai se perguntar como na terra você foi capaz de viver sem ele.

    

Answer 5

Seguindo o princípio da simplicidade de Occam e a de Einstein, eu escolheria o número 3. Até onde eu poderia tirar da minha experiência limitada com esse sistema (eu uso principalmente Deb, Arch e BSD), o RPM é um bloatware, provavelmente muito complicado para as suas necessidades. Eu mal posso ver os benefícios de introduzir uma camada SVN adicional. O mais lógico parece usar alguns scripts para construir tarballs a partir de tags SVN e alguns para entregar e implantar. IMHO.