Multisite no AWS EC2

Question

Estou trabalhando em um aplicativo de vários sites segmentado para executar totalmente o Amazon Web Services. Devido à sua natureza, ele terá picos de tráfego significativos, seguidos por longos períodos de baixo tráfego, portanto a capacidade de escalar instâncias do EC2 é obrigatória.

Até agora, a estrutura que tenho em mente é:

                                _____________________
                                Elastic Load Balancer
                                _____________________
                                          |
                                          V
                                _____________________
                          []   []   []   []   []   []   []
                                   Autoscaling EC2
                                With Dynamic Virtual
                                        Hosts
                                Global Business Logic
                                _____________________
                                /         |          \
                               /          |           \
                       Amazon RDS         S3        Site Views?
                      One Per Site       for      
                                     static files

Agora, tenho duas perguntas:

1. Onde devo manter os arquivos "visualizações" ou "temas" específicos do site? O S3 é rápido o suficiente para lidar com isso? Ou devo realmente criar novas AMIs toda vez que eu preciso ajustar o tema de um site em particular?
2. Arquivos de configuração. Como cada site se conecta a um banco de dados separado, cada um precisa de seus próprios arquivos de configuração. Novamente, devo armazená-los no S3, e todas as instâncias do EC2 verificam o S3 para configurações atualizadas de vez em quando?

Eu sinto que há um elo perdido que não conheço. Na maioria das vezes, vejo pessoas aconselhando você a criar uma nova AMI e encerrar as instâncias atuais e substituí-las por novas. Isso parece ser um fardo pesado, especialmente em uma estrutura de vários sites, em que essas alterações podem ser específicas de apenas um único site. Existe um método preferido de lidar com esses tipos de alterações de código?

    

Answer 1

1. Uma técnica que estou pensando em usar é criar AMIs personalizadas que, após o início, farão o download dos dados necessários para auto-inicialização. No seu caso, você pode manter seus sites no S3 e baixar os arquivos na inicialização. Se você usar o CloudInit para o Ubuntu ou algo semelhante para outras distros, então você pode criar scripts do seu site facilmente. Eu acredito que ele só é executado na primeira inicialização, portanto, a terminação contínua dos nós deve ativar a versão atualizada do site. Nesse caso, você não precisará atualizar continuamente as AMIs.

2. Se você não tiver uma configuração do sistema de gerenciamento de configuração, será fácil manter um arquivo no S3 com a configuração necessária. Conforme você cultiva o Chef ou o Puppet, pode ser melhor, mas eles levam algum tempo para aprender. Este arquivo pode ser carregado da mesma maneira ou acionado com uma ferramenta como Fabric ou Capistrano.

Fabric e Capistrano podem ajudar você a acionar atualizações menores. Se você reutilizar o script CloudInit, não precisará codificá-lo duas vezes. Tanto o Fabric quanto o Capistrano podem se integrar à API da AWS com bastante facilidade para permitir a consulta dinâmica dos nós em execução, para que você não precise manter as listas de servidores em constante mudança.

Uma ferramenta para fazer AMIs lançadas recentemente chamada Packer também pode ser útil para você. Na minha primeira tentativa, consegui criar uma nova AMI em 30 minutos após o início do tutorial. Também pode ajudar a fazer AMIs para várias regiões.