Déploiement d'applications avec Kubernetes

a. Exploiter la plateforme Kubernetes mise en place

Les précédents chapitres se sont attachés à montrer les différentes manières de monter un cluster Kubernetes, ainsi qu’à expliquer dans les détails les opérations de maintenance et d’exploitation de ce cluster une fois mis en place. Jusqu’à maintenant, donc, les opérations montrées relevaient plutôt de profils système ou opérationnels, dont le rôle est d’assurer la disponibilité de l’infrastructure. 

Dans le présent chapitre, nous allons basculer dans un autre rôle, qui correspond à un profil d’exploitant du logiciel supporté par la plateforme, et donc plutôt consommateur de celle-ci. En résumé, après être rentré dans le détail de comment Kubernetes fonctionne, nous allons nous pencher sur ce que nous pouvons en faire. L’usage principal de ce type de plateforme étant de déployer des applications pouvant passer à l’échelle, nous utiliserons une application exemple que nous installerons sur un cluster Kubernetes et que nous manipulerons comme le ferait l’exploitant d’une structure similaire en production.

b. Remarque sur l’approche DevOps

Dans son expression-même, "DevOps" peut faire penser que le principe associé est qu’une même personne possède les deux rôles de développeur et d’opérationnel, ou à l’inverse qu’il convient de bien séparer ces deux rôles. En fait, le principe du DevOps est de faire en sorte d’éviter les barrières entre les personnes en charge de l’infrastructure et celles en charge des logiciels portés par cette dernière.

Traditionnellement, les approches sont en effet opposées car les enjeux sont très différents : pour l’opérationnel en charge de la plateforme, l’enjeu principal est que celle-ci fonctionne en continu, ce qui a pour conséquence naturelle une certaine aversion au changement. Après tout, un des commandements principaux dans l’informatique est de ne pas toucher à un système qui fonctionne. Tout changement est potentiellement vecteur d’un nouveau bug, d’un problème dans la procédure de mise à jour et n’importe quel administrateur système a donc comme réflexe de réduire au maximum ces interventions.

À l’inverse, les développeurs et les profils qui commanditent ces changements, que ce soient des Product Owners sur un produit ou le client/utilisateur en direct sur un projet, ont plutôt intérêt à ce que les fonctionnalités sortent le plus vite possible, pour apporter le maximum de valeur métier au logiciel. À l’inverse de l’administrateur du système, ils souhaitent donc généralement accélérer le rythme du changement. Cette différence dans les enjeux a longtemps été traitée par un rapport de force et une opposition entre les deux approches, les seconds obtenant bon gré mal gré des premiers des mises en production tandis que ceux-ci invoquaient toutes les raisons, bonnes ou mauvaises, pour ne pas les réaliser.

Comme le périmètre de recoupement entre les deux responsabilités est traditionnellement assez large, les difficultés étaient plus étendues. Par exemple, un développeur pouvait avoir besoin d’un OS particulier pour son application, alors que l’administrateur souhaitait ne plus le supporter. Dans certains cas, un administrateur pouvait décider de blocages de sécurité trop contraignants pour un applicatif. Bref, le champ d’interaction était très large entre les deux rôles, car il couvrait toutes les technologies de support de déploiement, de la machine physique jusqu’au choix de librairies partagées.

Une approche plus évoluée est de s’attaquer au problème lié à l’incertitude sur le changement elle-même....

a. Présentation de l’application

L’application utilisée dans les exemples de manipulation ci-dessous s’appelle Middle Office. Il s’agit, comme son nom l’indique, d’une application s’interfaçant entre un Front Office (qui permet de déposer des demandes, typiquement sur un site web) et un Back Office (l’application côté entreprise qui va permettre de traiter ces demandes). Le Middle Office est en général géré par des gestionnaires qui vont qualifier les demandes et accepter qu’elles entrent dans le périmètre du traitement par l’entreprise sur le Back Office.

Il y a une part de tampon de sécurité dans le rôle du Middle Office, car il sert de sas à faire entrer des informations dans une zone moins fortement sécurisée du périmètre étendu de l’entreprise. Ainsi, c’est typiquement sur un Middle Office qu’on opérera les contrôles antivirus, pour ne pas faire perdre de temps à un usager ou un client lors de son dépôt, mais pour ne pas non plus accepter de faire entrer un document dangereux dans le périmètre interne de l’entreprise.

Le Middle Office est également un moyen de filtrer les demandes d’un point de vue fonctionnel, en faisant en sorte que les gestionnaires du Back Office ne soient pas gênés par des demandes incomplètes, farfelues ou invalides. Le gestionnaire Middle Office sert donc de validateur de premier niveau sur des demandes, en les autorisant à passer ou pas, ou en leur donnant une qualification qui va les orienter vers tel ou tel processus sur le reste du Système d’Information. 

Notre application exemple de Middle Office permettra ainsi à un type d’utilisateur de déposer des demandes, à un autre de faire porter des décisions sur ces demandes et à un troisième de paramétrer les types de demandes ainsi que les décisions possibles sur chaque. Cette application est souhaitée comme la plus générique possible, dans le sens où elle permet de gérer n’importe quel type de demande, avec toutes les données qui y sont associées...