Balanceamento de carga do Wordpress no Amazon Web Services: Gerenciando alterações

Question

Sou relativamente novo no Amazon Web Services e estou tentando entender como o Elastic Load Balancing funcionará no contexto da minha configuração do wordpress. Além disso, gostaria de receber alguns conselhos sobre a infraestrutura proposta.

Minha infraestrutura inicial proposta é a seguinte:

• 1x EC2 m1.small - Ubuntu 12.04.3 LTS 64 bits (com 1 volume EBS)
• 1x EC2 t1.micro - Ubuntu 12.04.3 LTD 64 bits (com ou sem volume EBS?)
• 1x Instância Micro RDS - MySQL 5.6.13

EC2 Meu EC2 atual (t1.micro) está executando uma pilha LAMP e configurado para executar o wordpress.

Eu gostaria de fazer o balanceamento de carga com uma instância m1.small, executando um clone da instância t1.micro.

As incógnitas atuais para mim são as seguintes:

• Como uma configuração balanceada de carga gerenciará as alterações feitas no CMS do wordpress nas instâncias? Terei que continuar atualizando as AMIs toda vez que uma alteração for feita no wordpress?
• Meu site é um website de comércio eletrônico. Existe algum impacto disso em uma configuração de balanceamento de carga? Ou seja, existe a possibilidade de existir ordens em uma instância e não em outra?

Pode ser uma pergunta bastante estúpida, mas presumo que alguns problemas não serão relevantes porque a infraestrutura está fazendo referência a um banco de dados.

Por fim, há uma maneira melhor de configurar a infraestrutura para o balanceamento de carga? Ou seja devo considerar o uso do Amazon S3 para armazenar todos os meus arquivos e usar o Cloudfront como um CDN para garantir uma operação eficiente e resolver todos os problemas de replicação de arquivos do EBS.

Qualquer ajuda muito apreciada.

Lloyd

    

Answer 1

Aplicativos da web sem estado são difíceis.

Como você sabe, o wordpress depende bastante de coisas sendo gravadas em disco. Aqui está a infra-estrutura proposta

• Balanceador de carga elástica
  • Grupo de escalonamento automático composto por pequenas instâncias de ec2
• Foreman / Dev micro ec2 instance
• Micro / Small RDS para dados do CMS
• Cluster Elasticache para armazenamento de sessão
• Balde S3 para uploads de mídia

Agora a parte difícil.

Vamos esquecer as atualizações da base de código por um segundo e vamos dar uma olhada em como tornar a coisa toda sem estado. Você deve fazer o seguinte para tornar essa coisa escalonável horizontalmente:

1. Comece com sua micro instância. Ele atuará como mecanismo de implantação, bem como um modelo
2. Definir sessões do PHP para usar o memcached para gerenciamento de sessões e apontá-lo para seu cluster de elasticache
3. Instale o git na micro instância
4. instale algum tipo de plugin wordpress para colocar todos os uploads de arquivos no S3 (opcional, mas evita que você reimplemente cada vez que você carrega um arquivo de mídia no cms) tente o plugin W3 Total Cache

Isso cuida da configuração

Como implantar novas alterações

Você usará sua micro instância para todas as alterações futuras na instalação do wordpress. Isso inclui coisas como atualizar o wordpress, atualizar seus arquivos de tema e praticamente qualquer coisa que esteja armazenada no disco.

Você precisará criar dois scripts:

O primeiro será usado para implantar as alterações no grupo de escalonamento automático. Deve fazer o seguinte:

1. Confirme as alterações feitas no seu git repo
2. Efetue ping de todas as instâncias de produção e peça que baixem a nova base de código da micro instância. Você precisará usar alguma forma de AWD sdk para obter a lista de instâncias no grupo de dimensionamento automático e acionar seus scripts de recebimento. Eu pessoalmente faço isso com o meu através de um endpoint HTTP que eu criei.

O segundo script viverá nas instâncias do grupo de escalonamento automático e será acionado pelo primeiro script, além de ser executado quando a instância for inicializada pela primeira vez. Deve fazer o seguinte:

1. conecte-se ao repositório git na instância micro
2. buscar as alterações mais recentes e finalizar as alterações em um estado HEAD separado

Sempre que você fizer alterações no arquivo do sistema, deverá executar o script de implementação acima. Isso propagará as alterações para todas as instâncias de produção.

Agora crie uma AMI de base para as instâncias de produção. Deve ser muito parecido com o micro exemplo, no entanto o wordpress não deve ser instalado. Você usará userdata passado para as instâncias ec2 na inicialização para executar o segundo script acima para baixar a versão mais recente da base de código da instância micro.

Uma última coisa ... Se você estiver executando qualquer forma de comércio eletrônico, precisará de um certificado SSL instalado no balanceador de carga. dê uma olhada no guia aqui: link