English version available

Cette série d’articles est consacrée à Flagger, un outil qui s’intègre à l’écosystème de la plateforme d’orchestration de container Kubernetes pour faire des déploiements automatisés et sera un pas de plus en direction d’un processus de déploiement continu.

Cet article est le premier de la série et aussi celui qui aborde le moins Flagger… Il vous permettra de prendre en main Kubernetes sur votre environnement local en déployant une application qui sera accessible par l’intermédiaire d’une passerelle Istio.

Docker

Installez Docker en installant l’application Docker Desktop for Mac, vous pouvez vous référer au guide officiel d’installation. Pour les utilisateurs de Windows, l’application équivalente « Docker for Windows » existe.

Pour la suite, nous allons également utiliser Docker for Mac pour mettre en place le cluster Kubernetes en local. Notez que ce tutoriel a été testé avec Docker for Mac 2.4.0.0 qui embarque un cluster Kubernetes en version 1.18.8.

Si vous utilisez une version différente, la technologie évolue rapidement et je ne peux donc pas garantir que les commandes utilisées dans cette série d’articles fonctionneront sans ajustement.

Mirror HTTP Server

Quelques mots sur l’application Mirror HTTP Server que nous allons utiliser dans cette série d’articles.

MHS est une application JavaScript basée sur Node.js utilisant le framework Express très simple qui permet de personnaliser la réponse HTTP reçue en spécifiant des headers HTTP dans la requête. L’image Docker est disponible publiquement sur le Docker Hub. Vous pouvez consulter le repo Github du projet pour en savoir plus, notez que je n’en suis pas l’auteur.

Cette mini application est exactement ce dont nous avons besoin pour tester les capacités de Flagger pour simuler des réponses 200 OK et des réponses 500 Internal Server Error.

Récupérons l’image Docker:

Lançons un container qui l’utilise:

Puis testons son bon fonctionnement:

Vous devriez recevoir une réponse HTTP 200 OK:

Alors que:

retournera une réponse HTTP 500:

Pour plus de simplicité, nous utilisons la commande curl, mais vous pouvez utiliser votre outil préféré comme Postman.

Kubernetes

Maintenant que vous avez installé Docker for Mac, avoir un cluster Kubernetes qui tourne en local ne sera qu’une simple formalité. Il vous suffit de cocher une case!

Activer Kubernetes avec Docker for Mac

Si la lumière est verte, alors votre cluster Kubernetes a démarré avec succès. Attention, cela prend pas mal de ressources donc ne vous affolez pas si le ventilateur tourne à plein régime et que cela prend un peu de temps pour démarrer…

Kube dashboard

Nous allons installer notre première application dans notre cluster Kubernetes.

Kubernetes via Docker ne fournit pas Kube dashboard par défaut, vous devez l’installer vous-même. Ce tableau de bord est très pratique et donne une vision graphique de ce que se passe dans votre cluster et vous évitera d’avoir à saisir des commandes kubectl.

Le tableau de bord est protégé, mais vous pouvez utiliser l’utilisateur par défaut pour y accéder. Générez un token pour cet utilisateur:

Copiez le token.

Vous devrez réutiliser cette commande et / ou le token copié si votre session a expiré, cela se produit lorsque vous n’interagissez pas avec le tableau de bord pendant un petit moment.

Enfin, créer un proxy pour accéder au tableau de bord à partir du navigateur (cette commande devra s’exécuter indéfiniment):

Si vous accédez à http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login et utilisez le token que vous avez copié pour vous authentifier, vous devriez voir cet écran.

Tableau de bord Kubernetes

Helm

Nous utilisons Homebrew pour l’installation de Helm. Homebrew est un gestionnaire de paquets très pratique disponible pour Mac.

Nous allons utiliser Helm pour installer Istio et l’application MHS dans notre cluster. Helm est un peu l’équivalent de Homebrew, mais pour Kubernetes. Nous utilisons la version 3. Helm vous évitera d’avoir à saisir de nombreuses commandes kubectl apply.

Installons Helm 3 avec:

Pour vérifier que Helm a bien été installé:

Vous devriez avoir en sortie (notez que Helm 3.3.4 est la dernière version au moment de la rédaction):

Istio & Prometheus

Maintenant, installons le Service Mesh Istio. Pour des explications et les avantages à utiliser un Service Mesh, je vous invite à lire la documentation officielle.

Tout d’abord, vous devez augmenter les limites de mémoire de votre Kubernetes via Docker, sinon vous allez rencontrer des problèmes de déploiement. Vos ventilateurs vont s’en remettre, ne vous inquiétez pas…

Voici ma configuration:

Configuration Kubernetes de Docker for Mac pour Istio

J’ai suivi les recommandations Docker Desktop pour Istio.

Passons à l’installation d’Istio 1.7.3 (la dernière version au moment de la rédaction). Tout d’abord, téléchargez les sources:

Ajoutez le client istioctl à votre path:

Installez Istio avec le client fourni, on utilise le profil de démo:

Après quelques minutes, vous devriez avoir un message confirmant qu’Istio a bien été installé. Et voilà!

Pour installer la dernière version d’Istio, vous pouvez simplement remplacer la première ligne par curl -L https://istio.io/downloadIstio | sh -.

Ajoutez Prometheus car c’est un prérequis pour Flagger:

A partir du tableau de bord Kube, vérifiez qu’un nouveau namespace a été créé istio-system et qu’il contient les outils Istio dont Prometheus.

Istio est déployé dans votre cluster

Pourquoi Prometheus est-il important? Car c’est un composant indispensable pour Flagger qui fournira les métriques pour montrer si la nouvelle version de votre application est en bonne santé ou non et ainsi la promouvoir ou au contraire faire un rollback. Je reviendrais en détail sur tout cela dans le prochain article.

Déploiement de Mirror HTTP Server

Avant de déployer MHS, créons un nouveau namespace application, nous ne voulons pas utiliser celui par défaut à la racine du cluster (c’est une bonne pratique). Le nom est un peu trop générique, mais suffisant pour ce tutoriel, en général vous utiliserez le nom de l’équipe ou le nom d’un regroupement de fonctionnalités.

N’oublions pas d’activer Istio sur ce nouveau namespace:

Pour déployer MHS, j’ai créé un Helm chart.

Ce chart a été créé avec la commande helm create mhs-chart, que j’ai ensuite adapté pour récupérer la dernière image de MHS. J’ai également ajouté un fichier gateway.yaml pour la configuration de la passerelle Istio afin que l’application soit accessible en dehors du cluster.

Clonez le repo contenant le chart:

Et installez MHS:

Après quelques instants, si vous regardez le tableau de bord, vous devriez voir 1 replica de MHS dans le namespace application.

MHS est déployé dans votre cluster

Vous avez maintenant 1 pod de MHS en cours d’exécution dans votre cluster Kubernetes. Le pod est exposé au monde extérieur via une passerelle Istio.

Pour tester, utilisons les commandes similaires précédemment utilisées contre le container docker:

Vous devriez recevoir une réponse HTTP 200 OK qui a été manipulé par le composant Envoy, le proxy utilisé par Istio:

Et:

devrait retourner une réponse HTTP 500:

Félicitations, vous êtes arrivé à la fin de ce premier tutoriel!

Pour information, vous pouvez également accéder à MHS avec votre navigateur préféré si vous exécutez d’abord une commande proxy pour exposer le pod:

export POD_NAME=$(kubectl get pods --namespace application -l "app.kubernetes.io/name=mhs,app.kubernetes.io/instance=mhs" -o jsonpath="{.items[0].metadata.name}")

kubectl port-forward --namespace application $POD_NAME 8080:80

Ensuite, accédez à http://localhost:8080/.

Vous devriez voir une… page blanche. C’est normal, MHS ne renvoie aucun body dans la réponse, il n’y a aucune sortie HTML!

Nettoyage des ressources

Vous pouvez supprimer l’application MHS et son namespace.

Nous ne supprimons pas Istio / Prometheus car nous en aurons besoin dans le prochain article, mais si vous souhaitez libérer des ressources, vous pouvez utiliser ces commandes:

Et après?

Le prochain article détaillera l’installation de Flagger et son utilisation via des déployments de type « canary release » de différentes versions de MHS. Stay tuned! En attendant, vous pouvez arrêter le cluster Kubernetes en décochant la case et redémarrant Docker Desktop. Votre ordinateur peut prendre une pause méritée.

 English version available

Cet article résume le travail que nous avons accompli au sein de mon équipe pour migrer nos micro-services de Java 8 à Java 11 pour le site Hotels.com.

En résumé, pour chacun de nos services, nous avons suivi les étapes suivantes:

• Compiler le code avec Java 11
• Démarrer le service (compatible Java 11) sur Java 8
• Démarrer le service sur Java 11

En réalité, nous avons eu quelques étapes supplémentaires. Lorsque nous avons commencé la migration, Java 11 n’était pas encore disponible, nous ne pouvions utiliser que Java 10.
L’hypothèse était la suivante: si le code compile avec Java 10, la migration vers Java 11 ne demandera pas beaucoup de travail, car le changement le plus important à propos de la modularité a été introduit avec Java 9 et le projet Jigsaw. Heureusement, ce fut le cas!

Mise à jour du sabre laser Star Wars...

1. Compiler le code avec Java 11

C’est la partie qui a pris le plus de temps. En effet, nous avons dû monter en version la plupart des frameworks et des outils que nous utilisions. En particulier, nous avons dû gérer la migration de Spring Boot 1 à 2 et de Spring 4 à 5. S’agissant de versions majeures, nous avons dû prendre en compte quelques modifications importantes.

Spring Boot

Pour Spring Boot 2, les guides de migration officiels de Spring Boot 2.0 et Spring Boot 2.1 sont bien écrits et détaillés.

• Le chargement des profils a évolué
• Le relaxed binding des propriétés est un peu moins relaxed
• Certaines propriétés ont été renommées et d’autres sont indisponibles (par exemple, la propriété security.basic.enabled doit être remplacée par un WebSecurityConfigurerAdapter)
• Certains endpoints ont été renommés (par exemple, actuator healthchecks)
• L’overriding de bean est maintenant désactivé par défaut. Comme nous l’utilisions dans nos tests d’intégration, nous avons dû le réactiver avec la nouvelle propriété spring.main.allow-bean-definition-overriding.

Spring

La migration vers Spring 5 était plutôt simple du point de vue du code avec quelques changements mineurs. La partie la plus compliquée était liée au fait que le projet était legacy et que nous devions gérer une configuration Spring en XML complexe et la migration vers Dropwizard Metrics 4.

Divers

Il peut arriver que des frameworks ne soient toujours pas compatibles avec Java 9+ car ils ne sont pas activement maintenus par la communauté. Dans notre cas, nous avons dû trouver une solution de contournement pour Cassandra Unit. Nous ne voulions pas investir de temps dans un changement de framework DB de test car nous prévoyons de passer à DynamoDB.

Nous avons également dû faire face au « Maven dependency hell » car certaines dépendances obligatoires tiraient d’anciennes dépendances non compatibles avec Java 9+. Dans la plupart des cas, l’ajout d’exclusions dans le POM a résolu le problème.

Environnement local

En local, nous avons ajouté quelques alias à notre fichier de profil bash pour passer d’une version de Java à une autre.

alias setjava8="export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/"
alias setjava10="export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home/"
alias setjava11="export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home/"

Sous IntelliJ, le changement de version de Java peut être effectué à partir des paramètres du projet (la liste déroulante « Project SDK »).

Environnement IC

Du côté de l’Intégration Continue (nous utilisons Bamboo), nous avons mis à jour l’agent pour qu’il utilise Java 11.
Nous avons constaté qu’il n’était pas possible d’avoir des versions différentes de l’agent pour les plans de branche et le plan principal (master), car la configuration du plan est globale. Cela signifie que la mise à jour de l’agent vers Java 11 cassera le plan principal si quelqu’un d’autre commite sur master (par exemple, une nouvelle fonctionnalité ou un correctif de bogue totalement indépendant de la migration vers Java 11).
Pour atténuer ce problème et éviter un build rouge, il était important pour nous de nous assurer que le projet était compilable avec Java 11 et que tous les tests passaient localement avant d’effectuer la mise à jour de l’agent, ceci afin de merger rapidement la branche concernant la migration Java. Une autre option consisterait à remettre temporairement l’agent à Java 8 une fois que le plan de branche est vert sur Java 11 sans oublier de le rebasculer sur Java 11 juste avant le merge.

2. Démarrer le service (compatible Java 11) sur Java 8

Une fois que tout a été corrigé, mergé et que le build principal est au vert, nous nous sommes assuré que la version compatible Java 11 fonctionnait correctement dans nos environnements de test. En gros, nous nous assurions que rien ne soit cassé… Nous avions des tests unitaires, d’intégration et des tests end-to-end, autant dire que notre niveau de confiance était assez élevé. Comme on est jamais trop prudent, nous avons effectué des tests exploratoires manuels sur l’API, avec quelques requêtes exotiques et autres cas en marge afin de nous assurer que le service se comportait correctement. Nous avons également consulté les log et les tableaux de bord Grafana pour s’assurer que tout fonctionnait bien.

La prochaine étape consistait à pousser cette nouvelle version en production. Le service fonctionnait toujours avec Java 8, même si le code était compatible (et compilé) avec Java 11, nous ne voulions pas introduire trop de changements en même temps, nous n’aimons pas les versions risquées après tout. Nous avons traité cette version avec un soin supplémentaire en raison de la refactorisation importante et des multiples montées en version. Après avoir examiné les tableaux de bord Grafana pendant quelques jours, en comparant les métriques avant et après la migration, nous avons constaté que tout s’était bien passé.

3. Démarrer le service sur Java 11

Le but était d’exécuter le service sur Java 11. En théorie, ce serait aussi simple que de mettre à jour le fichier Docker pour utiliser l’image Java 11 et pousser l’artifact en production. Cependant, dans la pratique, ce n’était pas si simple…

Tout d’abord, nous avons dû mettre à jour certains arguments de la JVM (le paramètre -d64 est obsolète et empêchera le service de démarrer, nous avons également dû mettre à jour l’argument concernant les logs du Garbage Collector).

Ensuite, nous avons rapidement réalisé que les logs s’étaient volatilisées dans Splunk pour notre environnement de production interne. En fait, elles apparaissaient dans le future alors qu’il n’y avait aucun soucis avec la production sur AWS. Nous avons dû mettre à jour la configuration logback pour corriger cette « distorsion temporelle » ;) en mettant à jour le date pattern de %d{ISO8601} à %d{yyyy-MM-dd'T'HH:mm:ss.SSSZ,UTC}.

Une autre erreur étrange VerifyError: Bad type on operand stack a fait son apparition pendant le déploiement en production. AppDynamics empêchait le démarrage de certaines instances en raison d’une manipulation exotique du bytecode. Pour des raisons encore inconnues, le déploiement échouait aléatoirement sur une des instances après avoir réussi sur plusieurs autres! Nous avons dû désactiver AppDynamics, ce qui nous convenait bien, car nous n’utilisons pas cet outil dans notre équipe.

Après la migration vers Java 11, nous avons également dû mettre à jour certains de nos tableaux de bord Grafana afin de refléter l’utilisation d’un nouveau Garbage Collector – G1.

Conclusion

Aujourd’hui, 3 services fournissant les notifications utilisateur utilisant Spring Boot 2 et 1 service fournissant l’en-tête et le pied de page du site utilisant Spring 5 fonctionnent sur Java 11, cela fait maintenant plusieurs semaines. Ils utilisent le Garbage Collector par défaut G1 et nous n’avons rencontré aucun comportement étrange lié à la mémoire ou à tout autre problème de performance. Aussi, nous n’avons constaté aucune amélioration de nos temps de réponse. Mais maintenant nous utilisons une version Java LTS (support à long terme), la migration a été un succès.

Et après? Java 12 sera publié en mars 2019. A ce jour, nous ne savons toujours pas si nous utiliserons cette version ou attendrons le prochain Java LTS. Cela dépendra probablement des fonctionnalités incluses.