Deploy sem downtime com blue-green e canary releases explicados
Introdução
O deploy de software é um processo crítico no ciclo de vida de qualquer aplicação, mas pode ser fonte de problemas quando não gerenciado adequadamente. O downtime, ou a parada do serviço por período prolongado, pode resultar em perda financeira significativa e danos à reputação da empresa.
Com o aumento na complexidade dos sistemas de software e a necessidade de atualizações periódicas para manter a segurança e funcionalidade, é fundamental encontrar métodos eficazes para realizar deploy sem interrupção dos serviços. Neste artigo, exploraremos as técnicas de blue-green e canary releases como soluções viáveis para alcançar o objetivo do deploy sem downtime.
Ao final deste artigo, você estará capacitado a identificar os principais benefícios das técnicas mencionadas e a aplicá-las em seu próprio contexto de desenvolvimento de software.
O que é e por que importa
O deploy sem downtime é um conceito fundamental para garantir a continuidade dos serviços de software, evitando interrupções no funcionamento dos sistemas críticos. Existem várias técnicas para alcançar esse objetivo, sendo as blue-green deployments e as canary releases duas das mais utilizadas.
A Blue-Green Deployment envolve a criação de dois ambientes idênticos, um com a versão atual do sistema (chamado "verde") e outro com a nova versão (chamado "azul"). Após a configuração da nova versão no ambiente azul, os usuários são redirecionados para ele. Se houver algum problema, o tráfego é revertido para o ambiente verde.
Já a Canary Release envolve o lançamento de uma pequena parcela da base de usuários para a nova versão do sistema, permitindo que sejam identificados e resolvidos problemas antes de serem liberadas para todos os usuários. A porcentagem inicial pode variar entre 1% e 10%.
Ambas as técnicas permitem a realização de deploy sem downtime, minimizando o risco de interrupções nos serviços. As blue-green deployments são mais adequadas para implantações em produção críticas, pois garantem um ambiente isolado para a nova versão. Já as canary releases são úteis quando há necessidade de testar a nova versão com uma pequena parcela da base de usuários antes de expandir para todos.
Como funciona na prática
Aqui estão as etapas para implementar blue-green deployments e canary releases de forma eficaz:
Blue-Green Deployments
- Preparação: Crie um ambiente idêntico à produção, denominado "ambiente azul".
- Configuração da nova versão: Instale a nova versão do sistema no ambiente azul e configure-o para funcionar como o ambiente verde.
- Migração de usuários: Redirecione os usuários para o ambiente azul. Se houver problemas, reverta o tráfego para o ambiente verde.
- Teste e monitoramento: Monitore a performance do sistema no ambiente azul e identifique quaisquer problemas antes de migrar todos os usuários.
Canary Releases
- Defina uma porcentagem de usuários: Estabeleça uma percentagem inicial de usuários (por exemplo, 5%) que serão redirecionados para a nova versão.
- Configuração da nova versão: Instale a nova versão do sistema e configure-a para funcionar como o ambiente existente.
- Lançamento: Redirecione a porcentagem de usuários definida anteriormente para a nova versão.
- Teste e monitoramento: Monitore a performance do sistema com os usuários migrados para a nova versão e identifique quaisquer problemas antes de expandir para todos os usuários.
Exemplo real
Vamos considerar um exemplo de como implementar blue-green deployments e canary releases em uma plataforma de streaming de vídeo.
Plataforma de Streaming de Vídeo
A nossa empresa desenvolveu uma plataforma de streaming de vídeo que utiliza dois servidores de aplicação, cada um executando a versão 1.0 do sistema. A equipe de engenharia está atualizando o código fonte para incluir suporte a novos formatos de vídeo e melhorias na experiência do usuário.
Para minimizar os riscos associados à implantação de uma nova versão, decidimos utilizar blue-green deployments para migrar gradualmente os usuários para a versão 2.0 do sistema.
Configuração
Aqui está o código comentado para configurar a plataforma de streaming de vídeo utilizando blue-green deployments:
// Define as variáveis de ambiente para os ambientes azul e verde
AZUL_PORT=8081
VERDE_PORT=8080
// Criar um container para o ambiente azul
docker run -d --name azure \
-p ${AZUL_PORT}:${AZUL_PORT} \
-e PORT=${AZUL_PORT} \
meu-imagem/azure:2.0
// Redirecione os usuários para o ambiente azul
echo "Redirecionando usuários para ambiente azul..."
curl http://localhost:${AZUL_PORT}
// Testar a performance do sistema no ambiente azul
echo "Testando performance do sistema em ambiente azul..."
curl -v http://localhost:${AZUL_PORT}
Implementação de Canary Releases
Além disso, também queremos testar a versão 2.0 com uma pequena parcela da base de usuários antes de expandir para todos. Nesse caso, decidimos implementar canary releases.
Aqui está o código comentado para configurar a plataforma de streaming de vídeo utilizando canary releases:
// Define as variáveis de ambiente para os ambientes azul e verde
CANARY_PORT=8082
// Criar um container para o ambiente canário
docker run -d --name canario \
-p ${CANARY_PORT}:${CANARY_PORT} \
-e PORT=${CANARY_PORT} \
meu-imagem/canario:2.0
// Redirecione uma porcentagem de usuários (5%) para o ambiente canário
echo "Redirecionando 5% dos usuários para ambiente canário..."
curl http://localhost:${CANARY_PORT}
// Testar a performance do sistema com os usuários migrados para o ambiente canário
echo "Testando performance do sistema com usuários em ambiente canário..."
curl -v http://localhost:${CANARY_PORT}
Esses exemplos ilustram como blue-green deployments e canary releases podem ser utilizados para minimizar os riscos associados à implantação de uma nova versão.
Boas práticas
- Testes de carga e estresse: Antes de implantar a nova versão, execute testes de carga e estresse para garantir que a plataforma possa lidar com o volume de usuários esperado.
- Monitoramento contínuo: Mantenha o monitoramento da aplicação em tempo real durante a implantação para detectar quaisquer problemas ou anomalias.
- Documentação completa: Faça um registro detalhado dos passos seguidos durante a implantação, incluindo os resultados dos testes e qualquer problema encontrado.
- Treinamento dos usuários: Antecipe-se às necessidades dos usuários e forneça suporte e treinamento para garantir que eles saibam como usar as novas funcionalidades.
Armadilhas comuns
- Subestimar a complexidade da implantação: Não subestime a complexidade de uma implantação, especialmente se envolver alterações significativas na infraestrutura ou no código.
- Não testar adequadamente: Não economize em testes, pois isso pode levar a problemas não detectados durante a implantação, o que pode resultar em tempo e recursos perdidos para resolver os problemas.
- Implantar sem um plano de fallback: Tenha um plano de fallback pronto em caso de falhas ou problemas inesperados. Isso pode incluir rollback da aplicação anterior ou implementação de soluções de contenção temporárias.
- Não comunicar adequadamente com a equipe e os usuários: A falta de comunicação clara pode levar a confusão, ansiedade e até mesmo danos reputacionais. Certifique-se de que todos estejam informados sobre os objetivos, prazos e riscos associados à implantação.
Conclusão
Em resumo, realizar implantações de aplicativos sem paradas pode ser um desafio, mas usando blue-green e lâmpadas canary é possível minimizar os riscos. Ao adotar essas estratégias e seguir as best practices mencionadas aqui, você pode garantir que a transição seja suave e transparente para usuários e equipe.
Para tomar o próximo passo, considere:
- Aprofundar na configuração de ambientes blue-green em seus sistemas de gerenciamento de infraestrutura como Kubernetes.
- Desenvolver uma estratégia de lâmpadas canary que seja específica às necessidades da sua aplicação e dos usuários.
- Estudar casos de sucesso em implantações sem paradas e aprender com as experiências de outras equipes.
Ao implementar essas estratégias e práticas, você estará melhor preparado para realizar implantations sem paradas, mantendo a disponibilidade da sua aplicação e atendendo às expectativas dos usuários.
Referências
- Martin Fowler. Strategies for Rolling Back a Rollout on Failure. Disponível em: https://martinfowler.com/articles/rolling-back-a-rollout-on-failure.html. Acesso: 2024.
- Thoughtworks. Blue-Green Deployments with Kubernetes and GitOps. Disponível em: https://www.thoughtworks.com/en/company/blog/blue-green-deployments-with-kubernetes-and-gitops. Acesso: 2024.
- OWASP. DevOps Considerations for Security Teams. Disponível em: https://owasp.org/www-pdf-archive/OWASP_DevSecOps.pdf. Acesso: 2024.
- 12factor.net. Backups and Recovery. Disponível em: https://12factor.net/backups-and-recovery. Acesso: 2024.
- Kubernetes.io. Blue-Green Deployments with Kubernetes. Disponível em: https://kubernetes.io/docs/concepts/workloads/applications/deployment/#blue-green-deployments. Acesso: 2024.