«Le danger est mon deuxième prénom», disait Austin Powers, un homme mystérieux international. Mais ce qui est tenu en haute estime par les super-agents et les services de renseignement n'est pas du tout adapté aux services informatiques, où l'ennui vaut bien mieux que le danger.
Et Istio, avec OpenShift et Kubernetes, rend le déploiement de microservices vraiment ennuyeux et prévisible – et c'est génial. Nous en parlerons et bien plus encore dans le quatrième et dernier article de la série Istio.
Quand l'ennui a raison
Dans notre cas, l’ennui ne survient que dans la phase finale, lorsqu’il ne reste plus qu’à s’asseoir et observer le processus. Mais pour cela, vous devez d'abord tout configurer, et beaucoup de choses intéressantes vous attendent ici.
Lors du déploiement d'une nouvelle version de votre logiciel, il convient d'envisager toutes les options permettant de minimiser les risques. L'exécution en parallèle est un moyen de test très puissant et éprouvé, et Istio vous permet d'utiliser un « service secret » (une version cachée de votre microservice) pour le faire sans interférer avec le système de production. Il existe même un terme spécial pour cela - "Dark Launch", qui à son tour est activé par une fonction portant le nom tout aussi espion de "trafic miroir".
Veuillez noter que la première phrase du paragraphe précédent utilise le terme « déployer » plutôt que « publier ». Vous devriez vraiment pouvoir déployer (et, bien sûr, utiliser) votre microservice aussi souvent que vous le souhaitez. Ce service doit être capable de recevoir et de traiter le trafic, de produire des résultats, mais également d'écrire dans les journaux et de le surveiller. Mais en même temps, ce service lui-même n'a pas nécessairement besoin d'être mis en production. Déployer et publier un logiciel ne sont pas toujours la même chose. Vous pouvez déployer quand vous le souhaitez, mais ne publier que lorsque vous êtes prêt.
Organiser l'ennui est intéressant
Jetez un œil à la règle de routage Istio suivante, qui achemine toutes les requêtes HTTP vers la recommandation de microservice v1 (tous les exemples tirés de ), tout en les reflétant simultanément dans le microservice de recommandation v2 :
Faites attention à l'étiquette mirror: en bas de l'écran - c'est cela qui définit la mise en miroir du trafic. Oui, c'est aussi simple que ça !
Le résultat de cette règle sera que votre système de production (v1) continuera à traiter les demandes entrantes, mais les demandes elles-mêmes seront mises en miroir de manière asynchrone vers la v2, c'est-à-dire que leurs doublons complets y iront. Ainsi, vous pouvez tester la v2 en conditions réelles – sur des données et du trafic réels – sans interférer en aucune façon avec le fonctionnement du système de production. Est-ce que cela rend l’organisation des tests ennuyeuse ? Oui définitivement. Mais c'est fait d'une manière intéressante.
Ajoutons du drame
Veuillez noter que dans le code v2, il est nécessaire de prévoir les situations dans lesquelles les demandes entrantes peuvent entraîner des modifications des données. Les requêtes elles-mêmes sont reflétées de manière simple et transparente, mais le choix de la méthode de traitement dans le test dépend de vous – et c'est un peu inquiétant.
Répétons un point important
Le lancement secret avec mise en miroir du trafic (Dark Launch/Request Mirroring) peut être effectué sans affecter le code de quelque manière que ce soit.
Nourriture pour la pensée
Et si l'endroit où les requêtes sont mises en miroir en envoyait certaines non pas vers la v1, mais vers la v2 ? Par exemple, un pour cent de toutes les demandes ou uniquement les demandes d'un certain groupe d'utilisateurs. Et puis, en regardant déjà le fonctionnement de la v2, transférez progressivement toutes les demandes vers la nouvelle version. Ou vice versa, renvoyez tout à la v1 si quelque chose ne va pas avec la v2. Je pense que cela s'appelle Canary Deployment. , et s'il était d'origine russe, il contiendrait probablement une référence à ), et nous allons maintenant examiner cela plus en détail.
Déploiement Canary dans Istio : simplifier la mise en service
Avec précaution et progressivement
L'essence du modèle de déploiement de Canary Deployment est extrêmement simple : lorsque vous lancez une nouvelle version de votre logiciel (dans notre cas, un microservice), vous en donnez d'abord accès à un petit groupe d'utilisateurs. Si tout se passe bien, vous augmentez lentement ce groupe jusqu'à ce que la nouvelle version commence à fonctionner, ou - si ce n'est pas le cas - vous y migrez éventuellement tous les utilisateurs. En introduisant de manière réfléchie et progressive une nouvelle version et en y faisant basculer les utilisateurs de manière contrôlée, vous pouvez réduire les risques et maximiser les retours.
Bien entendu, Istio simplifie le déploiement de Canary en proposant plusieurs bonnes options pour le routage intelligent des requêtes. Et oui, tout cela peut être fait sans toucher en aucune façon à votre code source.
Filtrage du navigateur
L'un des critères de routage les plus simples est la redirection basée sur le navigateur. Supposons que vous souhaitiez que seules les requêtes des navigateurs Safari soient transmises à la version v2. Voici comment procéder :
Appliquons cette règle de routage puis utilisons la commande curl Nous simulerons des requêtes réelles au microservice en boucle. Comme vous pouvez le voir sur la capture d'écran, ils vont tous vers la v1 :
Où est le trafic sur la v2 ? Puisque dans notre exemple, toutes les requêtes provenaient uniquement de notre propre ligne de commande, cela n'existe tout simplement pas. Mais faites attention aux lignes du bas de l'écran ci-dessus : il s'agit d'une réaction au fait que nous avons exécuté une requête du navigateur Safari, qui à son tour a produit ceci :
Pouvoir illimité
Nous avons déjà écrit que les expressions régulières offrent des capacités très puissantes pour le routage des requêtes. Jetez un œil à l’exemple suivant (nous pensons que vous comprendrez ce qu’il fait) :
Vous avez probablement maintenant une idée de ce que les expressions régulières peuvent faire.
Agissez intelligemment
Le routage intelligent, notamment le traitement des en-têtes de paquets à l'aide d'expressions régulières, permet d'orienter le trafic comme vous le souhaitez. Et cela simplifie grandement la mise en œuvre du nouveau code - c'est simple, cela ne nécessite pas de modifier le code lui-même, et si nécessaire, tout peut être rapidement rendu tel qu'il était.
Intéressé?
Avez-vous hâte d'expérimenter Istio, Kubernetes et OpenShift sur votre ordinateur ? Équipe préparé un excellent sur ce sujet et a rendu publics tous les fichiers qui l'accompagnent. Alors allez-y et ne vous refusez rien.
Istio Egress : sortie par la boutique de souvenirs
En utilisant Istio avec Red Hat OpenShift et Kubernetes, vous pouvez vous simplifier la vie avec les microservices. Le maillage de services d'Istio est caché dans les pods Kubernetes et votre code s'exécute (principalement) de manière isolée. Performance, facilité de changement, traçabilité, etc. – tout cela est facile à utiliser grâce à l’utilisation de conteneurs side-car. Mais que se passe-t-il si votre microservice doit communiquer avec d’autres services situés en dehors de votre système OpenShift-Kubernetes ?
C'est là qu'Istio Egress vient à la rescousse. En un mot, il vous permet simplement d'accéder à des ressources (lire : « services ») qui ne font pas partie de votre système de pods Kubernetes. Si vous n'effectuez pas de configuration supplémentaire, dans l'environnement Istio Egress, le trafic est acheminé uniquement au sein d'un cluster de pods et entre ces clusters en fonction des tables IP internes. Et une telle pupaison fonctionne très bien tant que vous n'avez pas besoin d'accéder à des services extérieurs.
Egress vous permet de contourner les tables IP ci-dessus, soit sur la base de règles de sortie, soit sur une plage d'adresses IP.
Disons que nous avons un programme Java qui envoie une requête GET à httpbin.org/headers.
(httpbin.org n'est qu'une ressource pratique pour tester les demandes de service sortantes.)
Si vous entrez sur la ligne de commande curl http://httpbin.org/headers, nous verrons ce qui suit :
Ou vous pouvez ouvrir la même adresse dans le navigateur :
Comme vous pouvez le constater, le service qui s'y trouve renvoie simplement les en-têtes qui lui sont transmis.
Nous remplaçons de front les importations
Prenons maintenant le code Java de ce service, externe à notre système, et exécutons-le par nous-mêmes, là où, rappelons-le, Istio est installé. (Vous pouvez le faire vous-même en contactant .) Après avoir construit l'image appropriée et l'avoir lancée sur la plateforme OpenShift, nous appellerons ce service avec la commande curl egresshttpbin-istioegress.$(minishift ip).nip.io, après quoi nous verrons ceci à l'écran :
Oups, que s'est-il passé ? Tout a fonctionné. Que signifie Introuvable ? Nous venons de le faire pour lui curl.
Extension des tables IP à l'ensemble d'Internet
Istio devrait être blâmé (ou remercié) pour cela. Après tout, Istio n'est qu'un conteneur side-car responsable de la détection et du routage (et de bien d'autres choses dont nous avons parlé plus tôt). Pour cette raison, les tables IP connaissent uniquement le contenu de votre système de cluster. Et httpbin.org est situé à l’extérieur et donc inaccessible. Et c'est là qu'Istio Egress vient à votre secours, sans la moindre modification de votre code source.
La règle de sortie ci-dessous oblige Istio à rechercher (si nécessaire, puis sur tout Internet) le service requis, dans ce cas, httpbin.org. Comme vous pouvez le voir sur ce fichier (egress_httpbin.yml), la fonctionnalité ici est assez simple :
Il ne reste plus qu'à appliquer cette règle :
istioctl create -f egress_httpbin.yml -n istioegress
Vous pouvez afficher les règles de sortie avec la commande istioctl get egressrules:
Et enfin, nous exécutons à nouveau la commande boucle – et on voit que tout fonctionne :
Nous pensons ouvertement
Comme vous pouvez le constater, Istio permet d'organiser l'interaction avec le monde extérieur. En d’autres termes, vous pouvez toujours créer des services OpenShift et les gérer via Kubernetes, en conservant tout dans des pods qui évoluent selon les besoins. Et en même temps, vous pouvez accéder en toute sécurité à des services externes à votre environnement. Et oui, nous répétons encore une fois que tout cela peut être fait sans toucher en aucune façon à votre code.
C'était le dernier article de la série sur Istio. Restez à l'écoute - il y a beaucoup de choses intéressantes à venir !
Source: habr.com