Implantação sem tempo de inatividade: atualize seu aplicativo dockerizado com a técnica azul-verde

Em um artigo que escrevi há um mês, falei sobre como implantar continuamente seu aplicativo da web Python em um ambiente de produção (ou pré-desenvolvimento/preparação).

Recentemente, fui encarregado de criar um microsserviço (usando Python e FastAPI) para combinar duas vozes e fornecer uma pontuação de previsão se ambas correspondessem ou não. As partes interessadas solicitaram um recurso de desbloqueio de voz.

Tivemos uma reunião de engenharia e me levantei para assumir a tarefa (ou minha liderança me defendeu, haha).

Foi uma tarefa interessante, pois nunca havia trabalhado (treinado ou não) com um modelo de ML antes. Levei uma semana para projetar, construir e enviar o código para uma instância AWS EC2. Sou um grande fã de CI/CD, então usei o que mais me agradava - GitHub Actions.

Uma semana depois… Mudanças foram solicitadas e eu queria experimentar uma nova técnica [de implantação] que vinha pesquisando. Eu precisava que o aplicativo de microsserviço dockerizado fosse executado normalmente na instância EC2 da AWS para não sofrer nenhum tempo de inatividade ao reimplantar.

E eu tinha o truque perfeito na manga.

Esse truque é: a técnica azul-verde .

De acordo com o AWS Whitepaper on Blue/Green Deployments, é uma estratégia de implantação na qual você cria dois ambientes separados, mas idênticos.

Um ambiente (azul) está executando a versão atual do aplicativo e um ambiente (verde) está executando a nova versão do aplicativo. O uso de uma estratégia de implantação azul/verde aumenta a disponibilidade do aplicativo e reduz o risco de implantação, simplificando o processo de reversão se uma implantação falhar.

Após a conclusão do teste no ambiente verde, o tráfego do aplicativo ativo é direcionado para o ambiente verde e o ambiente azul é obsoleto.

Em termos simples, a técnica de implantação azul/verde é uma forma de reduzir o tempo de inatividade e o risco executando dois ambientes de produção idênticos.

Se esta é a primeira vez que você ouve tal técnica de implantação, não há absolutamente nada a temer, fornecerei a você etapas detalhadas que o ajudarão a alcançar a implantação verde-azulada.

Vamos direto aos passos:

1. Comece criando uma nova imagem docker com seu código atualizado e marque-a com um novo número de versão.

   
   

 $ docker build -t myexample:v2 .

Isso criará uma nova imagem do Docker com a tag myexample:v2 usando o Dockerfile no diretório atual.

Onde myexample:v2 é o nome da imagem do docker recém-criada. No meu caso, era o nome do projeto ML. Por exemplo, docker build -t companyx-servicename-backend:v2

2. Inicie um novo contêiner do Docker a partir da nova imagem, mas não o exponha ao mundo exterior ainda.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

Isso iniciará um novo contêiner do Docker com o nome myexample-v2 da imagem myexample:v2 .

3. Aguarde até que o novo contêiner inicie e inicialize, certificando-se de que esteja funcionando corretamente.

   
   

 $ docker logs myexample-v2

Use o comando docker logs para verificar os logs do novo contêiner para garantir que ele foi iniciado e inicializado corretamente.

4. Use um proxy reverso, como NGINX, para rotear o tráfego para os contêineres antigos e novos. Configure seu proxy reverso para ouvir as solicitações e encaminhá-las para os contêineres antigos e novos. Isso permitirá que você mude gradualmente o tráfego para o novo contêiner.

Aqui está um exemplo de uma configuração NGINX que roteia dois contêineres:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Essa configuração configura um grupo upstream chamado myexample com dois servidores: myexample-v1 e myexample-v2 . A palavra-chave backup é usada para marcar o segundo servidor como um backup. A diretiva proxy_pass é usada para encaminhar solicitações para o grupo upstream myexample .

Certifique-se de atualizar a configuração do proxy reverso para refletir o nome e a porta do seu aplicativo.

5. Desloque gradualmente o tráfego do contêiner antigo para o novo, ajustando a configuração do proxy reverso.

   
   

Para deslocar o tráfego para o novo contêiner, ajuste a configuração do proxy reverso para dar mais peso ao novo contêiner. Isso pode ser feito removendo a palavra-chave backup da diretiva server:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Isso fará com que o NGINX envie mais solicitações para o contêiner myexample-v2 . Monitore seu aplicativo e ajuste a configuração conforme necessário até que todo o tráfego esteja fluindo para o novo contêiner.

6. Depois que todo o tráfego estiver fluindo para o novo contêiner, você poderá parar e remover com segurança o contêiner antigo.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

Isso interromperá e removerá o contêiner antigo, liberando recursos no servidor.

Conclusão

Sou novo nessa técnica e, obviamente, não sei muito sobre ela. Mas continuarei a aprender sobre suas vantagens e desvantagens e outras técnicas que funcionarão melhor. Você tem um ou dois truques na manga que gostaria de compartilhar comigo?

Eu aprecio isso. Deixe-me tê-lo (na seção de comentários).

Ah, ah. Não se esqueça de assinar minha newsletter chata. Aprendi muitas coisas desde o primeiro trimestre e as compartilharei em breve. Tchau.