Em poucas palavras, a ideia por trás dos lançamentos canário é entregar uma nova versão de software para apenas uma fração dos usuários, analisar os resultados e decidir se deve prosseguir ou não. Se os resultados não estiverem alinhados com as expectativas, retroceda; se forem, aumente o número de usuários expostos até que todos os usuários se beneficiem da nova versão.  Neste post, gostaria de detalhar brevemente esta introdução, explicar diferentes formas de definir a fração e mostrar como executá-la com  Apache APISIX.  Introdução aos lançamentos canário  O termo "canário" tem origem na indústria de mineração de carvão. Durante a mineração, não é incomum liberar gases tóxicos: em um espaço pequeno e fechado, isso pode significar morte rápida. Pior ainda, o gás pode ser inodoro, então os mineiros o respirariam até que fosse tarde demais para partir. O monóxido de carbono é bastante comum nas minas de carvão e não é detectável pelos sentidos humanos.  Por esta razão, os mineiros trouxeram canários para o subsolo. Se o canário caísse morto de repente, havia grandes chances de que tal bolsa de gás tivesse sido rompida e já era hora de deixar o local.  Anos atrás, trouxemos essa abordagem para lançar uma nova versão de software. A analogia é a seguinte: os mineradores são a equipe de operações que implanta a versão, o canário consiste em todas as ferramentas para medir o impacto do lançamento e o gás é um bug (crítico).  A parte mais importante é que   do lançamento, incluindo taxas de falha, códigos de status HTTP, etc., e compará-los com os da versão anterior. Está fora do escopo desta postagem, mas, novamente, é fundamental se você quiser se beneficiar dos lançamentos canário. A segunda parte mais importante é a capacidade de reverter rapidamente se a nova versão apresentar bugs. você precisa medir o impacto  Lançamentos Canary vs. sinalizadores de recursos  Observe que as versões canário não são a única maneira de gerenciar o risco de lançar novo código. Por exemplo, sinalizadores de recursos são outra forma popular:  A abordagem canário oferece o conjunto completo de recursos na nova versão do componente  Os sinalizadores de recursos também implantam o componente, mas parâmetros de configuração dedicados permitem ativar e desativar cada recurso individualmente  Os sinalizadores de recursos representam uma abordagem mais ágil (no verdadeiro sentido da palavra) em relação às reversões. Se um dos 10 recursos apresentar bugs, você não precisará remover a implantação da nova versão; você apenas desativa o recurso de buggy. No entanto, esse superpoder tem o custo de uma complexidade adicional de base de código, independentemente de você confiar em produtos de terceiros ou implementá-los sozinho.  Por outro lado, o canary requer um pipeline de implantação maduro para poder implantar e cancelar a implantação à vontade.  Abordagens para lançamentos canário  A ideia por trás dos lançamentos canário é permitir que apenas uma fração dos usuários acesse a nova versão. A maioria das definições canário define apenas "fração" como uma porcentagem de usuários. No entanto, há mais do que isso.  A primeira etapa pode ser permitir que apenas usuários verificados verifiquem se a implantação no ambiente de produção funciona conforme o esperado. Neste caso, você poderá encaminhar apenas um conjunto específico de usuários internos,   , testadores, para a nova versão. Se você conhece as pessoas com antecedência e o sistema autentica os usuários, você pode configurá-lo por identidade; caso contrário, você precisará recorrer a alguma forma genérica,   , cabeçalhos HTTP -   . por exemplo por exemplo X-Canary: Let-Me-Go-To-v2  Lembre-se de que devemos monitorar os sistemas antigos e novos para analisar as discrepâncias. Se nada aparecer, é um excelente momento para aumentar o pool de usuários encaminhados para a nova versão. Presumo que você coma sua própria comida de cachorro,   ; os membros da equipe usam o software que estão desenvolvendo. Se você não tem, por exemplo, um site de comércio eletrônico para carros de luxo, pode pular esta seção. ou seja  Para ampliar a fração de usuários e ao mesmo tempo limitar os riscos, podemos agora fornecer indiscriminadamente a nova versão aos usuários internos. Podemos configurar o sistema para encaminhar para a nova versão com base no IP do cliente para fazer isso. Numa época em que as pessoas trabalhavam no local, era fácil, pois seus IPs estavam em uma faixa específica. O remoto não muda muito, já que os usuários provavelmente acessam a rede da empresa por meio de uma VPN.  Novamente, monitore e compare neste ponto.  Todas as nove jardas  Neste ponto, tudo deve funcionar conforme o esperado para os usuários internos, sejam alguns ou todos. Mas assim como nenhum plano sobrevive ao contato com o inimigo, nenhum uso pode imitar toda a diversidade de uma carga de trabalho de produção. Resumindo, precisamos deixar que usuários regulares acessem a nova versão, mas de forma controlada, assim como aumentamos gradativamente o número de usuários até agora: comece com uma pequena fração, monitore e se estiver tudo bem, aumente a fração .  Veja como fazer isso com Apache APISIX. Apache APISIX oferece uma arquitetura baseada em plugin e fornece um plugin que atende às nossas necessidades, ou seja, o plugin   . traffic-split  O plug-in   pode ser usado para direcionar dinamicamente partes do tráfego para vários serviços Upstream. traffic-split  Isso é feito configurando   , que são regras personalizadas para divisão de tráfego, e   que é um conjunto de Upstreams para direcionar o tráfego. match weighted_upstreams  -  divisão de tráfego  Vamos começar com alguns upstreams básicos, um para cada versão:   upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1  Podemos usar o plugin   para encaminhar a maior parte do tráfego para v1 e uma fração para v2: traffic-split   routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3  Defina uma rota abrangente  Configure como dividir o tráfego; aqui, pesos  Encaminhe 99% do tráfego para v1 e 1% para v1. Observe que os pesos são relativos entre si. Para atingir 50/50, você pode definir os pesos 1 e 1, 3 e 3, 50 e 50, etc.  Novamente, monitoramos tudo e garantimos que os resultados sejam os esperados. Então, podemos aumentar a fração do tráfego encaminhado para v2,   : por exemplo   routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1  Aumente o tráfego para v2 para 5%  Observe que o Apache APISIX recarrega as alterações no arquivo acima a cada segundo. Conseqüentemente, você divide o tráfego quase em tempo real. Alternativamente, você pode usar a API Admin para conseguir o mesmo.  Lançamentos mais controlados  Acima, mudei de usuários internos para uma fração de usuários externos. Talvez liberar para todos os usuários internos seja um risco muito grande para sua organização e você precise de ainda mais controle. Observe que você pode configurar ainda mais o plugin   neste caso. traffic-split   routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95  Divida o tráfego apenas se o cabeçalho HTTP   tiver o valor configurado. X-Canary  O seguinte comando sempre encaminha para v1:   curl http://localhost:9080  O comando a seguir também sempre encaminha para v1:   curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080  O comando a seguir divide o tráfego de acordo com os pesos configurados,   , 95/5: ou seja   curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080  Conclusão  Esta postagem explicou as versões canary e como você pode configurá-las por meio do Apache APISIX. Você pode começar com várias rotas com prioridades diferentes e passar para o plugin   . Este último pode ainda ser configurado para permitir casos de uso mais complexos. traffic-split  O código-fonte completo desta postagem pode ser encontrado no   . GitHub   Ir adiante:   Implementação de solução de lançamento canário baseada em Apache APISIX   Lançamento Canary no Kubernetes com Apache APISIX Ingress   Liberação suave do Canary usando APISIX Ingress Controller com Flagger  Publicado originalmente em   em 3 de dezembro de 2023 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este áudio é produzido no idioma original da história!

Implementando versões Canary com Apache APISIX

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Modelo Bitcoin UTXO, alimentando um ecossistema único

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Modelo Bitcoin UTXO, alimentando um ecossistema único

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps