"O perigo é meu nome do meio", disse Austin Powers, um homem misterioso em escala internacional. Mas o que os super-agentes e serviços especiais têm em alta estima não é de todo adequado para serviços de informática, onde coisas chatas são muito melhores do que perigos.
E o Istio, junto com o OpenShift e o Kubernetes, tornam as implantações de microsserviço realmente chatas e previsíveis - e isso é ótimo. Falaremos sobre isso e muito mais no quarto e último post da série Istio.Quando o tédio está certo
No nosso caso, o tédio ocorre apenas na fase final, quando resta apenas sentar e assistir ao processo. Mas para isso, você precisa pré-configurar tudo, e aqui você encontrará muitas coisas interessantes.Ao implantar uma nova versão do seu software, você deve considerar todas as opções para minimizar os riscos. Trabalhar em modo paralelo é um método de teste muito poderoso e comprovado, e o Istio permite que você use o "serviço secreto" (uma versão do seu microsserviço oculto para olhares indiscretos) para isso sem interferir no sistema de produção. Existe até um termo especial para isso - "Lançamento Secreto" (Lançamento Escuro), que por sua vez é ativado por uma função com o menor nome de spyware "espelhamento de tráfego".Observe que a primeira frase do parágrafo anterior usa o termo "deploy" em vez de "release". Você realmente deve poder implantar - e, é claro, usar - seu microsserviço quantas vezes desejar. Esse serviço deve poder receber e processar tráfego, produzir resultados, além de gravar em logs e monitorar. Mas, ao mesmo tempo, esse serviço em si não precisa ser lançado em produção. A implantação e o lançamento do software nem sempre são a mesma coisa. Você pode executar a implantação quando quiser, mas liberar apenas quando estiver completamente pronto.Organizar o tédio é interessante
Dê uma olhada na seguinte regra de roteamento do Istio, que roteia todas as solicitações HTTP para o microsserviço de recomendação v1 (todos os exemplos são obtidos no repositório do Istio Tutorial GitHub ), enquanto os espelha para o microserviço de recomendação v2:Preste atenção na etiqueta mirror:na parte inferior da tela - é ela que define o espelhamento do tráfego. Sim, isso é tão simples!O resultado desta regra será que seu sistema de produção (v1) continuará processando solicitações recebidas, mas as solicitações se espelharão de forma assíncrona na v2, ou seja, suas duplicatas completas irão para lá. Assim, você pode testar o trabalho da v2 em condições reais - em dados e tráfego reais - sem interferir no trabalho do sistema de produção. Isso torna a organização de teste chata? Sim, claro. Mas isso está sendo feito de maneira interessante.Adicionar drama
Observe que no código v2, é necessário prever situações em que solicitações recebidas podem levar a alterações nos dados. As consultas em si são espelhadas com facilidade e transparência, mas a escolha do método de processamento no teste é sua - e isso já é um pouco empolgante.Repita o ponto importante
Um lançamento secreto com espelhamento de tráfego (Dark Launch / Request Mirroring) pode ser executado sem afetar o código.Alimento para o pensamento
Mas e se o lugar para espelhar os pedidos for enviar alguns deles não para a v1, mas para a v2? Por exemplo, um por cento de todas as solicitações ou apenas solicitações de um grupo de usuários específico. E então, já vendo como a v2 funciona, transfira gradualmente todos os pedidos para a nova versão. Ou vice-versa, retorne tudo para a v1 se algo der errado com a v2. Parece ser chamado de Canary Deployment ("canary Deployment" - o termo remonta à mineração e, se fosse de origem russa, provavelmente conteria uma referência a gatos ), e agora examinaremos isso mais detalhadamente.Implantação de canárias no Istio: simplificando o comissionamento
Cuidado e gradualmente
A essência do modelo de implantação do Canary Deployment é extremamente simples: quando você inicia uma nova versão do seu software (no nosso caso, microsserviço), primeiro dá acesso a um pequeno grupo de usuários. Se tudo der certo, você aumenta lentamente esse grupo até que a nova versão comece a se tornar indesejada ou, se isso não acontecer, transfere todos os usuários para ele. Introdução cuidadosa e gradual de uma nova versão em operação e troca de usuários de maneira controlada, você pode reduzir os riscos e maximizar o feedback.Obviamente, o Istio simplifica o Canary Deployment, oferecendo várias boas opções para roteamento inteligente de consultas. E sim, tudo isso pode ser feito sem tocar no seu código-fonte.Filtrar o navegador
Um dos critérios de roteamento mais simples é o redirecionamento baseado em navegador. Suponha que você queira que a v2 envie apenas solicitações dos navegadores Safari. Veja como fazê-lo:Aplicamos essa regra de roteamento e, com o comando curl, simularemos solicitações reais ao microsserviço em um loop. Como você pode ver na captura de tela, todos eles vão para a v1:E onde está o tráfego na v2? Como em nosso exemplo todas as solicitações vieram apenas de nossa própria linha de comando, ela simplesmente não existe. Mas preste atenção às linhas de fundo na captura de tela acima: essa é uma reação ao fato de termos executado a solicitação no navegador Safari, que por sua vez emitiu o seguinte:Poder ilimitado
Já escrevemos que expressões regulares fornecem recursos muito poderosos para consultas de roteamento. Dê uma olhada no exemplo a seguir (achamos que você mesmo entenderá o que ele faz):Agora você provavelmente já sabe do que expressões regulares são capazes.Agir de forma inteligente
O roteamento inteligente, em particular o processamento de cabeçalhos de pacotes usando expressões regulares, permite direcionar o tráfego da maneira que você deseja. E isso simplifica muito o comissionamento de novo código - é simples, não requer alteração do código e, se necessário, tudo pode ser retornado rapidamente como estava.Interessado em?
Você está ansioso para experimentar o Istio, Kubernetes e OpenShift no seu computador? A equipe de desenvolvedores da Red Hat preparou um excelente tutorial sobre este tópico e compartilhou todos os arquivos relacionados. Então vá em frente e não se negue nada. Istio Egress: saída pela loja de presentes
Usar o Istio com o Red Hat OpenShift e Kubernetes pode simplificar bastante sua vida com microsserviços. A grade do Istio Utility está oculta nos pods do Kubernetes e seu código é executado (principalmente) isoladamente. Desempenho, facilidade de alteração, rastreamento e muito mais - tudo isso é fácil de usar com precisão através do uso de contêineres laterais. Mas e se o seu microsserviço precisar se comunicar com outros serviços localizados fora do seu sistema OpenShift-Kubernetes?É aqui que o Istio Egress vem em socorro. Em poucas palavras, ele simplesmente permite acessar recursos (leia-se: “serviços”) que não estão incluídos no seu sistema de pod Kubernetes. Se você não executar uma configuração adicional, no ambiente do Istio Egress, o tráfego será roteado apenas dentro do cluster de pods e entre esses clusters com base em tabelas IP internas. E esse tipo de brincadeira funciona muito bem até que você precise acessar os serviços de fora.A saída permite ignorar as tabelas IP acima mencionadas, com base nas regras de saída, ou para um intervalo de endereços IP.Suponha que tenhamos um programa Java que executa uma solicitação GET para httpbin.org/headers.(httpbin.org é apenas um recurso conveniente para testar solicitações de serviço de saída.)Se você digitar no prompt de comandocurl http://httpbin.org/headersveremos o seguinte:Ou você pode abrir o mesmo endereço em um navegador:Como você pode ver, o serviço localizado simplesmente retorna os cabeçalhos passados para ele.Substituição de importação na testa
Agora, vamos pegar o código Java desse serviço externo ao nosso sistema e executá-lo em casa, onde, lembre-se, o Istio está. (Você pode fazer isso sozinho consultando o nosso tutorial Istio .) Após criar a imagem correspondente e executá-la na plataforma OpenShift, chamaremos esse serviço com um comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, após o qual veremos na tela:Opa, o que aconteceu? Ainda assim, apenas funcionou. O que significa Não encontrado? Nós apenas fizemos isso por ele curl.Estender tabelas IP para toda a Internet
Culpe (ou agradeça) Istio por isso. Afinal, o Istio são apenas contêineres secundários responsáveis pela detecção e roteamento (bem, por muitas outras coisas sobre as quais falamos anteriormente). Por esse motivo, as tabelas IP sabem apenas o que está dentro do seu sistema de cluster. E o httpbin.org está localizado fora e, portanto, indisponível. E aqui o Istio Egress vem em socorro - sem a menor alteração no seu código-fonte.A regra de saída abaixo faz com que o Istio procure (se necessário e depois em toda a Internet) pelo serviço desejado, neste caso, httpbin.org. Como você pode ver neste arquivo (egress_httpbin.yml), a funcionalidade aqui é bastante simples:Resta apenas aplicar esta regra:istioctl create -f egress_httpbin.yml -n istioegress
Você pode visualizar as regras de saída com o comando istioctl get egressrules:E, finalmente, execute o comando curl novamente - e veja se tudo funciona:Pensamos abertamente
Como você pode ver, o Istio permite organizar a interação com o mundo exterior. Em outras palavras, você ainda pode criar serviços OpenShift e orientá-los no Kubernetes, mantendo tudo em pods que aumentam e diminuem conforme necessário. E, ao mesmo tempo, você pode acessar com segurança serviços externos ao seu ambiente. E sim, repetimos mais uma vez que tudo isso pode ser feito sem tocar no seu código.Este foi o último post da série Istio. Fique conosco - há muitas coisas interessantes pela frente!