“Perigo é meu nome do meio”, costumava dizer Austin Powers, um homem misterioso internacional. Mas o que é tido em alta estima pelos superagentes e pelos serviços de inteligência não é de todo adequado para os serviços informáticos, onde o tédio é muito melhor do que o perigo.
E o Istio, junto com o OpenShift e o Kubernetes, torna a implantação de microsserviços realmente enfadonha e previsível – 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 observar o processo. Mas para isso você precisa configurar tudo primeiro, e muitas coisas interessantes esperam por você aqui.
Ao implantar uma nova versão do seu software, vale a pena considerar todas as opções para minimizar os riscos. Executar em paralelo é uma forma de teste muito poderosa e comprovada, e o Istio permite que você use um “serviço secreto” (uma versão oculta do seu microsserviço) para fazer isso sem interferir no sistema de produção. Existe até um termo especial para isso – “Dark Launch”, que por sua vez é ativado por uma função com nome igualmente espião “espelhamento de tráfego”.
Observe que a primeira frase do parágrafo anterior usa o termo “implantar” em vez de “liberar”. Você realmente deve ser capaz de implantar — e, claro, usar — seu microsserviço com a freqüência que desejar. Este serviço deve ser capaz de receber e processar tráfego, produzir resultados e também gravar em logs e monitorar. Mas, ao mesmo tempo, este serviço em si não precisa necessariamente ser colocado em produção. Implantar e lançar software nem sempre são a mesma coisa. Você pode implantar quando quiser, mas liberar somente quando estiver pronto.
Organizar o tédio é interessante
Dê uma olhada na seguinte regra de roteamento do Istio, que roteia todas as solicitações HTTP para a recomendação de microsserviço v1 (todos os exemplos retirados de ), ao mesmo tempo que os espelha para o microsserviço de recomendação v2:
Preste atenção ao rótulo mirror: na parte inferior da tela - é isso que define o espelhamento do tráfego. Sim, é simples assim!
O resultado desta regra será que seu sistema de produção (v1) continuará processando solicitações recebidas, mas as próprias solicitações serão espelhadas de forma assíncrona para v2, ou seja, suas duplicatas completas irão para lá. Dessa forma, você pode testar a v2 em condições reais – com dados e tráfego reais – sem interferir de forma alguma na operação do sistema de produção. Isso torna a organização dos testes chata? Sim definitivamente. Mas isso é feito de uma forma interessante.
Vamos adicionar drama
Observe que no código v2 é necessário prever situações em que as solicitações recebidas podem levar a alterações de dados. As solicitações em si são espelhadas de forma fácil e transparente, mas a escolha do método de processamento no teste fica por sua conta – 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 executado sem afetar o código de forma alguma.
Alimento para o pensamento
E se o local onde as solicitações são espelhadas enviar algumas delas não para v1, mas para v2? Por exemplo, um por cento de todas as solicitações ou apenas solicitações de um determinado grupo de usuários. E então, já observando como funciona a v2, transfira gradativamente todas as solicitações para a nova versão. Ou vice-versa, retorne tudo para v1 se algo der errado com v2. Acho que se chama Canary Deployment. , e se fosse de origem russa, provavelmente conteria uma referência a ), e agora veremos isso com mais detalhes.
Implantação Canary no Istio: simplificando o comissionamento
Com cuidado e gradualmente
A essência do modelo de implantação Canary Deployment é extremamente simples: ao lançar uma nova versão do seu software (no nosso caso, um microsserviço), você primeiro concede acesso a ele a um pequeno grupo de usuários. Se tudo correr bem, você aumenta lentamente esse grupo até que a nova versão comece a funcionar ou - se isso não acontecer - eventualmente migre todos os usuários para ele. Ao introduzir de forma cuidadosa e gradual uma nova versão e transferir usuários para ela de maneira controlada, você pode reduzir riscos e maximizar o feedback.
Obviamente, o Istio simplifica a implantação Canary, oferecendo várias boas opções para roteamento inteligente de solicitações. E sim, tudo isso pode ser feito sem mexer no código-fonte de forma alguma.
Filtrando o navegador
Um dos critérios de roteamento mais simples é o redirecionamento baseado em navegador. Digamos que você queira que apenas as solicitações dos navegadores Safari vão para a v2. Veja como isso é feito:
Vamos aplicar esta regra de roteamento e então usar o comando curl Simularemos solicitações reais ao microsserviço em loop. Como você pode ver na captura de tela, todos eles vão para v1:
Onde está o tráfego na v2? Como no nosso exemplo todas as solicitações vieram apenas da nossa própria linha de comando, ela simplesmente não existe. Mas preste atenção ao resultado final da tela acima: esta é uma reação ao fato de termos executado uma solicitação do navegador Safari, que por sua vez produziu isto:
Poder ilimitado
Já escrevemos que as expressões regulares fornecem recursos muito poderosos para rotear solicitações. Dê uma olhada no exemplo a seguir (achamos que você 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 processamento de cabeçalhos de pacotes usando expressões regulares, permite gerenciar o tráfego da maneira desejada. E isso simplifica muito a implementação do novo código - é simples, não requer alteração do código em si e, se necessário, tudo pode ser retornado rapidamente como estava.
Interessado?
Você está ansioso para experimentar Istio, Kubernetes e OpenShift em seu computador? Equipe preparou um excelente sobre este tópico e disponibilizou publicamente todos os arquivos que o acompanham. Então vá em frente e não negue nada a si mesmo.
Istio Egress: saída pela loja de souvenirs
Ao usar o Istio junto com o Red Hat OpenShift e o Kubernetes, você pode tornar sua vida com microsserviços muito mais fácil. A malha de serviço do Istio está oculta dentro dos pods do Kubernetes e seu código é executado (principalmente) isoladamente. Desempenho, facilidade de troca, rastreamento, etc. – tudo isso é fácil de usar graças ao 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. Resumindo, ele simplesmente permite que você acesse recursos (leia-se: “serviços”) que não fazem parte do seu sistema de pods Kubernetes. Se você não executar configurações adicionais, no ambiente de saída do Istio o tráfego será roteado apenas dentro de um cluster de pods e entre esses clusters com base em tabelas IP internas. E essa pupação funciona muito bem, desde que você não precise de acesso a serviços externos.
A saída permite ignorar as tabelas de IP acima, com base nas regras de saída ou em um intervalo de endereços IP.
Digamos que temos um programa Java que faz 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 na linha de comando curl http://httpbin.org/headers, veremos o seguinte:
Ou você pode abrir o mesmo endereço no navegador:
Como você pode ver, o serviço localizado ali simplesmente retorna os cabeçalhos passados a ele.
Substituição de importação de frente
Agora vamos pegar o código Java deste serviço, externo ao nosso sistema, e executá-lo por conta própria, onde, lembre-se, o Istio está instalado. (Você pode fazer isso sozinho entrando em contato .) Depois de construir a imagem apropriada e lançá-la na plataforma OpenShift, chamaremos este serviço com o comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, após o qual veremos isso na tela:
Ops, o que aconteceu? Tudo simplesmente funcionou. O que significa Não encontrado? Nós apenas fizemos isso por ele curl.
Estendendo tabelas IP para toda a Internet
O Istio deveria ser culpado (ou agradecido) por isso. Afinal, o Istio é apenas um contêiner secundário responsável pela detecção e roteamento (e muitas outras coisas sobre as quais falamos anteriormente). Por esse motivo, as tabelas IP só sabem o que está dentro do seu sistema de cluster. E httpbin.org está localizado fora e, portanto, inacessível. E é aqui que o Istio Egress vem em socorro - sem a menor alteração no seu código-fonte.
A regra de saída abaixo força o Istio a pesquisar (se necessário, em toda a Internet) o serviço necessário, neste caso, httpbin.org. Como você pode ver neste arquivo (egress_httpbin.yml), a funcionalidade aqui é bastante simples:
Resta 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, executamos o comando novamente enrolar – e vemos que 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 gerenciá-los por meio do Kubernetes, mantendo tudo em pods que podem ser ampliados ou reduzidos 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 mexer no seu código de forma alguma.
Este foi o último post da série no Istio. Fique ligado - há muitas coisas interessantes pela frente!
Fonte: habr.com