Use o Puppet e o MCollective juntos. Puppet pode fazer a maior parte do seu trabalho de construção. O MCollective permite escolher nós e agendá-los.
Recentemente, experimentei várias ferramentas de gerenciamento de nuvem, como RightScale, Scalr, scripts personalizados para gerenciar vários servidores, cada um hospedando várias funções (aplicativo, banco de dados, balanceador de carga, filas de trabalho etc.).
A única coisa que eu acho que falta na maioria das soluções é uma maneira de fazer implantações contínuas, ou seja, executar implantações sequencialmente em vários servidores com a mesma função. Por exemplo, eu não quero construir todos os meus servidores ao mesmo tempo, pois isso quase certamente resultará em algum tempo de inatividade ou 500 para os meus clientes. Eu prefiro ter um ou dois servidores construídos por vez, enquanto outros servidores ainda estão disponíveis para lidar com solicitações.
A outra alternativa é obviamente lançar novos servidores que se atualizam automaticamente na inicialização, mas isso não é tão econômico, e provavelmente requer mais tempo para a construção ser concluída (é mais rápido construir em um servidor existente do que lançar um novo servidor e matar os antigos).
Todos nós já ouvimos falar das grandes empresas que têm o famoso botão "push to build" (empresas como Twilio, Etsy, etc.), mas parece que todas elas têm implementações personalizadas disso. Eu não estou falando sobre um simples ssh-loop, clusterssh, ou mesmo um coletivo - de preferência eu quero algo com uma interface simples que me permita especificar algo como um script RightScript ou Scalr para rodar em um conjunto de servidores com um papel específico, e os constrói sequencialmente.
Alguém sabe de maneiras fáceis de fazer isso, ou isso é um candidato para um novo projeto de código aberto?
Use o Puppet e o MCollective juntos. Puppet pode fazer a maior parte do seu trabalho de construção. O MCollective permite escolher nós e agendá-los.
Eu implantei o webistrano , mas nunca consegui que nossos desenvolvedores trabalhassem com ele. eles sempre encontravam alguma maneira de causar confusão na implantação.
Não estou ciente de nenhum serviço que ajude nesse tipo de atualização. O problema é que o aplicativo precisa ser projetado com isso em mente. O que você vê são muitos servidores sendo configurados para usar o servidor x como o servidor db ou o servidor y como o servidor de cache. Este é o maior problema que vejo quando começo a olhar para o nosso software legado e penso em como podemos automatizar os processos de atualização, etc.
Tivemos o mesmo problema que você. A solução para nós não foi muito difícil porque todo o nosso último produto foi projetado para esse tipo de atualização no começo, porque vimos como pode ser difícil. Nós tentamos evitar serviços acoplados em nosso desenvolvimento. O que isso nos permite fazer é lançar um novo grupo de servidores em uma área de preparação. Quando terminarmos de testar a área de preparação, promoveremos a área de preparação para a produção, alterando um CNAME no servidor de DNS. Esse processo acontece sem qualquer tempo de inatividade e com baixo risco de atualizar os servidores com uma configuração incorreta, etc. Conseguimos isso usando http como o protocolo de comunicação principal e um servidor de DNS local.
Eu percebo que provavelmente não é tarefa fácil redesenhar todo o seu aplicativo para se adequar a uma arquitetura específica que funciona bem com atualizações contínuas, mas é a solução mais fácil. O famoso "push to build" botão não tem que ser apenas para o peixe grande, até mesmo o pequeno atum pode obter um pouco dessa ação. Dependendo da complexidade ou simplicidade do seu aplicativo, você definirá a dificuldade ou a facilidade de criar seu próprio botão "push to build".
Tags amazon-ec2 cloud scalr