"Perigo é o meu segundo nome", adoitaba dicir Austin Powers, un home misterioso internacional. Pero o que teñen en gran estima os súper axentes e os servizos de intelixencia non é nada axeitado para os servizos informáticos, onde o aburrimento é moito mellor que o perigo.
E Istio, xunto con OpenShift e Kubernetes, fai que a implantación de microservizos sexa realmente aburrida e previsible, e iso é xenial. Disto e moito máis falaremos no cuarto e último post da serie Istio.
Cando o aburrimento é correcto
No noso caso, o aburrimento prodúcese só na fase final, cando só queda sentarse a ver o proceso. Pero para iso debes configurar todo primeiro, e aquí te esperan moitas cousas interesantes.
Ao implementar unha nova versión do seu software, paga a pena considerar todas as opcións para minimizar os riscos. Executar en paralelo é unha forma moi poderosa e comprobada de probar, e Istio permíteche usar un "servizo secreto" (unha versión oculta do teu microservizo) para facelo sen interferir co sistema de produción. Incluso hai un termo especial para iso: "Dark Launch", que á súa vez está activado por unha función cun nome igualmente espía "replicación de tráfico".
Teña en conta que a primeira frase do parágrafo anterior usa o termo "desplegar" en lugar de "liberar". Realmente deberías poder implementar e, por suposto, usar o teu microservizo tantas veces como queiras. Este servizo debe ser capaz de recibir e procesar tráfico, producir resultados e tamén escribir nos rexistros e supervisar. Pero, ao mesmo tempo, este servizo en si non necesariamente necesita ser lanzado en produción. Implementar e liberar software non sempre é o mesmo. Podes implementar cando queiras, pero lanzar só cando esteas listo.
Organizar o aburrimento é interesante
Bótalle un ollo á seguinte regra de enrutamento de Istio, que encamiña todas as solicitudes HTTP á recomendación de microservizos v1 (todos os exemplos tomados de ), ao mesmo tempo que os reflicte no microservizo de recomendación v2:
Preste atención á etiqueta mirror: na parte inferior da pantalla: isto é o que establece a duplicación do tráfico. Si, é así de sinxelo!
O resultado desta regra será que o seu sistema de produción (v1) seguirá procesando as solicitudes entrantes, pero as propias solicitudes serán reflectidas de forma asíncrona na v2, é dicir, os seus duplicados completos irán alí. Deste xeito, podes probar v2 en condicións reais -sobre datos e tráfico reais- sen interferir de ningún xeito no funcionamento do sistema de produción. Isto fai que a organización das probas sexa aburrida? Si, definitivamente. Pero faise dun xeito interesante.
Engadimos dramatismo
Teña en conta que no código v2 é necesario prever situacións nas que as solicitudes entrantes poidan levar a cambios de datos. As solicitudes en si replícanse de xeito sinxelo e transparente, pero a elección do método de procesamento na proba depende de ti, e isto é un pouco preocupante.
Repetimos un punto importante
O lanzamento secreto con espello de tráfico (Dark Launch/Request Mirroring) pódese realizar sen afectar o código de ningún xeito.
Comida para pensar
E se o lugar onde se duplican as solicitudes envía algunhas delas non á v1, senón á v2? Por exemplo, un por cento de todas as solicitudes ou só as solicitudes dun determinado grupo de usuarios. E despois, xa mirando como funciona a versión 2, transfire gradualmente todas as solicitudes á nova versión. Ou viceversa, devolve todo a v1 se algo sae mal con v2. Creo que se chama Despliegue Canario. , e se fose de orixe rusa, probablemente conteña unha referencia a ), e agora veremos isto con máis detalle.
Despliegue Canario en Istio: simplificando a posta en servizo
Con coidado e gradualmente
A esencia do modelo de implantación de Canary Deployment é extremadamente sinxela: cando lanzas unha nova versión do teu software (no noso caso, un microservizo), primeiro dás acceso a ela a un pequeno grupo de usuarios. Se todo vai ben, vai aumentando este grupo aos poucos ata que a nova versión comece a actuar, ou, se non, eventualmente migrar a el todos os usuarios. Ao introducir coidadosamente e gradualmente unha nova versión e cambiar os usuarios a ela dun xeito controlado, pode reducir os riscos e maximizar os comentarios.
Por suposto, Istio simplifica Canary Deployment ofrecendo varias boas opcións para o enrutamento intelixente de solicitudes. E si, todo isto pódese facer sen tocar o seu código fonte de ningún xeito.
Filtrando o navegador
Un dos criterios de enrutamento máis sinxelos é a redirección baseada no navegador. Digamos que só queres que as solicitudes dos navegadores Safari vaian á versión 2. Velaquí como se fai:
Apliquemos esta regra de enrutamento e despois usemos o comando curl Simularemos solicitudes reais ao microservizo nun bucle. Como podes ver na captura de pantalla, todos van á v1:
Onde está o tráfico na v2? Xa que no noso exemplo todas as solicitudes proviñan só da nosa propia liña de comandos, simplemente non existe. Pero preste atención ás liñas inferiores da pantalla anterior: esta é unha reacción ao feito de que executamos unha solicitude do navegador Safari, que á súa vez produciu isto:
Poder ilimitado
Xa escribimos que as expresións regulares proporcionan capacidades moi poderosas para enrutar solicitudes. Bótalle un ollo ao seguinte exemplo (creemos que entenderás o que fai):
Ata agora probablemente teñas unha idea do que poden facer as expresións regulares.
Actúa intelixente
O enrutamento intelixente, en particular o procesamento de cabeceiras de paquetes mediante expresións regulares, permítelle dirixir o tráfico como quere. E isto simplifica moito a implementación do novo código: é sinxelo, non require cambiar o propio código e, se é necesario, pódese devolver todo rapidamente como estaba.
Interesado?
Estás ansioso por experimentar con Istio, Kubernetes e OpenShift no teu ordenador? Equipo preparou un excelente sobre este tema e puxo a disposición do público todos os ficheiros que o acompañan. Así que adiante e non te negues nada.
Istio Egress: saída pola tenda de souvenirs
Ao usar Istio xunto con Red Hat OpenShift e Kubernetes, podes facilitar moito a túa vida cos microservizos. A malla de servizo de Istio está oculta dentro dos pods de Kubernetes e o teu código execútase (principalmente) de forma illada. Rendemento, facilidade de cambio, trazado, etc.: todo isto é fácil de usar grazas ao uso de contedores sidecar. Pero que pasa se o teu microservizo precisa comunicarse con outros servizos que se atopan fóra do teu sistema OpenShift-Kubernetes?
Aquí é onde Istio Egress vén ao rescate. En poucas palabras, simplemente permíteche acceder a recursos (léase: "servizos") que non forman parte do teu sistema de pods de Kubernetes. Se non realiza unha configuración adicional, no contorno Istio Egress o tráfico só se encamiña dentro dun clúster de pods e entre tales clústeres baseados en táboas IP internas. E tal pupación funciona moi ben sempre que non necesites acceso a servizos desde fóra.
Egress permítelle ignorar as táboas IP anteriores, xa sexa en función das regras de saída ou nunha serie de enderezos IP.
Digamos que temos un programa Java que fai unha solicitude GET a httpbin.org/headers.
(httpbin.org é só un recurso conveniente para probar as solicitudes de servizo saíntes).
Se ingresas na liña de comandos curl http://httpbin.org/headers, veremos o seguinte:
Ou pode abrir o mesmo enderezo no navegador:
Como podes ver, o servizo alí situado simplemente devolve as cabeceiras que lle pasaron.
Estamos a substituír as importacións frontalmente
Agora tomemos o código Java deste servizo, externo ao noso sistema, e executémolo pola nosa conta, onde, recordemos, está instalado Istio. (Podes facelo vostede mesmo contactando .) Unha vez construída a imaxe adecuada e lanzada na plataforma OpenShift, chamaremos a este servizo co comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, despois de que veremos isto na pantalla:
Vaia, que pasou? Todo funcionou. Que significa Non atopado? Só o fixemos por el curl.
Estendendo as táboas IP a toda Internet
Istio debe ser culpado (ou agradecedo) por isto. Despois de todo, Istio son só contedores de sidecar que son responsables da detección e enrutamento (e moitas outras cousas das que falamos anteriormente). Por este motivo, as táboas IP só saben o que hai dentro do seu sistema de clúster. E httpbin.org está situado fóra e, polo tanto, inaccesible. E aquí é onde Istio Egress vén ao rescate, sen o máis mínimo cambio no seu código fonte.
A seguinte regra de saída obriga a Istio a buscar (se é necesario, logo en toda Internet) o servizo necesario, neste caso, httpbin.org. Como podes ver neste ficheiro (egress_httpbin.yml), a funcionalidade aquí é bastante sinxela:
Só queda aplicar esta regra:
istioctl create -f egress_httpbin.yml -n istioegress
Podes ver as regras de saída co comando istioctl get egressrules:
E, finalmente, executamos o comando de novo enrolar – e vemos que todo funciona:
Pensamos abertamente
Como podes ver, Istio permíteche organizar a interacción co mundo exterior. Noutras palabras, aínda podes crear servizos OpenShift e xestionalos a través de Kubernetes, mantendo todo en pods que aumentan e baixan segundo sexa necesario. E ao mesmo tempo, pode acceder con seguridade a servizos externos ao seu contorno. E si, repetimos unha vez máis que todo isto pódese facer sen tocar o teu código de ningún xeito.
Esta foi a última publicación da serie sobre Istio. Estade atentos: hai moitas cousas interesantes por diante!
Fonte: www.habr.com