Em um 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). artigo Você pode consultar o artigo anterior para implantar seu aplicativo em qualquer outro idioma. Apenas certifique-se de modificar o arquivo de fluxo de trabalho. 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. Usaremos um produto imaginário para fins de exemplo, pois não quero percorrer as etapas de implantação com o produto que construí para minha empresa devido a motivos de NDA. haha. Vamos direto aos passos: 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 usando o no diretório atual. myexample:v2 Dockerfile Onde é o nome da imagem do docker recém-criada. No meu caso, era o nome do projeto ML. Por exemplo, myexample:v2 docker build -t companyx-servicename-backend:v2 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 da imagem . myexample-v2 myexample:v2 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. 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: e . A palavra-chave é usada para marcar o segundo servidor como um backup. A diretiva é usada para encaminhar solicitações para o grupo upstream . myexample-v1 myexample-v2 backup proxy_pass myexample Certifique-se de atualizar a configuração do proxy reverso para refletir o nome e a porta do seu aplicativo. 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 . Monitore seu aplicativo e ajuste a configuração conforme necessário até que todo o tráfego esteja fluindo para o novo contêiner. myexample-v2 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 Se seu aplicativo depende de um banco de dados relacional, a estratégia de implantação azul-verde pode causar inconsistências entre os bancos de dados Azul e Verde quando as atualizações são feitas. Para garantir o mais alto nível de integridade de dados, é recomendável configurar um banco de dados unificado compatível com versões anteriores e futuras. 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.
