5 principes de bon sens pour créer des applications cloud-native

Les applications « cloud natives » ou simplement « cloud » sont spécifiquement conçues pour fonctionner dans des infrastructures cloud. Elles sont généralement construites comme un ensemble de microservices faiblement couplés, emballés dans des conteneurs, qui sont eux-mêmes gérés par une plateforme cloud. Ces applications sont par défaut prêtes à faire face aux pannes, ce qui signifie qu'elles fonctionnent de manière fiable et évoluent même en cas de défaillances graves au niveau de l'infrastructure. L'inconvénient est un ensemble de contraintes (contrats) que la plateforme cloud impose aux applications conteneurisées pour pouvoir les gérer de manière automatique.

Bien conscient de la nécessité et de l'importance de la transition vers des applications cloud, de nombreuses organisations ne savent toujours pas par où commencer. Dans ce billet, nous examinerons un certain nombre de principes, dont le respect dans le développement d'applications conteneurisées permettra de réaliser le potentiel des plateformes cloud et d'obtenir un fonctionnement fiable et une évolutivité des applications même en cas de défaillances graves au niveau de l'infrastructure informatique. L'objectif final des principes exposés ici est d'apprendre à créer des applications pouvant être gérées automatiquement par des plateformes cloud comme Kubernetes.

Principes de conception logicielle

Dans le monde de la programmation, les principes sont compris comme des règles assez générales à respecter lors de la conception de logiciels. Elles peuvent être appliquées indépendamment du langage de programmation utilisé. Chaque principe a ses propres objectifs, souvent atteints à l'aide de modèles et de bonnes pratiques. Il existe également un ensemble de principes fondamentaux de création de logiciels de qualité, dont tous les autres découlent. Voici quelques exemples de principes fondamentaux :

• KISS (Keep it simple, stupid) – ne pas compliquer les choses ;
• DRY (Don’t repeat yourself) – ne pas se répéter ;
• YAGNI (You aren’t gonna need it) – ne pas créer quelque chose dont on n'a pas un besoin immédiat ;
• SoC (Separation of concerns) – séparer les responsabilités.

Comme on peut le voir, ces principes ne fixent pas de règles spécifiques, mais relèvent plutôt du bon sens basé sur l'expérience pratique, que de nombreux développeurs partagent et auxquels ils se réfèrent régulièrement.
De plus, il existe SOLID – un ensemble des cinq premiers principes de la programmation et de la conception orientées objet, formulés par Robert Martin. SOLID comprend des principes complémentaires et interprétables qui, lorsqu'ils sont appliqués ensemble, aident à créer des systèmes logiciels de meilleure qualité et à les maintenir plus efficacement à long terme.

Les principes SOLID s'appliquent au domaine de la POO et sont formulés à l'aide de concepts tels que classes, interfaces et héritage. Par analogie, des principes de développement peuvent également être formulés pour les applications cloud, où l'élément de base n'est pas une classe, mais un conteneur. En suivant ces principes, on peut créer des applications basées sur des conteneurs qui répondent mieux aux objectifs et exigences des plateformes cloud comme Kubernetes.

Conteneurs orientés cloud : approche Red Hat

Aujourd'hui, il est relativement facile d'emballer pratiquement n'importe quelle application dans des conteneurs. Cependant, pour que les applications s'automatisent et s'orchestrent efficacement au sein d'une plateforme cloud comme Kubernetes, des efforts supplémentaires sont nécessaires.
Les idées présentées ci-dessous sont basées sur la méthodologie L'application en douze facteurs et de nombreux autres travaux sur différents aspects de la création d'applications web, allant de la gestion du code source à des modèles de mise à l'échelle. Les principes décrits ne concernent que le développement d'applications basées sur des conteneurs, construits selon une architecture microservices, et destinées aux plateformes cloud telles que Kubernetes. L'élément de base dans notre discussion est l'image du conteneur, et par environnement d'exécution prévu des conteneurs, nous entendons la plateforme d'orchestration des conteneurs. L'objectif des principes proposés est de créer des conteneurs pour lesquels la plupart des plateformes d'orchestration peuvent automatiser les tâches de planification (scheduling – choix de l'hôte pour lancer une instance de conteneur), de mise à l'échelle et de surveillance. Les principes sont exposés dans un ordre arbitraire.

Principe de la tâche unique (Single Concern Principle, SCP)

Ce principe est en grande partie similaire au principe de la responsabilité unique (Single Responsibility Principle, SRP), qui fait partie du principe SOLID et stipule que chaque objet doit avoir une seule responsabilité, et cette responsabilité doit être entièrement encapsulée dans la classe. L'essence du SRP est que chaque responsabilité est une raison de modification, et la classe ne doit avoir qu'une seule raison de changer.

Dans le SCP, au lieu du mot « responsabilité » (responsibility), nous utilisons le mot « tâche » (concern) pour indiquer un niveau d'abstraction plus élevé et une portée plus large pour le conteneur par rapport à la classe OOP. Et si l'objectif du SRP est d'avoir seulement une raison pour des modifications, le SCP vise à élargir les possibilités de réutilisation et de remplacement des conteneurs. En suivant le SRP et en créant un conteneur qui résout une seule tâche et le fait de manière fonctionnellement complète, vous augmentez les chances de réutiliser ce conteneur dans divers contextes d'application.

Le principe SCP stipule que chaque conteneur doit résoudre une seule tâche et bien la réaliser. De plus, le SCP dans le monde des conteneurs est atteint plus facilement que le SRP dans le monde de l'OOP, car les conteneurs effectuent généralement un seul processus, et la plupart du temps, ce processus résout une seule tâche.

Si un microservice conteneur doit résoudre plusieurs tâches à la fois, il peut être décomposé en conteneurs unidimensionnels et regroupé dans un même pod (unité de déploiement de la plateforme de conteneurisation) à l'aide de modèles sidecar et init-containers. De plus, le SCP facilite le remplacement d'un ancien conteneur (par exemple, un serveur web ou un broker de messages) par un nouveau qui résout la même tâche mais possède des fonctionnalités étendues ou se scale mieux.

Le principe de haute observabilité (High Observability Principle, HOP)

Lors de l'utilisation de conteneurs comme moyen unifié d'empaquetage et de déploiement d'applications, celles-ci sont considérées comme des « boîtes noires ». Cependant, lorsqu'il s'agit de conteneurs cloud, ils doivent fournir des API spécifiques à l'environnement d'exécution pour contrôler la santé des conteneurs et prendre les mesures appropriées si nécessaire. Sans cela, il sera impossible d'uniformiser l'automatisation de la mise à jour des conteneurs et la gestion de leur cycle de vie, ce qui, à son tour, nuira à la résilience et à l'utilisation pratique du système logiciel.

En pratique, une application conteneurisée doit, au minimum, disposer d'une API pour différents types de contrôles de santé : des tests de disponibilité (liveness) et des tests de préparation (readiness). Si l'application prétend offrir davantage, elle doit également fournir d'autres moyens de contrôle de son état. Par exemple, l'enregistrement d'événements importants via STDERR et STDOUT pour l'agrégation des journaux à l'aide d'outils comme Fluentd, Logstash et autres. Ainsi que l'intégration avec des bibliothèques de traçage et de collecte de métriques, telles que OpenTracing, Prometheus, etc.

En général, l'application peut toujours être considérée comme une « boîte noire », mais elle doit être équipée de toutes les API nécessaires à la plateforme pour qu'elle puisse surveiller et gérer l'application de la meilleure manière possible.

Principe de conformité au cycle de vie (Life-cycle Conformance Principle, LCP)

LCP est l'antithèse de HOP. Si HOP stipule que le conteneur doit fournir des API à la plateforme pour la lecture, LCP exige que l'application soit capable de recevoir des informations de la plateforme. De plus, le conteneur doit non seulement recevoir des événements, mais aussi s'adapter, c'est-à-dire réagir à eux. D'où le nom du principe, qui peut être considéré comme une exigence de fournir des API à la plateforme pour l'écriture.

Les plateformes disposent de différents types d'événements qui aident à gérer le cycle de vie du conteneur. Cependant, c'est l'application elle-même qui doit décider lesquels d'entre eux percevoir et comment réagir.

Il est clair que certains événements sont plus importants que d'autres. Par exemple, si une application ne gère pas bien les arrêts inattendus, elle doit pouvoir recevoir des messages signal: terminate (SIGTERM) et initier sa procédure d'arrêt dès que possible, afin de terminer avant de recevoir signal: kill (SIGKILL), qui vient après SIGTERM.

De plus, des événements tels que PostStart et PreStop peuvent être cruciaux pour le cycle de vie de l'application. Par exemple, après le démarrage, une application peut nécessiter un certain temps de "réchauffement" avant de pouvoir répondre aux requêtes. Ou l'application doit de manière particulière libérer des ressources lors de son arrêt.

Principe de non-modification de l'image du conteneur (Image Immutability Principle, IIP)

Il est généralement admis que les applications conteneurisées doivent rester inchangées après la construction, même si elles sont exécutées dans différents environnements. Cela nécessite d'externaliser le stockage des données au moment de l'exécution (autrement dit, d'utiliser des moyens externes pour cela), ainsi que de se fier à des configurations externes adaptées à l'environnement d'exécution spécifique, plutôt que de modifier ou de créer des conteneurs uniques pour chaque environnement. Après toute modification de l'application, l'image du conteneur doit être reconstruite et déployée dans tous les environnements utilisés. D'ailleurs, un principe similaire est utilisé dans la gestion des systèmes informatiques, connu sous le nom de principe de non-modification des serveurs et de l'infrastructure.

L'objectif de l'IIP est d'éviter la création d'images de conteneurs distincts pour différents environnements d'exécution et d'utiliser la même image avec la configuration correspondante pour un environnement spécifique. Suivre ce principe permet de mettre en œuvre des pratiques importantes en termes d'automatisation des systèmes cloud, telles que le retour en arrière (roll-back) et l'application (roll-forward) des mises à jour d'application.

Principe de la généricité des processus (Process Disposability Principle, PDP)

L'une des caractéristiques les plus importantes d'un conteneur est son éphémérité : une instance de conteneur est facilement créée et facilement détruite, ce qui permet de la remplacer à tout moment par une autre instance. Il peut y avoir de nombreuses raisons pour un tel remplacement : échec d'un test de validité, mise à l'échelle de l'application, migration vers un autre hôte, épuisement des ressources de la plateforme ou d'autres situations.

En conséquence, les applications conteneurisées doivent conserver leur état à l'aide de moyens externes, ou utiliser pour cela des schémas distribués internes avec redondance. De plus, l'application doit démarrer rapidement et se terminer rapidement, et doit également être prête à faire face à une défaillance matérielle fatale soudaine.

Une des pratiques qui aide à mettre en œuvre ce principe consiste à créer des conteneurs de petite taille. Les environnements cloud peuvent automatiquement choisir un hôte pour exécuter un exemplaire de conteneur, donc plus la taille du conteneur est petite, plus il démarrera rapidement - il sera simplement copié plus rapidement sur l'hôte cible via le réseau.

Principe d'autosuffisance (Self-containment Principle, S-CP)

Selon ce principe, à l'étape de construction, tous les composants nécessaires sont inclus dans le conteneur. Le conteneur doit être construit en supposant qu'il n'y a qu'un noyau Linux propre dans le système, donc toutes les bibliothèques supplémentaires nécessaires doivent être placées dans le conteneur lui-même. On doit également y placer des éléments tels que l'environnement d'exécution pour le langage de programmation concerné, la plateforme d'application (si nécessaire) et d'autres dépendances requises lors de l'exécution de l'application conteneurisée.

Les exceptions ne sont faites que pour les configurations qui varient d'un environnement à l'autre et doivent être fournies à l'exécution, par exemple, via Kubernetes ConfigMap.

L'application peut inclure plusieurs composants conteneurisés, comme un conteneur de SGBD dans le cadre d'une application web conteneurisée. Selon le principe S-CP, ces conteneurs ne doivent pas être fusionnés en un seul, mais doivent être conçus de manière à ce que le conteneur SGBD contienne tout le nécessaire pour le fonctionnement de la base de données, tandis que le conteneur de l'application web contienne tout le nécessaire pour le fonctionnement de l'application web, y compris le serveur web. En conséquence, lors de l'exécution, le conteneur de l'application web dépendra du conteneur SGBD et s'adressera à lui au besoin.

Principe de confinement à l'exécution (Runtime Confinement Principle, RCP)

Le principe S-CP détermine comment un conteneur doit être assemblé et ce que doit contenir le fichier binaire de l'image. Mais un conteneur n'est pas simplement une "boîte noire" qui n'a qu'une seule caractéristique : la taille du fichier. Pendant l'exécution, le conteneur acquiert d'autres dimensions : la quantité de mémoire utilisée, le temps processeur et d'autres ressources système.

C'est ici que le principe RCP entre en jeu, selon lequel le conteneur doit découpler ses exigences en ressources système et les transmettre à la plateforme. En ayant des profils de ressources pour chaque conteneur (quelles ressources CPU, mémoire, réseau et système de disque sont nécessaires), la plateforme peut optimiser la gestion et l'autoscaling, gérer les capacités informatiques et maintenir les niveaux SLA pour les conteneurs.

Outre la satisfaction des exigences des ressources du conteneur, il est également important que l'application ne dépasse pas les limites qu'elle a elle-même définies. Sinon, en cas de pénurie de ressources, la plateforme aura plus de chances de l'inclure dans la liste des applications à interrompre ou à migrer.

Lorsqu'on parle d'orientation vers le cloud, nous faisons avant tout référence à la manière de travailler.
Nous avons formulé ci-dessus une série de principes généraux qui établissent les bases méthodologiques pour construire des applications conteneurisées de qualité pour des environnements cloud.

Il est à noter qu'en plus de ces principes généraux, vous aurez également besoin de méthodes et techniques avancées pour travailler avec des conteneurs. De plus, nous avons plusieurs recommandations succinctes, qui sont plus spécifiques et doivent être appliquées (ou non) en fonction de la situation :

• Essayez de réduire la taille des images : supprimez les fichiers temporaires et n'installez pas de paquets inutiles – plus la taille du conteneur est réduite, plus il se construit et se copie rapidement sur l'hôte cible via le réseau.
• Concentrez-vous sur des User-ID arbitraires : n'utilisez pas la commande sudo ou des User-ID spéciaux pour exécuter vos conteneurs.
• Étiquetez les ports importants : les numéros de ports peuvent être assignés aussi bien à l'exécution, mais il est préférable de les spécifier à l'aide de la commande EXPOSE – cela facilitera l'utilisation de vos images par d'autres personnes et programmes.
• Stockez des données permanentes sur des volumes : les données qui doivent persister après la destruction d'un conteneur doivent être enregistrées sur des volumes.
• Écrivez des métadonnées d'image : les étiquettes, balises et annotations facilitent l'utilisation des images - les autres développeurs vous en seront reconnaissants.
• Synchronisez l'hôte et les images : certaines applications conteneurisées nécessitent la synchronisation du conteneur avec l'hôte sur certains attributs, comme l'heure ou l'identifiant de machine.
• En conclusion, nous partageons des modèles et des meilleures pratiques qui vous aideront à mettre en œuvre plus efficacement les principes mentionnés ci-dessus :
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

Webinaire sur la nouvelle version de la OpenShift Container Platform - 4
11 juin à 11h00

Ce que vous apprendrez :

• Red Hat Enterprise Linux CoreOS immuable
• OpenShift service mesh
• Cadre Operator
• Cadre Knative

Source : habr.com