«Perigo – meu segundo nome», dizia Austin Powers, um homem enigmático de importância internacional. Mas o que é valorizado pelos superagentes e serviços secretos não serve para os serviços de computação, onde a monotonia é muito preferível ao perigo.
E o Istio, junto com o OpenShift e o Kubernetes, transforma a implantação de microsserviços em uma tarefa realmente monótona e previsível – e isso é ótimo. Vamos falar sobre isso e muito mais no quarto e último post da série sobre Istio.
Quando a monotonia é a escolha certa
No nosso caso, a monotonia surge apenas na fase final, quando resta apenas sentar e observar o processo. Mas para isso, é necessário configurá-lo tudo previamente, e aqui você encontrará muitas coisas interessantes.
Ao implantar uma nova versão do seu software, é importante considerar todas as opções para minimizar riscos. Trabalhar em modo paralelo é uma forma muito poderosa e comprovada de teste, e o Istio permite usar um 'serviço secreto' (uma versão do seu microsserviço oculta dos olhos dos outros) sem interferir no funcionamento do sistema de produção. Para isso, existe até um termo específico – 'Lançamento Secreto' (Dark Launch), que por sua vez é ativado por uma função com um nome igualmente espionagem: 'espelhamento de tráfego'.
Observe que na primeira frase do parágrafo anterior é utilizado o termo 'implantação' (deploy), e não 'lançamento' (release). Você realmente deve ser capaz de implantar – e, claro, utilizar – seu microsserviço sempre que desejar. Este serviço deve ser capaz de aceitar e processar tráfego, fornecer resultados, além de registrar em logs e ser monitorado. Mas o serviço em si não precisa ser lançado em produção. Implantação e lançamento de software nem sempre são a mesma coisa. Você pode implantar sempre que quiser, enquanto o lançamento só deve ocorrer quando você estiver completamente pronto.
Organizar a monotonia é interessante
Veja a seguinte regra de roteamento do Istio, que direciona todas as requisições HTTP para o microsserviço recommendation v1 (todos os exemplos são retirados de ), espelhando-as simultaneamente no microsserviço recommendation v2:
Preste atenção na etiqueta mirror: na parte inferior da tela – é ela que define o espelhamento de tráfego. Sim, é simples assim!
A implementação desta regra fará com que seu sistema de produção (v1) continue processando as solicitações recebidas, enquanto os próprios pedidos serão espelhados de forma assíncrona em v2, ou seja, cópias completas deles serão enviadas para lá. Assim, você poderá testar o funcionamento do v2 em condições reais — com dados e tráfego reais — sem interferir no funcionamento do sistema de produção. Isso torna a organização do teste um tédio? Sim, sem dúvida. Mas é feito de forma interessante.
Vamos adicionar um pouco de drama
Observe que no código v2, é necessário prever situações em que as solicitações recebidas possam levar a alterações nos dados. As próprias solicitações são espelhadas de forma fácil e transparente, mas a escolha do método de processamento no teste fica a seu critério — e isso é um pouco preocupante.
Vamos repetir um ponto importante
O lançamento secreto com espelhamento de tráfego (Dark Launch/Request Mirroring) pode ser realizado sem afetar o código de forma alguma.
Uma reflexão
E se, em vez de espelhar todas as solicitações para v1, enviássemos uma parte delas para v2? Por exemplo, um por cento de todas as solicitações ou apenas as solicitações de um grupo específico de usuários. E então, ao observar como v2 funciona, ir gradualmente transferindo todas as solicitações para a nova versão. Ou, ao contrário, retornar tudo para v1, se algo der errado com v2. Isso parece ser chamado de Canary Deployment ("implantação canário" — um termo , e se tivesse origens russas, provavelmente faria alusão a ), e agora iremos examinar isso mais de perto.
Canary Deployment no Istio: simplificando a implementação
Com cautela e lentamente
A essência do modelo de implementação Canary Deployment é extremamente simples: ao lançar uma nova versão de seu software (neste caso — micross serviço), você primeiro permite que um pequeno grupo de usuários tenha acesso a ele. Se tudo correr bem, você aumenta lentamente esse grupo até que a nova versão comece a falhar, ou — se isso não acontecer — eventualmente transfere todos os usuários para ela. Ao introduzir cuidadosamente e gradualmente a nova versão e controladamente mudar os usuários para ela, é possível reduzir riscos e maximizar o feedback.
Claro que o Istio simplifica o Canary Deployment, oferecendo várias boas opções para o roteamento inteligente de solicitações. E sim, tudo isso pode ser feito sem tocar no seu código-fonte.
Filtrando o navegador
Um dos critérios de roteamento mais simples é o redirecionamento com base no navegador. Suponha que você queira que apenas solicitações do navegador Safari sejam direcionadas para a v2. Veja como fazer isso:
Aplicaremos essa regra de roteamento e então com a equipe curl vamos simular em loop solicitações reais para o microsserviço. Como você pode ver na captura de tela, todas estão sendo direcionadas para a v1:
Mas onde está o tráfego para a v2? Como em nosso exemplo todas as solicitações vieram apenas da nossa linha de comando, elas simplesmente não existem. Mas note as linhas inferiores na captura acima: essa é a reação ao ter feito a solicitação a partir do navegador Safari, que retornou o seguinte:
Poder ilimitado
Já mencionamos que expressões regulares oferecem poderosas capacidades para roteamento de solicitações. Veja o próximo exemplo (acreditamos que você mesmo entenderá o que ele faz):
Agora você provavelmente já tem uma ideia do que as expressões regulares podem fazer.
Aja de forma inteligente
O roteamento inteligente, em particular o tratamento dos cabeçalhos de pacotes usando expressões regulares, permite controlar o tráfego como você desejar. E isso simplifica muito a introdução de novo código - é simples, não requer alterações no próprio código, e se necessário, tudo pode ser rapidamente revertido como estava.
Interessado?
Está animado para experimentar o Istio, Kubernetes e OpenShift no seu computador? A equipe preparou um ótimo sobre esse tema e disponibilizou todos os arquivos de apoio. Então, vá em frente e não se prive de nada.
Istio Egress: saída através da loja de souvenirs
Aplicando o Istio junto com Red Hat OpenShift e Kubernetes, você pode facilitar muito a sua vida com microsserviços. A malha de serviços do Istio está embutida dentro dos pods do Kubernetes, enquanto seu código é executado (principalmente) de forma isolada. Desempenho, facilidade de modificação, rastreamento e muito mais - tudo isso é fácil de utilizar devido à aplicação de contêineres sidecar. Mas o que fazer se seu microsserviço precisar se comunicar com outros serviços que estão fora do seu sistema OpenShift-Kubernetes?
Aqui entra o Istio Egress. Em poucas palavras, ele simplesmente permite acesso a recursos (leia-se: "serviços") que não fazem parte dos pods do seu sistema Kubernetes. Sem configurações adicionais, o tráfego no ambiente do Istio Egress é roteado apenas dentro do cluster de pods e entre clusters com base nas tabelas de IP internas. Esse encapsulamento funciona bem até que você precise acessar serviços externos.
O Egress permite contornar as tabelas de IP mencionadas acima, seja com base em regras de Egress ou para um intervalo de endereços IP.
Vamos supor que temos um programa Java que faz uma requisição GET para httpbin.org/headers.
(httpbin.org é apenas um recurso conveniente para testar solicitações de serviços de saída.)
Se digitarmos no terminal curl http://httpbin.org/headers, veremos o seguinte:
Ou podemos abrir esse mesmo endereço no navegador:
Como podemos ver, o serviço localizado lá simplesmente retorna os cabeçalhos que foram enviados a ele.
Vamos fazer um substituto direto
Agora, vamos pegar o código Java desse serviço externo em relação ao nosso sistema e executá-lo onde, lembremos, temos o Istio. (Você pode fazer isso sozinho, consultando o .) Após compilar a imagem correspondente e executá-la na plataforma OpenShift, chamaremos esse serviço com o comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, após o que veremos na tela o seguinte:
O que aconteceu? Estava funcionando, afinal. O que significa Not Found? Acabamos de criar para ele curl.
Expandindo as tabelas de IP para toda a internet
Devemos isso (ou agradecer) ao Istio. Afinal, o Istio é apenas contêineres sidecar, que são responsáveis pela descoberta e roteamento (e por muitas outras coisas das quais falamos anteriormente). Por essa razão, as tabelas de IP conhecem apenas o que está dentro do seu sistema de clusters. E httpbin.org está localizado fora e, portanto, não está acessível. É aí que o Istio Egress entra em cena – sem a menor mudança no seu código-fonte.
A regra de Egress abaixo faz o Istio procurar (se necessário, até em toda a internet) pelo serviço desejado, neste caso, httpbin.org. Como pode ser visto neste arquivo (egress_httpbin.yml), a funcionalidade aqui é bastante simples:
Basta aplicar essa regra:
istioctl create -f egress_httpbin.yml -n istioegress
Você pode visualizar as regras de Egress com o comando istioctl get egressrules:
E finalmente, executamos novamente o comando curl – e vemos que tudo funciona:
Pensamos de forma aberta
Como você pode ver, o Istio permite organizar a interação com o mundo externo. Em outras palavras, você ainda pode criar serviços OpenShift e gerenciá-los através do Kubernetes, mantendo tudo em pods que escalam para cima e para baixo conforme necessário. E você pode tranquilamente acessar serviços externos em relação ao seu ambiente. E sim, mais uma vez, reafirmamos que tudo isso pode ser feito sem alterar seu código.
Este foi o último post da série sobre Istio. Fique conosco – ainda temos muito conteúdo interessante pela frente!
Fonte: habr.com
