Nota perev. - Com este artigo, começamos uma série de traduções dedicadas ao tópico de Zero Downtime Deployment. As publicações a seguir destacarão a implantação de novas versões do aplicativo com o banco de dados e a implantação no Kubernetes.
Apesar de a solução técnica descrita abaixo ser controversa, o objetivo deste artigo é familiarizar o leitor diretamente com a abordagem de implantação Azul-Verde, que, aliás, é aplicável não apenas aos aplicativos Spring.
O objetivo da implantação Azul-Verde é eliminar o tempo de inatividade durante a implantação de uma nova versão do aplicativo.
O tempo de inatividade é associado à indisponibilidade de servidores quando uma nova versão de um aplicativo é instalada para substituir o antigo. A idéia da implantação Azul / Verde é implantar a nova versão do aplicativo em um local separado, onde você pode realizar os testes, até que seja tomada a decisão final de mudar para ele como o principal.
Neste artigo, veremos como configurar a implantação azul esverdeado dos aplicativos de inicialização do Spring. Usaremos o Nginx como o principal servidor da Web para redirecionar solicitações recebidas para nossos aplicativos.
Configuração do servidor
Este guia pressupõe que você tenha um servidor e um aplicativo de inicialização Spring em execução que possa ser implantado nele.
No servidor, acesse o diretório inicial e crie duas pastas: blue e green . Então precisamos de dois links simbólicos available e de testing . Esses links apontarão para uma pasta azul ou verde. Por exemplo, se available aponta para green , o testing aponta para blue .
mkdir blue mkdir green ln -s ./green ./available ln -s ./blue ./testing
Cada pasta conterá seu próprio aplicativo Spring e a configuração do Nginx. Em algum momento da implantação, os dois aplicativos funcionarão simultaneamente (embora em portas diferentes) e, para mudar do aplicativo azul para o verde, precisamos alterar apenas a configuração do Nginx para verde ou azul.
Configurações do Nginx
Digamos que temos um domínio springsite.com. A configuração verde do Nginx redirecionará todas as chamadas para springsite.com/api/ para o aplicativo green na porta 8080 e todas as chamadas para springsite.com/api-test/ para o aplicativo blue na porta 8090.
Vamos criar esses arquivos de configuração. Abra seu editor favorito e adicione o seguinte conteúdo.
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8090/api; } location /api-test { proxy_pass http://localhost:8080/api; } } include servers/*; }
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8080/api; } location /api-test { proxy_pass http://localhost:8090/api; } } include servers/*; }
A estrutura do arquivo deve se parecer com isso:
--root |--- blue |--- nginx.conf.blue |--- app-V2.jar |--- green |--- nginx.conf.green |--- app-V1.jar |--- available -> ./green |--- testing -> ./blue
Suponha que desejemos implantar uma nova versão em um contêiner blue . Podemos testá-lo enquanto a versão anterior ainda está disponível . Quando todos estiverem satisfeitos com a nova versão, precisaremos apenas alterar os links!
Crie o arquivo swap.sh na pasta que contém as pastas blue e green :
touch swap.sh chmod +x swap.sh
Adicione o seguinte conteúdo ao arquivo swap.sh :
#!/bin/bash testing_now=$(ls -l ./ | grep testing) if [[ "$testing_now" == *blue ]] then testing="blue" active="green" else testing="green" active="blue" fi #remove current links rm ./available rm ./testing rm -f /etc/nginx/nginx.conf #create new links with the active/inactive reversed ln -s ./$inactive ./available ln -s ./$active ./testing ln -s /home/ubuntu/spring/$active/nginx.conf /etc/nginx/nginx.conf #reload the http server service nginx reload echo swap completed $active is now available
Nesse ponto, podemos executar 2 aplicativos Spring nas portas 8090 e 8080 e alterá-los executando sudo ./swap.sh .
Implantar
Graças aos links simbólicos, sabemos que o aplicativo principal é sempre indicado por available , e o que está sendo testado por testing . Portanto, sempre devemos implantar uma nova versão do aplicativo na pasta de testing usando um link simbólico. Supõe-se que acabamos de empacotar o aplicativo e agora podemos baixá-lo usando o scp .
scp -r -i ~/.ssh/MyKeyPair.pem <package name.jar> <user>@<ip>:spring/testing
Seguir em frente
A configuração de uma implantação azul esverdeado no servidor reduzirá significativamente o tempo de inatividade . Este guia explica como implantar novas versões do seu aplicativo que residem no mesmo servidor físico. Pode ser adaptado a situações com vários servidores físicos e um balanceador de carga. No entanto, isso exigirá ter o dobro do ambiente de produção necessário. Para uma infraestrutura muito grande, isso é impossível ou extremamente caro.
Isso leva à pergunta: como as grandes empresas conseguem lançar novas versões de seus aplicativos sem tempo de inatividade? Pense no Google ou no Facebook que estão sempre disponíveis!
O uso da implantação Blue-Green aqui não é realista devido ao grande número de servidores necessários. As atualizações de aplicativos são realizadas gradualmente: os servidores são retirados de serviço um por um e retornados após a atualização. Além disso, novas versões também são lançadas gradualmente: no início, apenas uma pequena parte dos servidores funcionará com a nova versão. Então, se nenhum problema ou bug for encontrado, mais e mais servidores começarão com o novo código. Nesse ponto, métricas importantes de desempenho, como CPU, memória e desempenho de consulta, são avaliadas. Se tudo correu bem, o lançamento está completo e uma nova versão do aplicativo será lançada em todos os servidores do mundo.
Conclusão
Espero que agora você entenda como resolver o problema do tempo de inatividade graças à implantação Azul-Verde. Agora você pode configurar a implantação básica azul esverdeado do seu aplicativo Spring com o NGINX.
Como você deve ter notado, quando usamos essa solução, as versões antiga e atual de seus aplicativos funcionam simultaneamente e ambas são conectadas ao banco de dados. Isso pode levar a problemas inesperados ao alterar a estrutura do banco de dados. Este excelente artigo https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database descreve como lidar com essas situações.
E, finalmente, você pode estar interessado no fato de que tanto a AWS quanto o Google Cloud Compute oferecem serviços de Implantação azul e verde:
https://aws.amazon.com/quickstart/architecture/blue-green-deployment/
https://cloud.google.com/solutions/continuous-delivery/
Leia também outros artigos em nosso blog: