"Le danger est mon deuxième prénom", a déclaré Austin Powers, un homme mystère à l'échelle internationale. Mais ce qui est tenu en haute estime par les super-agents et les services spéciaux ne convient pas du tout aux services informatiques, où les choses ennuyeuses sont bien meilleures que les dangers.
Et Istio, avec OpenShift et Kubernetes, rendent les déploiements de micro-services vraiment ennuyeux et prévisibles - et c'est génial. Nous en parlerons et bien plus dans le quatrième et dernier post de la série Istio.Quand l'ennui a raison
Dans notre cas, l'ennui ne se produit que dans la phase finale, quand il ne reste plus qu'à s'asseoir et regarder le processus. Mais pour cela, vous devez tout pré-configurer, et ici vous trouverez beaucoup de choses intéressantes.Lors du déploiement d'une nouvelle version de votre logiciel, vous devez considérer toutes les options pour minimiser les risques. Travailler en mode parallèle est une méthode de test très puissante et éprouvée, et Istio vous permet d'utiliser le "service secret" (une version de votre microservice cachée des regards indiscrets) pour cela sans interférer avec le système de production. Il y a même un terme spécial pour cela - "Secret Launch" (Dark Launch), qui à son tour est activé par une fonction avec le moins de spywares "traffic mirroring".Notez que la première phrase du paragraphe précédent utilise le terme «déployer» plutôt que «libérer». Vous devriez vraiment pouvoir déployer - et, bien sûr, utiliser - votre microservice aussi souvent que vous le souhaitez. Ce service doit pouvoir recevoir et traiter le trafic, produire des résultats, ainsi qu'écrire dans les journaux et surveiller. Mais en même temps, ce service lui-même n'a pas du tout besoin d'être mis en production. Le déploiement et la libération de logiciels ne sont pas toujours la même chose. Vous pouvez effectuer le déploiement quand vous le souhaitez, mais ne le libérer que lorsque vous êtes complètement 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 le microservice de recommandation v1 (tous les exemples proviennent du référentiel Istio Tutorial GitHub ), tout en les mettant en miroir vers le microservice de recommandation v2:Faites attention à l'étiquette mirror:en bas de l'écran - c'est elle qui définit la mise en miroir du trafic. Oui, c'est tellement simple!Le résultat de cette règle sera que votre système de production (v1) continuera de traiter les demandes entrantes, mais les demandes elles-mêmes seront mises en miroir de manière asynchrone sur la v2, c'est-à-dire que leurs doublons complets y iront. Ainsi, vous pouvez tester le travail de la v2 en conditions réelles - sur des données et du trafic réels - sans interférer avec le travail du système de production. Est-ce que cela rend l'organisation des tests ennuyeuse? Oui bien sûr. Mais cela se fait de façon intéressante.Ajouter un drame
Veuillez noter que dans le code v2, il est nécessaire de prévoir les situations où les demandes entrantes peuvent entraîner des modifications de données. Les requêtes elles-mêmes sont reflétées facilement et de manière transparente, mais le choix de la méthode de traitement dans le test vous appartient - et c'est déjà un peu excitant.Répétez le point important
Un lancement secret avec mise en miroir du trafic (Dark Launch / Request Mirroring) peut être effectué sans affecter le code.Nourriture pour la pensée
Mais que se passe-t-il si l'endroit pour refléter les demandes est d'en envoyer certaines non pas à la v1, mais à la v2? Par exemple, un pour cent de toutes les demandes ou uniquement les demandes d'un groupe d'utilisateurs spécifique. Et puis, en regardant déjà comment fonctionne la v2, transférez progressivement toutes les demandes vers la nouvelle version. Ou vice versa, remettez tout en v1 si quelque chose ne va pas avec v2. Il semble s'appeler Canary Deployment («canary deployment» - le terme remonte à l'exploitation minière , et s'il était d'origine russe, il contiendrait probablement une référence aux chats ), et maintenant nous allons l'examiner plus en détail.Déploiement des Canaries à Istio: simplifier la mise en service
Attention et progressivement
L'essence du modèle de déploiement Canary Deployment est extrêmement simple: lorsque vous démarrez une nouvelle version de votre logiciel (dans notre cas, le microservice), vous donnez d'abord accès à celui-ci à un petit groupe d'utilisateurs. Si tout se passe bien, vous augmentez lentement ce groupe jusqu'à ce que la nouvelle version commence à être indésirable, ou - si cela ne se produit pas - transférez éventuellement tous les utilisateurs. En introduisant consciencieusement et progressivement une nouvelle version en fonctionnement et en basculant les utilisateurs de manière contrôlée, vous pouvez réduire les risques et maximiser le retour d'informations.Bien sûr, Istio simplifie le déploiement de 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 le navigateur
L'un des critères de routage les plus simples est la redirection basée sur un navigateur. Supposons que vous souhaitiez que la v2 envoie uniquement des demandes à partir des navigateurs Safari. Voici comment procéder:Nous appliquons cette règle de routage, puis avec la commande, curlnous simulerons des demandes réelles au microservice en boucle. Comme vous pouvez le voir sur la capture d'écran, ils vont tous à la v1:Et où est le trafic sur la v2? Étant donné que dans notre exemple, toutes les demandes proviennent uniquement de notre propre ligne de commande, cela n'existe tout simplement pas. Mais faites attention aux résultats de la capture d'écran ci-dessus: c'est une réaction au fait que nous avons exécuté la demande du navigateur Safari, qui à son tour a émis 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 vous-même ce qu'il fait):Maintenant, vous savez probablement déjà de quoi les expressions régulières sont capables.Agissez intelligemment
Le routage intelligent, en particulier le traitement des en-têtes de paquets à l'aide d'expressions régulières, vous permet de générer du trafic comme vous le souhaitez. Et cela simplifie considérablement la mise en service du nouveau code - c'est simple, cela ne nécessite pas de changer le code lui-même, et si nécessaire, tout peut être rapidement retourné tel quel.Intéressé par?
Êtes-vous impatient d'expérimenter avec Istio, Kubernetes et OpenShift sur votre ordinateur? L' équipe de développeurs Red Hat a préparé un excellent didacticiel sur ce sujet et a partagé tous les fichiers associés. Alors allez-y, et ne vous refusez rien. Istio Egress: sortie par la boutique de cadeaux
L'utilisation d'Istio avec Red Hat OpenShift et Kubernetes peut grandement vous simplifier la vie avec les microservices. La grille de l'utilitaire Istio est cachée dans les pods Kubernetes et votre code est exécuté (principalement) de manière isolée. Performance, facilité de changement, de traçage et plus encore - tout cela est facile à utiliser précisément grâce à l'utilisation de sidecar-containers. 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 sont pas incluses dans votre système de pod Kubernetes. Si vous n'effectuez pas de configuration supplémentaire, dans l'environnement Istio Egress, le trafic est acheminé uniquement à l'intérieur du cluster de pods et entre ces clusters en fonction des tables IP internes. Et ce genre de mise en scène fonctionne très bien jusqu'à ce que vous ayez besoin d'accéder aux services de l'extérieur.Egress vous permet de contourner les tables IP susmentionnées, soit en fonction des règles Egress, soit pour une plage d'adresses IP.Supposons que nous ayons un programme Java qui exécute une demande GET à httpbin.org/headers.(httpbin.org est juste une ressource pratique pour tester les demandes de service sortantes.)Si vous tapez à l'invite de commandecurl http://httpbin.org/headersnous verrons ce qui suit:Ou vous pouvez ouvrir la même adresse dans un navigateur:Comme vous pouvez le voir, le service qui s'y trouve renvoie simplement les en-têtes qui lui sont passés.Substitution d'importation au front
Maintenant, prenons le code Java de ce service externe à notre système et exécutons-le à la maison, où, rappelez-vous, Istio se trouve. (Vous pouvez le faire vous-même en vous référant à notre tutoriel Istio .) Après avoir assemblé l'image correspondante et l'avoir exécutée sur la plate-forme OpenShift, nous appellerons ce service avec une commande curl egresshttpbin-istioegress.$(minishift ip).nip.io, après quoi nous verrons à l'écran ceci:Oups, que s'est-il passé? Pourtant, cela a juste fonctionné. Que signifie Not Found? Nous l'avons juste fait pour lui curl.Étendez les tables IP à l'ensemble d'Internet
Blâmez (ou remerciez) Istio pour cela. Après tout, Istio est juste des conteneurs side-car qui sont responsables de la détection et du routage (enfin, pour beaucoup d'autres choses dont nous avons parlé plus tôt). Pour cette raison, les tables IP ne savent que ce qui se trouve à l'intérieur de votre système de cluster. Et httpbin.org est situé à l'extérieur et donc indisponible. Et ici, Istio Egress vient à la rescousse - sans la moindre modification de votre code source.La règle Egress ci-dessous oblige Istio à rechercher (si nécessaire, puis sur tout Internet) le service souhaité, dans ce cas, httpbin.org. Comme vous pouvez le voir dans 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, réexécutez la commande curl - et vérifiez que tout fonctionne:Nous pensons ouvertement
Comme vous pouvez le voir, Istio vous permet d'organiser l'interaction avec le monde extérieur. En d'autres termes, vous pouvez toujours créer des services OpenShift et les diriger à travers Kubernetes, en conservant tout dans des modules qui évoluent de haut en bas 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 se faire sans toucher à votre code.Ce fut le dernier message de la série Istio. Restez avec nous - il y a beaucoup de choses intéressantes à venir!