Docker com alta disponibilidade na AWS: o que mudar na aplicação

Colocar a aplicação em Docker não a deixa altamente disponível. Para rodar em várias instâncias, ela precisa de duas mudanças: o banco de dados sai de dentro do servidor e os arquivos saem do volume local. Aqui estão as duas, com os caminhos que a AWS oferece para cada uma.

Publiquei o vídeo em 12 de agosto de 2021, como continuação da introdução ao Docker, e parto do princípio de que sua aplicação já roda em container. Se não for o caso, comece por o que é Docker.

O ponto de partida: tudo dentro de um servidor

O cenário é o mais comum de quem acabou de adotar container. Há um servidor, que pode ser uma instância EC2, e dentro dele a aplicação web em container e o banco de dados, também em container.

O que escala é a parte web. É nela que você quer ter três, quatro ou N cópias. Só que, do jeito que está, cada cópia levaria junto o banco e os arquivos, e aí nada funciona. Por isso são duas separações.

1Tire o banco de dentro do servidor

O banco não pode ficar no mesmo lugar da aplicação que vai se multiplicar. Na AWS você tem dois caminhos:

• Uma instância EC2 separada, só com o banco.
• Um serviço de banco gerenciado, como o Amazon RDS.

O RDS tem requisitos e configurações que dão alta disponibilidade ao banco, e o Amazon Aurora também ajuda nisso.

Com isso, o primeiro problema está resolvido. Os dados do banco deixam de pertencer a um servidor específico.

2Entenda por que o volume local não escala

A aplicação web costuma guardar conteúdo: arquivos de clientes, fotos. Se esses arquivos ficam dentro do container e ele para, você perde tudo.

A solução óbvia é criar um volume ligado ao container. Os arquivos passam a ser escritos na instância EC2 e o container pode morrer sem levar as informações.

Para uma instância só, resolve. O problema aparece quando você escala.

Com três instâncias EC2, cada uma tem o seu volume. Um arquivo escrito numa delas fica disponível só ali. O tráfego é roteado para qualquer uma das três: se cair na instância que tem o arquivo, a aplicação o encontra. Se cair em outra, não encontra.

Replicar esses arquivos o tempo todo entre os volumes para fazer isso funcionar não faz sentido. Essa estrutura tem um problema de desenho.

3Grave os arquivos fora da instância

A saída é remover os volumes de dentro das instâncias e fazer com que os arquivos sejam escritos fora delas. Existem outros caminhos, mas a aula mostra dois:

1. Amazon S3.
2. Uma estrutura de armazenamento elástica. Os arquivos são escritos simultaneamente e ficam num ponto central de comunicação com todos os containers. À medida que novos containers entram, eles conversam automaticamente com essa estrutura.

Com o banco separado e os arquivos separados, a aplicação pode escalar para 3, 4 ou N instâncias. A partir daí, ela entra no cenário de alta disponibilidade.

4Escolha entre S3 e armazenamento elástico

A escolha depende do que você precisa mudar na aplicação. Imagine uma aplicação em PHP, com uma lógica que recebe o upload da foto do cliente e grava num caminho como /usr/fotos.

Com o S3, você precisa reescrever essa lógica. Em vez de gravar nesse caminho, a aplicação passa a gravar no S3. Isso implica usar o SDK, trabalhar com credenciais e permissões e migrar os arquivos que já existem. Para uma aplicação que já está pronta, isso dificulta bastante a ida para a nuvem.

Com o armazenamento elástico, o caminho /usr/fotos continua o mesmo. A forma de escrever os arquivos não muda e você não precisa redesenhar nada. Esse é o grande diferencial dele: levar a aplicação para a AWS do jeito que ela está.

Onde isso se encaixa no resto do caminho

Este é o passo seguinte a rodar a aplicação em container. Para ver como subir o container no serviço de containers da AWS, leia primeiro container em produção no ECS. Para um caso real de aplicação que saiu de um servidor único e foi para banco gerenciado, arquivos no S3 e containers em duas zonas, leia como sair da VPS e migrar para a AWS.

Checklist

• Confirme que a aplicação já roda em container com Docker.
• Tire o banco de dentro do servidor: EC2 separada ou RDS, com as configurações de alta disponibilidade.
• Identifique o que a aplicação grava no disco: fotos, arquivos de clientes.
• Não conte com volume por instância para escalar.
• Escolha onde gravar os arquivos fora da instância: S3 ou armazenamento elástico.
• Se escolher o S3, reserve tempo para reescrever a lógica de upload, com SDK, credenciais e permissões.
• Só então aumente o número de instâncias.

Se a sua aplicação grava arquivos em disco e você não sabe qual dos dois caminhos pesa menos, essa conversa vale antes de escalar.