Uma implantação sem parada é aquela em que o processo real de mudar os usuários de uma versão para outra acontece de maneira quase instantânea. É fundamental que os usuários possam voltar para a versão anterior quase que de imediato se algo der errado.
A questão principal para implantações sem parada é separar as várias partes do processo de entrega de modo que possam acontecer da maneira mais independente possível. Em especial, deve ser possível atualizar as versões de recursos compartilhados dos quais a aplicação depende, como bancos de dados, serviços e recursos estáticos, antes da atualização da própria aplicação.
Com recursos estáticos e serviços Web, isso é relativamente simples. você pode incluir a versão do recurso ou serviço na URL de modo que várias versões dele possam estar ativas ao mesmo tempo. Por exemplo, a Amazon versiona seus AWS (Amazon Web Services) com base em datas, e a última versão da API EC2, por exemplo, está disponível em http://ec2.amazonaws. com/doc/2009-11-30/AmazonEC2.wsdl. Obviamente eles mantêm as versões antigas funcionando e também as URLs antigas. Para recursos como imagens, JavaScript, HTML e CSS, quando você mudar a versão do site, pode colocá-los em um novo diretório – por exemplo, as imagens para a versão 2.6.5 da aplicação podem estar no diretório /static/2.6.5/images.Isso é um pouco mais complicado com bancos de dados.
Implantações blue-green:
Essa é uma das técnicas mais poderosas que conhecemos para gerir implantações. A ideia é ter duas versões idênticas do ambiente de produção, que chamaremos de azul e verde.
No exemplo da Figura, usuários do sistema são roteados para o ambiente verde, que é o ambiente atual de produção. Quando quisermos, então, implantar uma nova versão da aplicação, fazemos a implantação para o ambiente azul e fazemos sua inicialização. Isso não afeta de maneira alguma o ambiente verde. Podemos rodar smoke tests para verificar se o ambiente azul está funcionando de maneira apropriada. Quando estivermos prontos, mudar para a nova versão é tão simples como mudar as configurações do roteador para apontar para o ambiente azul em vez do ambiente verde. O ambiente azul se torna a produção. Essa mudança geralmente pode ser efetuada em menos de um segundo.
Se algo der errado, simplesmente voltamos o roteador para a configuração anterior, restaurando o ambiente verde. Podemos então depurar o problema no ambiente azul.
É fácil perceber que essa abordagem apresenta várias melhorias em relação à abordagem de reimplantar uma versão anterior. Entretanto, é necessário certo cuidado com bancos de dados em implantações azul-verde.
Geralmente não é possível mudar diretamente do banco de dados verde para o banco de dados azul, porque leva tempo migrar os dados de um banco para o outro, especialmente no caso de mudanças de estrutura. Uma maneira de resolver isso é colocar a aplicação em modo de leitura um pouco antes da mudança. você pode então fazer uma cópia do banco de dados verde, restaurá-lo no ambiente azul, fazer a migração e mudar para o ambiente azul.
Se tudo correr bem, você pode tirar a aplicação do modo de leitura. Se algo der errado, simplesmente volte para o banco de dados verde. Se isso acontecer antes que a aplicação saia do modo de leitura, nada mais precisa ser feito, mas se algo já foi escrito no novo banco de dados e você deseja preservar isso, é necessária alguma forma de pegar esses registros novos e migrá-los de volta para o banco de dados verde antes de tentar uma nova implantação. Alternativamente, você pode encontrar uma forma de alimentar os dois bancos de dados ao mesmo tempo com as novas transações.
Implantações Canário:
Implantação sem parada
Geralmente é seguro assumir que você tem somente uma versão da aplicação em produção de cada vez. Isso torna mais fácil o trabalho de gerir correções e, na verdade, a infraestrutura como um todo. Entretanto, isso também gera um impedimento nos testes. Mesmo com uma estratégia abrangente e solida de testes, aparecem defeitos em produção. E mesmo com um tempo de ciclo reduzido, equipes de desenvolvimento podem se beneficiar ainda mais de feedback mais rápido de novas funcionalidades ou qualquer coisa que estejam fazendo para trazer mais valor ao software em que estão trabalhando.
Além disso, se você tem ambientes enormes de produção, é impossível criar testes de capacidade significativos (a menos que a arquitetura de sua aplicação tenha compartilhamentos de ponta a ponta). Como garantir que a nova versão não tenha um desempenho ruim? Implantação canário resolve esses problemas.
Como um canário em uma mina de carvão, isso rapidamente detecta qualquer problema com novas versões sem atingir a maioria dos usuários, e é uma ótima forma de reduzir o risco de novas versões. Como em implantações azul-verde, você precisa inicialmente implantar a nova versão da aplicação em um conjunto de servidores que não estejam expostos a usuários. você pode então rodar os smoke tests e, se quiser, testes de capacidade, na nova versão. Finalmente, pode começar a rotear usuários selecionados para a nova versão.
Algumas empresas selecionam usuários mais ativos para usar a nova versão primeiro. você pode ter varias versões da aplicação em produção ao mesmo tempo, roteando diferentes grupos de usuários para diferentes versões de acordo com a necessidade.
Há vários benefícios nessa técnica:
- Reverter para uma versão anterior é fácil. Apenas deixe de rotear os usuários para versões ruins e investigue os logs sem pressa.
- você pode usá-la para testes A/B, roteando alguns usuários para a nova versão e alguns para a versão anterior. Algumas empresas medem o uso de novas funcionalidades, e as eliminam se não há uso suficiente. Outras medem a receita gerada pela nova versão, e revertem se a receita for menor. Se o software gera resultados de busca, você pode comparar a qualidade obtida por usuários reais na nova versão comparada com a versão anterior. você não precisa rotear para muitos usuários; um conjunto representativo é o suficiente.
- você pode verificar se a aplicação atende os requisitos de capacidade aumentando a carga aos poucos, lentamente roteando mais e mais usuários para a aplicação e medindo tempo de resposta e métricas como uso de CPU, I/O e memória, e verificando os logs em busca de exceções. Essa é uma forma de testar a capacidade no ambiente de produção com relativamente pouco risco se o ambiente for grande demais para permitir a criação de ambientes realistas de testes de capacidade.
Quer estar sempre por dentro dos conteúdos de devops? Assine nossa newsletter gratuita e receba semanalmente conteúdos novos para você.
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
