Estratégia de liberação das canárias vs. Azul / Verde


125

Meu entendimento de um release canário é que é um release parcial para um subconjunto de nós de produção com sessões fixas ativadas. Dessa forma, você pode controlar e minimizar o número de usuários / clientes afetados se você acabar lançando um bug incorreto.

Meu entendimento de uma versão azul / verde é que você possui 2 ambientes de produção espelhados ("azul" e "verde") e envia as alterações para todos os nós de azul ou verde de uma só vez e depois usa a magia da rede para controlar para qual ambiente os usuários são roteados via DNS.

Portanto, antes de começar, se alguma coisa que eu disse até agora estiver incorreta, comece me corrigindo!

Supondo que eu esteja mais ou menos no caminho certo, duas perguntas sobre as duas estratégias:

  • Existem cenários em que o canário é preferido em vez de azul / verde e vice-versa?
  • Existem cenários em que um modelo de implantação pode implementar as duas estratégias ao mesmo tempo?

5
Sua compreensão é sólida, mas eu não descreveria uma estratégia azul esverdeada como precisando implantar em todos os nós de uma só vez. Você pode implantá-los da maneira que desejar - a única pressão são seus próprios prazos. Além disso, você pode usar azul esverdeado para liberar alterações em apenas um subconjunto de seus nós (por exemplo, modificar apenas um dos muitos conjuntos de terminais de API).
Patrick M

1
Um resumo muito bom desses conceitos que vejo em todos os lugares sem uma definição clara primeiro!
kheraud

Respostas:


94

A liberação azul esverdeado é mais simples e rápida.

Você pode executar uma versão azul esverdeada se tiver testado a nova versão em um ambiente de teste e tiver certeza de que a nova versão funcionará corretamente na produção. Sempre usar alternâncias de recursos é uma boa maneira de aumentar sua confiança em uma nova versão, uma vez que a nova versão funciona exatamente como a antiga até que alguém vire uma alternância de recurso. Dividir seu aplicativo em serviços pequenos e liberáveis ​​de forma independente é outro, pois há menos para testar e menos que podem ser interrompidos.

Você precisa fazer um lançamento canário se não tiver certeza absoluta de que a nova versão funcionará corretamente na produção. Mesmo se você for um testador completo, a Internet é um lugar grande e complexo e sempre apresenta desafios inesperados. Mesmo se você usar alternâncias de recursos, uma poderá ser implementada incorretamente.

A automação da implantação exige esforço, portanto a maioria das organizações planeja usar uma estratégia ou outra sempre.

O mesmo ocorre com a implantação azul esverdeado, se você se comprometer com práticas que permitem confiar em fazê-lo. Caso contrário, envie o canário.

A essência do azul esverdeado é implantada de uma só vez e a essência da implantação do canário é implantada de forma incremental, portanto, dado um único pool de usuários, não consigo pensar em um processo que descreveria como fazendo as duas coisas ao mesmo tempo. Se você tivesse vários pools de usuários independentes, por exemplo, usando diferentes datacenters regionais, seria possível fazer azul esverdeado em cada datacenter e canário nos datacenters. Embora se você não precisasse da implantação de canários em um datacenter, provavelmente não precisaria dela nos datacenters.


Algumas palavras sobre o significado das cores: - o ambiente antigo poderia ser o azul, o novo o verde. - No próximo lançamento, o antigo será o verde. Wiki:> Muitas línguas não distinguem entre o que em Inglês são descritos como "azul" e "verde" e em vez disso usar um termo de cobertura abrangendo ambos - "grue"
kinjelom

Canário nem sempre é mais rápido que azul / verde. Tudo depende dos fluxos de trabalho de IC e CD!
Ligemer

81

Escrevi um ensaio detalhado sobre este tópico aqui: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

Na minha opinião, a diferença é se a nova versão 'verde' é ou não exposta a usuários reais. Se for, então eu chamaria de Canário. Uma maneira comum de implementar o Canary é o azul / verde comum, com a adição de roteamento inteligente de usuários específicos à nova versão. Leia o post para uma comparação detalhada

Azul verde: insira a descrição da imagem aqui

Canário: insira a descrição da imagem aqui


4
Suas ilustrações são ótimas, posso considerar incorporá-las em sua resposta aqui, mas mantendo o link para um mergulho mais profundo com explicações.
usar o seguinte

Obrigado. Adicionados
itaysk 30/03/19

4
Muito boa explicação. Mas seria melhor mostrar a amostra de porcentagem de carga do usuário na ilustração canary.
Nikli 21/04/19

Qual é a diferença entre "durante" e "depois" no diagrama de lançamento do Canary? Eu esperava "depois" para se parecer com a da liberação azul / verde
Kes115

ambos os métodos visam reduzir o risco avaliando a nova versão. durante significa que a nova versão foi implantada, mas ainda não foi tomada uma decisão sobre como proceder. after significa depois que uma decisão positiva foi tomada para prosseguir.
itaysk

5

Embora ambos os termos pareçam bastante próximos, eles têm diferenças sutis. Um confia na liberação da funcionalidade e o outro confia na maneira como você libera.

Canário

  1. O release canary é uma técnica para reduzir o risco de introduzir uma nova versão de software em produção, lançando lentamente a alteração em um pequeno subconjunto de usuários antes de lançá-la em toda a infraestrutura.

  2. Está prestes a ter uma idéia de como a nova versão será executada (integre-se a outros aplicativos, CPU, memória, uso de disco, etc.).

Azul verde:

  1. É mais sobre o lançamento previsível com implantação zero de inatividade.
  2. Reversões fáceis em caso de falha.
  3. Processo de implantação completamente automatizado

4

Aqui estão algumas definições em linha -

  • Implantação azul esverdeado - Ao implantar uma nova versão de um aplicativo, um segundo ambiente é criado. Depois que o novo ambiente é testado, ele substitui a versão antiga. O ambiente antigo pode ser desativado.

     

  • Teste A / B - Duas versões de um aplicativo estão sendo executadas ao mesmo tempo. Uma parte dos pedidos vai para cada um. Os desenvolvedores podem comparar as versões.  
  • Canary Release - Uma nova versão de um microsserviço é iniciada junto com as versões antigas. Essa nova versão pode receber uma parte das solicitações e a equipe pode testar como essa nova versão interage com o sistema geral.

2

Um bom começo de definições. Eu acho que também ajuda a tomar uma decisão para sua estratégia se você dividir sua definição de "release" em "deploy" e "release (funcionalidade)".

Implantar (binários)

A ação da implantação binária do seu produto em um sistema (de produção).

Liberação (funcionalidade)

A ação de gerenciar a disponibilidade da funcionalidade para (grupos de) usuários.

Por quê? Você normalmente tem (várias) duas preocupações ao "liberar": 1) Bugs / compatibilidade com versões anteriores / etc 2) Verificando a validade / usabilidade dos novos recursos

Em seguida, pergunte a si mesmo, antes de escolher uma estratégia de modo Canário ou Azul / verde ou qualquer que seja o modo cinza / misto: Que preocupação (s) temos ao lançar / implantar a nova versão? E só então, se você conhece suas preocupações, escolha sua estratégia.

Além disso, é possível executar estratégias de implantação / liberação mais complexas. Por exemplo, em algumas nuvens / infra, é possível ter vários servidores de produção, e retransmitir a carga em diferentes proporções para diferentes servidores e versões do seu produto, além de monitorar a integridade antes de escalar uma versão / implantação para todos os usuários.

Sinalização de recursos

A ação de "configurar" (frio ou até quente) qual funcionalidade está (não) disponível para qual (grupo) de usuários

Se você também fizer algo como "sinalização de recurso", poderá implantar primeiro, medir a solidez do seu lançamento na compatibilidade com versões anteriores / perspectiva de bug e liberar novas funcionalidades gradualmente para diferentes usuários, ou vice-versa (reduzir ou até mesmo a funcionalidade de reversão e / ou binários ) A sinalização de recursos permite dividir a disponibilidade da funcionalidade da implantação de binários e fornece muito mais informações detalhadas sobre a tomada de decisões do que apenas "implantar / reverter"

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.