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

Pour cet article, je vais parler de deux solutions d’hébergement, l’une plutôt standard pour un site simple (par exemple en PHP) et l’autre orientée Cloud de type PaaS (Platform as a Service) pour une application plus complexe (par exemple en Java). L’objectif n’est pas de faire une comparaison de toutes les offres existantes du marché, mais de vous présenter deux solutions que j’utilise aujourd’hui et qui comblent mes attentes.

1&1, hébergement standard

Ce blog est hébergé sur 1&1 depuis plusieurs années (3 ans). Au début, j’étais chez Free qui était gratuit, mais la solution était limitée et plutôt lente. L’élément déclencheur fut la suppression pure et simple de mon blog du jour au lendemain par les services de Free pour une raison qui reste encore inconnue. Je me suis alors tourné vers une solution professionnelle plus fiable qui m’a permis de choisir mon propre nom de domaine et donc de m’affranchir du fameux « free.fr ».

La solution 1&1 fonctionne bien et ne coute finalement pas très chère (environ 30 euros par an, autrement dit le prix d’un café par mois). J’avais regardé du côté de la concurrence notamment OVH qui était un poil plus cher, finalement je m’étais tourné vers 1&1 qui faisait une promotion sur la première année. Côté disponibilité, le plugin Jetpack Monitor monitore en permanence CarmaBlog et me prévient lorsque le site est indisponible. Je dois dire que cela arrive de temps en temps (2 à 3 fois par mois) pour des périodes ne dépassant pas les 5 minutes en général. Pour un blog comme le mien, c’est suffisant, je n’ai pas besoin d’avoir un taux de disponibilité frôlant les 100%.

Dans son pack, 1&1 fournit le nom de domaine par défaut que vous avez choisi (donc www.fabianpiau.com pour moi), mais vous avez aussi la possibilité de créer des sous-domaines. J’ai donc pu créer des sous-domaines pour:

• Le formulaire de contact: contact.fabianpiau.com (redirection).
• Le blog lui-même: blog.fabianpiau.com (espace web).
• Et aussi mon CV: cv.fabianpiau.com (espace web).

Au niveau des outils fournis, vous avez accès à:

• Une base de données MySQL. Limitée à 1GO ce qui est largement suffisant, à moins de stocker des fichiers complets. Avec près de 80 articles, j’utilise peut-être 10 MO tout au plus.
• Un espace sur un serveur FTP. Je ne suis pas sûr qu’il y ait de limite de taille, mais je ne stocke ni films ni musiques.
• Un compte email au nom de votre domaine. Je n’utilise pas directement le webmail, j’ai préféré mettre en place une redirection vers mon adresse email perso.

Vous pouvez configurer tous ces services depuis un tableau de bord.

Tableau de Bord 1&1

L’accès à la base de données n’est possible qu’en ligne via l’interface web phpMyAdmin. En toute franchise, WordPress et Matomo s’en sortent très bien tout seuls donc je n’y touche pas. Par contre et heureusement, vous pouvez utiliser un client FTP comme FileZilla pour transférer vos fichiers vers le serveur FTP.

A noter que 1&1 fournit des solutions toutes faites pour vous aider à créer votre site web. Par exemple, il existe un pack dédié pour WordPress, un peu plus cher que le pack Basic standard. 1&1 fournit aussi une solution clé en main pour créer des sites internet 1&1 MyWebsite sans avoir besoin de connaissances techniques.

Dans mon cas, je connais bien les technologies et faire un blog de zéro en installant WordPress était la solution la plus naturelle (et aussi la plus économique!).

Heroku, hébergement Cloud

L’application Updapy est hébergée sur Heroku. J’en suis très satisfait, car ça me coute 0 euro par an (on peut difficilement mieux faire, je pense). J’ai quand même acheté un nom de domaine via 1&1, car l’URL par défaut https://updapy.herokuapp.com/ n’était pas assez sexy à mon goût. L’achat du nom de domaine via 1&1 coûte environ 12 euros par an, 1 euro par mois, je dois pouvoir m’en sortir… Je n’ai pas regardé chez la concurrence, étant déjà client 1&1, c’était la solution la plus simple pour moi.

J’ai choisi le populaire Heroku principalement grâce au nombre d’utilisateurs et la communauté importante. En plus, la documentation est très bien faite. En particulier, ce tutoriel pas à pas pour créer et déployer une application Java m’a bien aidé. J’avais hésité avec CloudBees qui était aussi bien réputé. Finalement, j’ai eu la chance de porter mon choix sur Heroku car CloudBees a décidé de se recentrer sur son activité Jenkins et a abandonné son offre PaaS Cloud il y a quelques jours. Il y a aussi d’autres solutions Cloud comme Clever Cloud (hébergeur Français) ou bien Cloud Foundry pour ne citer que les plus connus. Je ne peux pas les comparer ici, car je me suis arrêté à Heroku, libre à vous d’essayer ces autres plateformes.

Heroku fournit des extensions pour couvrir les besoins qu’une application peut avoir: envoi d’email, de SMS, monitoring, queues JMS, caching, noSQL, la liste est bien trop longue pour tout citer ici. Le principe est toujours le même, quand vous voulez une fonctionnalité, vous ajoutez l’extension à votre application en quelques clics via le tableau de bord ou en ligne de commande. Vous adaptez un peu votre code pour utiliser les nouvelles fonctionnalités (encore une fois, la documentation pour chaque extension est bien faite).

La grande majorité des extensions disponibles suivent le même business plan. Elles sont disponibles dans plusieurs versions:

• Une version de base gratuite avec des limitations. C’est parfait pour des petites applications ou à des fins d’évaluation.
• Des versions avancées avec moins de limitations, mais qui deviennent payantes tous les mois.
• Des versions expertes plus chères. A réserver dans le cas où vous gérez un site à gros trafic.

Au niveau de l’indisponibilité sous Heroku, ça me semble très bon. Je verrais à l’usage, mais l’extension de monitoring que j’utilise a levé une fois une indisponibilité de 3 minutes en 3 mois. Les autres, je ne les comptes pas, c’était de ma faute…

Tableau de Bord Heroku

Comme vous pouvez le constater sur le tableau de bord ci-dessus, je me suis arrangé pour ne prendre que des extensions dans leur version de base avec leurs lots de limitations. Ainsi, je « paye » $0.00 tous les mois, une fortune.

• Le plugin SendGrid de base me permet d’envoyer au maximum 200 emails par jour.
• Le plugin PostgreSQL de base me permet d’avoir une base de données sur une instance partagée d’Amazon, avec des tables pouvant contenir au maximum 10 000 lignes.

Ce sont des exemples de limitations, vous pouvez regarder cette page pour connaitre les limites principales. Pour une petite application comme la mienne, c’est suffisant, mais dès que votre application grossit et que vous pouvez en faire un business, il est évident qu’il faudra mettre la main à la poche et rémunérer l’équipe Heroku. Vous pouvez consulter la liste des extensions sur cette page, il y a en a beaucoup!

Avec Heroku, le Cloud prend tout son sens. Vous ne vous souciez pas de la gestion de l’infrastructure, vous adaptez les ressources en fonction de vos besoins (scalabilité) et le coût par mois se met à jour en fonction (attention, car ça peut monter très vite). Vous pouvez gérer et vous focaliser sur ce qui compte vraiment pour vous: le business et le code de votre application. Quand au déploiement d’une nouvelle version, vous pushez simplement vos modifications dans le repo git fourni par Heroku et l’application est automatiquement déployée en production. C’est plutôt magique et bluffant.

En espérant vous avoir donner quelques pistes, en particulier si vous êtes en réflexion pour lancer votre propre blog ou déployer une application sur le Cloud.