Des applications «basées sur le cloud» (natives du cloud) ou simplement «cloud» sont créées spécifiquement pour être utilisées dans les infrastructures cloud. Habituellement, ils sont construits comme un ensemble de microservices à couplage lâche emballés dans des conteneurs, qui, à leur tour, sont gérés par une plateforme cloud. Par défaut, ces applications sont prêtes pour les pannes, ce qui signifie qu'elles fonctionnent de manière fiable et évoluent même en cas de pannes graves au niveau de l'infrastructure. Le revers de la médaille est l'ensemble des restrictions (contrats) que la plate-forme cloud impose aux applications de conteneurs afin de pouvoir les gérer automatiquement.
Conscientes de la nécessité et de l'importance de passer aux applications cloud, de nombreuses entreprises ne savent toujours pas par où commencer. Dans cet article, nous examinerons un certain nombre de principes dont le respect lors du développement des applications de conteneur réalisera le potentiel des plates-formes cloud et réalisera un fonctionnement et une mise à l'échelle fiables des applications, même en cas de graves défaillances au niveau de l'infrastructure informatique. Le but ultime des principes énoncés ici est d'apprendre à créer des applications qui peuvent être gérées automatiquement par des plateformes cloud telles que Kubernetes.
Principes de conception de logiciels
Dans le monde de la programmation, les principes sont compris comme des règles assez générales à respecter lors du développement de logiciels. Ils peuvent être utilisés lorsque vous travaillez avec n'importe quel langage de programmation. Chaque principe a ses propres objectifs, les modèles et les pratiques servent généralement d'instrument pour leur réalisation. Il existe également un certain nombre de principes fondamentaux pour la création de logiciels de haute qualité, dont tous les autres découlent. Voici quelques exemples de principes fondamentaux:
- KISS (Restez simple, stupide) - ne vous compliquez pas;
- SEC (ne vous répétez pas) - ne répétez pas;
- YAGNI (vous n'en aurez pas besoin) - ne créez pas quelque chose dans lequel il n'y a pas de besoin immédiat;
- SoC (Séparation des préoccupations) - pour partager les responsabilités.
Comme vous pouvez le voir, ces principes ne fixent pas de règles spécifiques, mais appartiennent à la catégorie des considérations dites de bon sens basées sur une expérience pratique partagée par de nombreux développeurs et auxquelles ils se réfèrent régulièrement.
En outre, il existe
SOLID - un ensemble des cinq premiers principes de programmation et de conception orientées objet, formulés par Robert Martin. SOLID comprend des principes mutuellement complémentaires qui sont généralisés et ouverts à l'interprétation, qui - lorsqu'ils sont appliqués en combinaison - aident à créer de meilleurs systèmes logiciels et à mieux les soutenir à long terme.
Les principes SOLID s'appliquent à la POO et sont formulés en termes de concepts et de concepts tels que les classes, les interfaces et l'héritage. Par analogie, pour les applications cloud, vous pouvez également formuler les principes de développement, seul l'élément de base ici ne sera pas une classe, mais un conteneur. En suivant ces principes, vous pouvez créer des applications conteneurisées qui répondent mieux aux buts et objectifs des plates-formes cloud comme Kubernetes.
Conteneurs basés sur le cloud: approche Red Hat
Aujourd'hui, presque toutes les applications sont relativement faciles à emballer dans des conteneurs. Mais pour que les applications soient efficacement automatisées et orchestrées au sein d'une plateforme cloud comme Kubernetes, des efforts supplémentaires sont nécessaires.
Les idées présentées ci-dessous étaient basées sur la méthodologie de
l'application à douze facteurs et de nombreux autres travaux sur divers aspects de la création d'applications Web, du contrôle des sources aux modèles à l'échelle. Les principes décrits s'appliquent uniquement au développement d'applications de conteneurs construites sur la base de microservices et conçues pour des plates-formes cloud telles que Kubernetes. L'élément de base de notre discussion est l'image du conteneur, et le runtime cible du conteneur est la plate-forme d'orchestration de conteneur. Le but des principes proposés est de créer des conteneurs pour lesquels, sur la plupart des plateformes d'orchestration, vous pouvez automatiser les tâches de planification (planification - choix d'un hôte pour exécuter l'instance de conteneur), la mise à l'échelle et la surveillance. Les principes sont énoncés dans un ordre aléatoire.
Principe de préoccupation unique (SCP)
Ce principe est à bien des égards similaire au principe de responsabilité unique (
SRP ), qui fait partie de la suite SOLID et stipule que chaque objet doit avoir une responsabilité, et cette responsabilité doit être entièrement encapsulée dans la classe. L'essence du SRP est que chaque devoir est une raison de changement, et une classe doit avoir une et une seule raison de changement.
Dans SCP, au lieu du mot «responsabilité», nous utilisons le mot «préoccupation» pour indiquer un niveau d'abstraction plus élevé et un objectif plus large du conteneur par rapport à la classe OOP. Et si l'objectif de SRP est de n'avoir qu'une seule raison de changer, alors SCP souhaite étendre les possibilités de réutilisation et de remplacement des conteneurs. En suivant SRP et en créant un conteneur qui résout une seule tâche et le fait d'une manière fonctionnelle complète, vous augmentez les chances de réutiliser l'image de ce conteneur dans divers contextes d'application.
Le principe de SCP stipule que chaque conteneur doit résoudre une seule tâche et bien le faire. De plus, SCP dans le monde des conteneurs est réalisé plus facilement que SRP dans le monde de la POO, 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 de conteneur doit résoudre plusieurs problèmes à la fois, il peut être divisé en conteneurs à tâche unique et fusionné en un seul pod (unités de déploiement de plateforme de conteneur) à l'aide de modèles de side-car et de conteneurs d'initialisation. De plus, SCP facilite le remplacement d'un ancien conteneur (tel qu'un serveur Web ou un courtier de messages) par un nouveau qui résout le même problème mais a des fonctionnalités améliorées ou évolue mieux.
Principe de commodité de la surveillance (principe de haute observabilité, HOP)
Lorsque les conteneurs sont utilisés comme un moyen unifié d'emballage et de lancement d'applications, les applications elles-mêmes sont considérées comme une «boîte noire». Cependant, s'il s'agit de conteneurs cloud, ils doivent fournir au runtime des API spéciales pour surveiller la santé des conteneurs et prendre les mesures appropriées si nécessaire. Sans cela, il ne sera pas possible d'unifier l'automatisation de la mise à jour des conteneurs et la gestion de leur cycle de vie, ce qui, à son tour, aggravera la stabilité et la convivialité du système logiciel.
Dans la pratique, une application de conteneur doit, au minimum, avoir une API pour différents types de contrôles d'intégrité: tests de vivacité et tests de préparation. Si la demande prétend être supérieure, elle devrait fournir d'autres moyens de surveiller son état. Par exemple, la journalisation des événements importants via STDERR et STDOUT pour agréger les journaux à l'aide de Fluentd, Logstash et d'autres outils similaires. Ainsi que l'intégration avec les bibliothèques de trace et de collection 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 en même temps, elle doit être équipée de toutes les API dont la plate-forme a besoin pour la surveiller et la gérer au mieux.
Principe de conformité du cycle de vie (LCP)
LCP est l'antithèse de HOP. Si le HOP indique que le conteneur doit fournir à la plate-forme des API pour la lecture, alors LCP requiert que l'application puisse recevoir des informations de la plate-forme. De plus, le conteneur doit non seulement recevoir des événements, mais également s'adapter, en d'autres termes, y répondre. D'où le nom du principe, qui peut être considéré comme une exigence pour fournir à la plateforme des API d'écriture.
Les plates-formes ont différents types d'événements qui aident à gérer le cycle de vie du conteneur. Mais c'est à l'application de décider laquelle percevoir et comment y répondre.
Il est clair que certains événements sont plus importants que d'autres. Par exemple, si l'application ne tolère pas l'arrêt d'urgence, elle doit accepter les messages signal: terminate (SIGTERM) et lancer sa procédure de terminaison dès que possible afin d'attraper le signal: kill (SIGKILL) qui vient après SIGTERM.
De plus, des événements tels que PostStart et PreStop peuvent être importants pour le cycle de vie de l'application. Par exemple, après le lancement de l'application, il peut s'écouler un certain temps avant de répondre aux demandes. Ou l'application doit en quelque sorte libérer des ressources à l'arrêt.
Le principe d'immuabilité de l'image du contenant (Principe d'Immutabilité d'Image, IIP)
Il est généralement admis que les applications conteneurisées doivent rester inchangées après l'assemblage, même si elles s'exécutent dans des environnements différents. Cela implique la nécessité d'externaliser le stockage des données lors de l'exécution (en d'autres termes, d'utiliser des outils externes pour cela), ainsi que de s'appuyer sur des configurations externes configurées pour un environnement d'exécution spécifique, au lieu 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 réassemblée et déployée dans tous les environnements utilisés. Soit dit en passant, lors de la gestion des systèmes informatiques, un principe similaire est utilisé, connu sous le nom de principe d'immuabilité des serveurs et des infrastructures.
Le but de IIP est d'empêcher la création d'images de conteneurs distinctes pour différents environnements d'exécution et d'utiliser la même image partout avec la configuration appropriée pour un environnement spécifique. Le respect de ce principe vous permet de mettre en œuvre des pratiques aussi importantes du point de vue de l'automatisation des systèmes cloud que la restauration et la restauration des mises à jour des applications.
Principe d'élimination des processus (PDP)
L'une des caractéristiques les plus importantes d'un conteneur est son éphéméralité: une instance de conteneur est facilement créée et facilement détruite, de sorte qu'elle peut être facilement remplacée par une autre instance à tout moment. Il peut y avoir plusieurs raisons à un tel remplacement: échec du test d'intégrité, mise à l'échelle de l'application, transfert vers un autre hôte, épuisement des ressources de la plateforme ou autres situations.
Par conséquent, les applications de conteneur doivent conserver leur état en utilisant des moyens externes, ou utiliser des circuits distribués internes avec redondance pour cela. De plus, l'application doit se lancer rapidement et s'arrêter rapidement, et être préparée à une panne matérielle soudaine et fatale.
Une pratique qui aide à mettre en œuvre ce principe est de créer de petits conteneurs. Les environnements cloud peuvent sélectionner automatiquement un hôte pour lancer une instance de conteneur, donc plus le conteneur est petit, plus il démarrera rapidement - il sera simplement copié sur l'hôte cible sur le réseau plus rapidement.
Principe d'auto-confinement (S-CP)
Selon ce principe, au stade de l'assemblage, tous les composants nécessaires sont inclus dans le conteneur. Le conteneur doit être construit dans l'espoir que le système ne dispose que d'un noyau Linux propre, donc toutes les bibliothèques supplémentaires nécessaires doivent être placées dans le conteneur lui-même. Des éléments doivent également s'y trouver, tels que le runtime du langage de programmation correspondant, la plate-forme d'application (si nécessaire) et d'autres dépendances qui seront nécessaires pendant le fonctionnement de l'application conteneur.
Des exceptions sont faites uniquement pour les configurations qui varient d'un environnement à l'autre et doivent être fournies au moment de l'exécution, par exemple via Kubernetes ConfigMap.
Une application peut inclure plusieurs composants conteneurisés, par exemple, un conteneur SGBD distinct dans le cadre d'une application de conteneur Web. Selon le principe S-CP, ces conteneurs ne doivent pas être combinés en un seul, mais conçus de manière à ce que le conteneur SGBD contienne tout ce qui est nécessaire au fonctionnement de la base de données et que le conteneur d'application Web contienne tout le nécessaire au fonctionnement de l'application Web, le même serveur Web. . Par conséquent, au moment de l'exécution, le conteneur d'application Web dépendra du conteneur SGBD et y accédera si nécessaire.
Principe de confinement d'exécution (RCP)
Le principe S-CP définit comment un conteneur doit être assemblé et ce qu'un fichier image binaire doit contenir. Mais un conteneur n'est pas seulement une «boîte noire», qui n'a qu'une seule caractéristique - la taille du fichier. Au moment de 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.
Et ici, le principe RCP est utile, selon lequel le conteneur doit décapiter ses besoins en ressources système et les transférer sur la plateforme. Ayant les profils de ressources de chaque conteneur (combien de ressources CPU, mémoire, réseau et système de disque dont elle a besoin), la plateforme peut effectuer de manière optimale la planification et la mise à l'échelle automatique, gérer les capacités informatiques et prendre en charge les niveaux SLA pour les conteneurs.
En plus de répondre aux besoins en ressources du conteneur, il est également important que l'application ne dépasse pas le cadre désigné par celui-ci. Sinon, en cas de manque de ressources, la plateforme est plus susceptible de l'inclure dans la liste des applications qui doivent être interrompues ou migrées.
Parlant de l'accent mis sur le cloud, nous entendons principalement notre façon de travailler.
Ci-dessus, nous avons formulé un certain nombre de principes généraux qui jettent les bases méthodologiques pour la création d'applications de conteneurs de haute qualité pour les environnements cloud.
Notez qu'en plus de ces principes généraux, vous aurez également besoin de méthodes et de techniques avancées supplémentaires pour travailler avec des conteneurs. De plus, nous avons quelques courtes recommandations plus spécifiques et qui doivent être appliquées (ou non) en fonction de la situation:
Webinaire sur la nouvelle version d'OpenShift Container Platform - 411 juin à 11h00
Ce que vous apprendrez:
- Immuable Red Hat Enterprise Linux CoreOS
- Maillage de service OpenShift
- Cadre opérateur
- Cadre Knative