«Le danger est mon deuxième prénom», disait Austin Powers, un homme mystérieux d'envergure internationale. Mais ce qui est apprécié des super-agents et des services secrets ne convient pas du tout aux services informatiques, où l'ennui est bien meilleur que les dangers.
Avec Istio, OpenShift et Kubernetes, le déploiement de microservices devient réellement ennuyeux et prévisible – et c'est très bien. Nous en parlerons, ainsi que d'autres sujets, dans le quatrième et dernier article de la série sur Istio.
Quand l'ennui est une bonne chose
Dans notre cas, l'ennui ne se produit qu'à la phase finale, lorsque l'on doit juste s'asseoir et observer le processus. Mais pour cela, tout doit être configuré au préalable, et il y a beaucoup de choses intéressantes à faire ici.
Lorsque vous déployez une nouvelle version de votre logiciel, il est important d'envisager toutes les options pour minimiser les risques. Le fonctionnement en mode parallèle est une méthode de test très puissante et éprouvée, et Istio permet d'utiliser un «service secret» (une version cachée de votre microservice) sans interférer avec la production. Il existe même un terme spécialisé pour cela – «Lancement secret» (Dark Launch), qui est activé par une fonctionnalité avec un nom tout aussi mystérieux, «miroir du trafic».
Notez que dans la première phrase du paragraphe précédent, le terme «déploiement» (deploy) est utilisé, et non «lancement» (release). Vous devez 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, ainsi que d'écrire des logs et d'être surveillé. Cependant, cela ne signifie pas que ce service doit être mis en production. Déploiement et publication de logiciels ne sont pas toujours synonymes. Vous pouvez déployer quand vous le souhaitez, mais la publication ne peut se faire que lorsque vous êtes complètement prêt.
Organiser l'ennui est intéressant
Regardez la règle de routage Istio suivante, qui dirige toutes les requêtes HTTP vers le microservice recommendation v1 (tous les exemples sont extraits de ), tout en les reflétant sur le microservice recommendation v2 :
Notez l'étiquette mirror : en bas de l'écran – c'est elle qui détermine le miroir du trafic. Oui, c'est aussi simple que cela !
Le résultat de cette règle sera que votre système de production (v1) continuera à gérer les requêtes entrantes, mais les requêtes elles-mêmes seront simultanément dupliquées sur v2, c'est-à-dire que des copies complètes seront envoyées là-bas. Ainsi, vous pourrez tester le fonctionnement de v2 dans des conditions réelles — avec de vraies données et du trafic — sans interférer avec le fonctionnement du système de production. Cela transforme-t-il l'organisation des tests en quelque chose d'ennuyeux ? Oui, sans aucun doute. Mais c'est fait de manière intéressante.
Ajoutons un peu de drame
Notez que dans le code de v2, il faut prévoir des situations où les requêtes entrantes peuvent entraîner des modifications des données. Les requêtes se dupliquent facilement et de manière transparente, mais le choix de la méthode de traitement dans le test reste entre vos mains — et cela, c'est un peu inquiétant.
Répétons un point important
Le lancement secret avec duplication du trafic (Dark Launch/Request Mirroring) peut être effectué sans toucher au code.
Nourrissez votre réflexion
Et si, au lieu de dupliquer les requêtes vers v1, vous envoyiez une partie d'entre elles vers v2 ? Par exemple, un pourcentage de toutes les requêtes ou seulement les requêtes d'un certain groupe d'utilisateurs. Et ensuite, en observant comment fonctionne v2, vous pourriez progressivement transférer toutes les requêtes vers la nouvelle version. Ou inversement, revenir à v1 si quelque chose ne fonctionne pas avec v2. Cela semble s'appeler le Canary Deployment (« déploiement de canari » – un terme , et s'il avait une origine russe, il aurait probablement fait référence à ), et nous allons maintenant examiner cela plus en détail.
Canary Deployment dans Istio : simplification du déploiement
Avec prudence et progressivement
Le principe du modèle de déploiement Canary Deployment est extrêmement simple : lors du lancement d'une nouvelle version de votre logiciel (dans notre cas, d'un microservice), vous 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 à avoir des problèmes, ou — si cela ne se produit pas — vous transférez finalement tous les utilisateurs vers elle. En introduisant progressivement la nouvelle version et en contrôlant le transfert des utilisateurs, vous pouvez réduire les risques et maximiser les retours.
Bien sûr, Istio facilite le déploiement Canary en offrant plusieurs bonnes options pour le routage intelligent des requêtes. Et oui, tout cela peut être fait sans toucher à votre code source.
Filtrer par navigateur
Un des critères de routage les plus simples est le redirection en fonction du navigateur. Supposons que vous souhaitez que seules les requêtes provenant des navigateurs Safari aillent vers v2. Voici comment procéder :
Appliquons cette règle de routage et ensuite avec la commande curl nous allons simuler en boucle de vraies requêtes au microservice. Comme on peut le voir sur la capture d'écran, toutes sont dirigées vers v1 :
Mais où est le trafic vers v2 ? Puisque dans notre exemple, toutes les requêtes provenaient uniquement de notre ligne de commande, il n'existe tout simplement pas. Mais observez les lignes du bas sur la capture d'écran ci-dessus : c'est la réponse à notre requête effectuée depuis le navigateur Safari, qui a rendu ceci :
Pouvoir illimité
Nous avons déjà mentionné que les expressions régulières offrent des possibilités très puissantes pour le routage des requêtes. Regardez le prochain exemple (nous pensons que vous allez comprendre par vous-même ce qu'il fait) :
Maintenant, vous avez probablement déjà une idée de ce dont les expressions régulières sont capables.
Agissez intelligemment
Un routage intelligent, notamment le traitement des en-têtes de paquets à l'aide d'expressions régulières, vous permet de contrôler le trafic comme vous le souhaitez. Et cela simplifie considérablement la mise en service d'un nouveau code – c'est simple, cela ne nécessite pas de modification du code lui-même, et si nécessaire, tout peut être rapidement retourné à son état initial.
Intéressé ?
Enthousiasmé à l'idée d'expérimenter avec Istio, Kubernetes et OpenShift sur votre ordinateur ? L'équipe a préparé un excellent sur ce sujet et a mis tous les fichiers associés à la disposition du public. 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 grandement faciliter votre travail avec les microservices. La grille de services Istio est intégrée dans les pods Kubernetes, tandis que votre code s'exécute (principalement) de manière isolée. La performance, la facilité de modification, le traçage, etc. — tout cela est facilement accessible grâce à l'utilisation de conteneurs sidecar. Mais que faire si votre microservice doit communiquer avec d'autres services situés en dehors de votre système OpenShift-Kubernetes ?
C'est là qu'intervient Istio Egress. En termes simples, il permet d'accéder à des ressources (lire : « services ») qui ne font pas partie de votre système de pods Kubernetes. Si aucune configuration supplémentaire n'est effectuée, dans un environnement Istio Egress, le trafic est uniquement acheminé à l'intérieur du cluster de pods et entre ces clusters en fonction des tables IP internes. Et cette encapsulation fonctionne très bien jusqu'à ce que vous ayez besoin d'accéder à des services externes.
Egress permet de contourner les tables IP mentionnées ci-dessus, soit sur la base de règles Egress, soit pour une plage d'adresses IP.
Supposons que nous avons un programme Java qui effectue une requête GET à httpbin.org/headers.
(httpbin.org est simplement une ressource utile pour tester les requêtes de services sortants.)
Si nous entrons dans la ligne de commande curl http://httpbin.org/headers, nous verrons ce qui suit :
Ou vous pouvez ouvrir cette même adresse dans un navigateur :
Comme nous le voyons, le service situé là-bas retourne simplement les en-têtes qui lui ont été transmis.
Nous faisons du remplacement en plein visage
Prenons maintenant le code Java de ce service externe par rapport à notre système et lançons-le chez nous, où, rappelons-le, Istio est installé. (Vous pouvez le faire vous-même en vous référant à .) Après avoir construit l'image correspondante et l'avoir exécuté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 :
Oh, que s'est-il passé ? Ça fonctionnait tout à l'heure. Que signifie Not Found ? Nous venons juste de faire cela pour lui. curl.
Nous étendons les tables IP à l'ensemble d'Internet.
On doit le blâmer (ou le remercier) à Istio. En effet, Istio consiste simplement en des conteneurs sidecar, qui sont responsables de la découverte et du routage (et de nombreuses autres choses dont nous avons parlé précédemment). Pour cette raison, les tables IP ne connaissent que ce qui se trouve à l'intérieur de votre système de clusters. Et httpbin.org est à l'extérieur, donc inaccessible. C'est ici qu'intervient Istio Egress – sans aucune modification de votre code source.
La règle Egress suivante oblige Istio à rechercher (si nécessaire, dans le monde entier) le service requis, en l'occurrence httpbin.org. Comme on peut le voir dans ce fichier (egress_httpbin.yml), la fonctionnalité ici est plutôt simple :
Il ne reste plus qu'à appliquer cette règle :
istioctl create -f egress_httpbin.yml -n istioegress
Vous pouvez consulter les règles Egress avec la commande istioctl get egressrules:
Et enfin, relançons la commande curl – et voyons que tout fonctionne :
Pensons de manière ouverte
Comme vous pouvez le voir, Istio permet d'organiser les interactions avec le monde extérieur. En d'autres termes, vous pouvez toujours créer des services OpenShift et les gérer via Kubernetes, en maintenant tout dans des pods, qui se développent ou se réduisent en fonction des besoins. Et en plus, vous pouvez tranquillemen t'accéder à des services externes à votre environnement. Et oui, encore une fois, nous voulons rappeler que tout cela peut être fait sans toucher à votre code.
C'était le dernier post d'une série sur Istio. Restez avec nous – il y a encore beaucoup de choses intéressantes à venir !
Source : habr.com
