Servidor Web Wordpress compartilhado com escala automática da AWS - scripts de usuário AMI vs

Question

Eu tenho um servidor de hospedagem Wordpress compartilhado com aproximadamente 50 sites, que é totalmente configurado via Ansible.

Estou tentando encontrar um bom limite entre

a) atualizando as AMIs toda vez que um site é adicionado ou a configuração é alterada, por exemplo, isso afetaria os hosts virtuais e os arquivos do conjunto PHP

b) executando algumas dessas alterações de configuração com um script de inicialização personalizado e simplesmente dando à instância mais tempo na inicialização antes de receber tráfego de um balanceador de carga

Atualmente, há uma única instância e, provavelmente, o escalonamento automático não é necessário por um tempo para lidar com grandes alterações nos valores de tráfego. Em vez disso, há demanda para usar o escalonamento automático para a substituição automática da instância caso ela falhe em poucas horas.

Com base na minha escala atual para um bom gerenciamento de custos, seria melhor executar um c5.large durante a noite e programar escalonamento automático para 2 c5.large durante o dia, o que me daria o benefício adicional de ter confiabilidade multi-AZ no mesmo custo de um único c5.xlarge

Estou planejando usar o EFS para compartilhar todos os arquivos do Wordpress e, provavelmente, o Redis para o gerenciamento de sessões compartilhadas, no entanto, esse não é o tópico desta pergunta.

Minha preocupação com a solução a) é que toda vez que um novo site é adicionado, um site de teste criado ou qualquer outra alteração de configuração é necessário, preciso criar uma nova instância, fazer a alteração, criar uma AMI e girar as AMIs no meu grupo de autoescala. Mesmo se totalmente automatizado, eu esperaria que isso demorasse demais para ter uma velocidade de retorno aceitável.

Em vez disso, eu poderia fazer essas alterações em um pequeno número de instâncias e atualizar a AMI programaticamente. Só então seria usado - em um cenário de falha ou - quando um teste de restauração está sendo feito ou - quando o desenvolvimento é testado em uma pilha de testes

Esta é uma boa abordagem para gerenciar um ambiente de hospedagem compartilhada?

    

Answer 1

I'm planning to use EFS to share all Wordpress files and likely Redis for shared session management, however this is not the topic of this question.

Hmm, é uma pena. Eu estava prestes a sugerir que você descarregasse todos os dados de configuração e usuário das instâncias para um armazenamento compartilhado durável e usasse as instâncias puramente como servidores da Web sem estado - fáceis de dimensionar, fáceis de substituir. A conversão do armazenamento local para o EFS é fácil (não é realmente uma nova arquitetura do sistema, movendo apenas alguns diretórios para o EFS) e pode ser feita com muito pouco tempo de inatividade.

Todos os arquivos de configuração do Apache / Nginx / PHP e do Wordpress, bem como os arquivos de mídia do usuário carregados serão então armazenados no sistema de arquivos compartilhado e as instâncias se auto-configuram a partir dali.

De qualquer forma, se você descartar imediatamente a melhor e óbvia solução , ficaremos sugerindo algumas opções inferiores. Eu tenho um modelo do CloudFormation que faz algo próximo do que você deseja:

• A instância do EC2 está no grupo AutoScaling de min = 1 / max = 1. Ou seja se ele morrer, reinicia automaticamente.
• Toda noite, um Lambda cria um instantâneo da instância como uma nova AMI e atualiza a Configuração de inicialização do ASG com o novo ID da AMI. Ou seja se a instância morrer no dia seguinte, ela será criada a partir do instantâneo da última noite.

Isso funciona bem em instâncias que não mudam com muita frequência. Por exemplo. nosso CMS tem todos os dados em um banco de dados e todos os arquivos de configuração e usuário do aplicativo no EFS e apenas alguns pacotes e arquivos de configuração do sistema são atualizados na instância de tempos em tempos, mas não com muita frequência.

Pode algo assim funcionar para você? No entanto, o esforço para implementar isso é provavelmente maior do que migrar para o EFS em primeiro lugar e o resultado não é tão bom e tão resiliente.

Espero que ajude:)