Implementação de produção para o EC2 com tempo de inatividade mínimo

Question

Eu tenho um aplicativo da web simples implantado em uma grande instância com o EC2. Agora quero implantar o código mais recente neste servidor, mas quero fazer isso de uma maneira que minimize o tempo de inatividade e seja o mais suave possível para o usuário final. Aqui está o meu plano:

1. Acione outra instância grande
2. Instale todas as camadas de software nessa instância
3. Restaurar e anexar uma unidade EBS à instância
4. Implante nosso código pronto para produção mais recente na nova instância
5. Executar todos os testes (incluindo teste manual do aplicativo)
6. (Se os testes forem aprovados) Coloque um aviso "Site em manutenção" no site ao vivo.
7. Backup da instância do EBS no site ativo
8. Desanexe a instância do EBS do novo servidor e substitua pelo último backup
9. Use ec2-associate-address para mover o endereço IP para a nova instância
10. Sente-se e espere o tráfego começar a fluir pela nova instância
11. Encerrar a instância antiga

Isso parece uma boa estratégia? Existem alguns tutoriais ou livros que possam cobrir este tópico? Eu já li o Cloud Application Architectures de George Reese, que é um excelente livro, mas não abrange a implantação. Além disso, eu sei que existem ferramentas que podem ajudar com isso, como RightScale ou enStratus, que eu usarei quando começar a usar mais de uma instância.

    

Answer 1

Isso parece uma boa abordagem geral. Você pode cortar a etapa 2 e, assim, diminuir o tempo de inicialização, criando uma AMI personalizada que inclua todas as camadas de software necessárias; Dito isso, ainda atualizaria todos os pacotes na inicialização para garantir que você receba as atualizações de segurança mais recentes.

Você também pode querer pensar em usar um Instância apoiada pelo EBS - assim você poderia ter o volume de inicialização, a pilha de software e seu aplicativo no EBS, o que eliminaria alguns dos passos acima.

    

Answer 2

OK, isso foi perguntado há algum tempo, mas vou entrar em contato com meus 2 centavos de qualquer maneira. Acho que você está perdendo os benefícios da computação em nuvem.

Primeiramente, você deve separar o código do seu aplicativo e seus dados persistentes em duas máquinas virtuais diferentes. Isso vai lhe custar um pouco em latência de comunicação entre VMs, mas deve tornar sua administração muito mais simples. Lembre-se, ter 2 VMs pequenas em vez de 1 VM grande não é mais caro; escolha o número de hosts que melhor atenda às suas necessidades.

Se possível, você deseja que os servidores de aplicativos fiquem "sem estado", no sentido de que eles não devem ter dados persistentes, e você deve ser capaz de gerar uma nova instância com um mínimo de trabalho manual.

Em segundo lugar, você deve considerar se alguns dos serviços gerenciados da Amazon, como o SimpleDB ou o Relational Database Service (MySQL hospedado), são adequados para o armazenamento de dados persistente.

O fluxo ideal é algo assim:

1. Altere o sistema backend "mais recuado" primeiro. Por exemplo, se sua alteração exigir a adição de uma coluna a uma tabela de banco de dados, adicione-a usando as ferramentas normais do MySQL em uma instância do RDS em execução. (Isso pressupõe que sua arquitetura permite que seu armazenamento de dados seja alterado, mantendo a compatibilidade com versões anteriores, ou que você primeiro atualize o código do servidor de aplicativos para que seja compatível com versões futuras.)
2. Criar uma nova instância do servidor de aplicativos , usando uma AMI personalizada pronta para uso que você tenha preparado com antecedência.
3. Instale seu código atualizado no novo servidor de aplicativos, ou seja, o novo código que usa a nova coluna e tem a nova funcionalidade.
4. Teste .
5. Traga algum ou todo o tráfego, ou seja, mova o endereço IP / alterne o Elastic Load Balancing para o novo servidor de aplicativos. (Em um mundo ideal, você passaria por apenas uma pequena porcentagem, digamos, 5% do seu tráfego em primeiro lugar e depois observaria qualquer problema. O AFAIK Elastic Load Balancing não suporta roteamento fixo ponderado ainda, então você provavelmente não deve fazer isso. A alternância gradual também pode ser obtida com dois caminhos de execução em seu código, mas isso é demorado e irritante para realizar um balanceamento de carga fixo ponderado é mais simples.
6. Mantenha a antiga instância do servidor de aplicativos por alguns dias , caso o novo código tenha regressões e você precise retroceder.