Les applications « cloud natives » ou simplement « cloud » sont créées spécifiquement pour fonctionner dans les infrastructures cloud. Ils sont généralement construits comme un ensemble de microservices faiblement couplés, regroupés dans des conteneurs, qui sont à leur tour gérés par une plateforme cloud. Ces applications sont préparées par défaut aux 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, ce sont les ensembles de restrictions (contrats) que la plateforme cloud impose aux applications conteneurisées afin de pouvoir les gérer automatiquement.
Même si elles sont pleinement conscientes de la nécessité et de l'importance de migrer vers des applications basées sur le cloud, de nombreuses organisations ne savent toujours pas par où commencer. Dans cet article, nous examinerons un certain nombre de principes qui, s'ils sont suivis lors du développement d'applications conteneurisées, vous permettront de réaliser le potentiel des plates-formes cloud et d'obtenir un fonctionnement et une mise à l'échelle fiables des applications même en cas de pannes graves de l'infrastructure informatique. niveau. Le but ultime des principes décrits ici est d'apprendre à créer des applications pouvant être automatiquement gérées par des plateformes cloud telles que Kubernetes.
Principes de conception de logiciels
Dans le monde de la programmation, les principes font référence à des règles assez générales qui doivent être suivies 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 outils pour les atteindre étant généralement des modèles et des pratiques. Il existe également un certain nombre de principes fondamentaux pour créer des logiciels de haute qualité, dont découlent tous les autres. Voici quelques exemples de principes fondamentaux :
- (Restez simple, stupide) – ne compliquez pas les choses ;
- (Ne vous répétez pas) - ne vous répétez pas ;
- (Vous n'en aurez pas besoin) - ne créez pas quelque chose qui n'est pas immédiatement nécessaire ;
- Séparation des préoccupations – partage des responsabilités.
Comme vous pouvez le constater, ces principes ne fixent pas de règles précises, mais appartiennent à la catégorie des considérations dites de bon sens fondées sur l'expérience pratique, partagées par de nombreux développeurs et auxquelles ils font régulièrement référence.
De plus, il y a – Un ensemble des cinq premiers principes de programmation et de conception orientées objet, formulés par Robert Martin. SOLID comprend des principes généraux, ouverts et complémentaires qui, lorsqu'ils sont appliqués ensemble, contribuent à créer de meilleurs systèmes logiciels et à mieux les maintenir sur le long terme.
Les principes SOLID appartiennent au domaine de la POO et sont formulés dans le langage de concepts et concepts tels que les classes, les interfaces et l'héritage. Par analogie, les principes de développement peuvent également être formulés pour les applications cloud, 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 plateformes cloud comme Kubernetes.
Conteneurs cloud natifs : l'approche Red Hat
Aujourd’hui, presque toutes les applications peuvent être regroupées relativement facilement 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.
La base des idées décrites ci-dessous était la méthodologie et de nombreux autres travaux sur divers aspects de la création d'applications Web, de la gestion du code source à la mise à l'échelle des modèles. Les principes décrits s'appliquent uniquement au développement d'applications conteneurisées construites sur des 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 du conteneur cible est la plate-forme d'orchestration de conteneurs. L'objectif des principes proposés est de créer des conteneurs pour lesquels les tâches de planification, de mise à l'échelle et de surveillance peuvent être automatisées sur la plupart des plateformes d'orchestration. Les principes ne sont pas présentés dans un ordre particulier.
Principe de préoccupation unique (SCP)
Ce principe est à bien des égards similaire au principe de responsabilité unique. ), qui fait partie de l'ensemble SOLID et stipule que chaque objet doit avoir une responsabilité et que cette responsabilité doit être complètement encapsulée dans une classe. Le but du SRP est que chaque responsabilité est une raison de changement, et qu’une classe doit avoir une et une seule raison de changer.
Dans SCP, nous utilisons le mot « préoccupation » au lieu du mot « responsabilité » pour indiquer le niveau d'abstraction plus élevé et l'objectif plus large d'un conteneur par rapport à une classe POO. Et si l’objectif du SRP est de n’avoir qu’une seule raison de changer, alors derrière le SCP se cache le désir d’étendre la capacité de réutiliser et de remplacer les conteneurs. En suivant le SRP et en créant un conteneur qui résout un problème unique et le fait de manière fonctionnellement complète, vous augmentez les chances de réutiliser cette image de conteneur dans différents contextes d'application.
Le principe SCP stipule que chaque conteneur doit résoudre un seul problème et le faire correctement. De plus, SCP dans le monde des conteneurs est plus facile à réaliser que SRP dans le monde POO, car les conteneurs exécutent 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 alors être divisé en conteneurs à tâche unique et combinés au sein d'un seul pod (une unité de déploiement de plate-forme de conteneurs) à l'aide de modèles de conteneur side-car et 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 qui possède des fonctionnalités étendues ou qui évolue mieux.
Principe de haute observabilité (HOP)
Lorsque les conteneurs sont utilisés comme moyen unifié pour empaqueter et exécuter des applications, les applications elles-mêmes sont traitées comme une boîte noire. Toutefois, s’il s’agit de conteneurs cloud, ils doivent alors fournir des API spéciales au runtime pour surveiller l’état des conteneurs et, si nécessaire, prendre les mesures appropriées. 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, détériorera la stabilité et la convivialité 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é : tests d'activité et tests de préparation. Si une application prétend faire plus, elle doit fournir d'autres moyens de surveiller son état. Par exemple, enregistrer des événements importants via STDERR et STDOUT pour l'agrégation de journaux à l'aide de Fluentd, Logstash et d'autres outils similaires. Ainsi que l'intégration avec des bibliothèques de traçage et de collecte de métriques, telles que OpenTracing, Prometheus, etc.
De manière générale, l’application peut toujours être traitée comme une boîte noire, mais elle doit être dotée de toutes les API dont la plateforme a besoin pour la surveiller et la gérer de la meilleure façon possible.
Principe de conformité du cycle de vie (LCP)
LCP est l’antithèse de HOP. Alors que HOP indique que le conteneur doit exposer les API de lecture à la plateforme, LCP exige que l'application soit capable d'accepter les informations de la plateforme. De plus, le conteneur doit non seulement recevoir les événements, mais aussi s’y adapter, c’est-à-dire y réagir. D’où le nom du principe, qui peut être considéré comme une condition nécessaire pour doter la plateforme d’API d’écriture.
Les plateformes disposent de différents types d'événements pour aider à gérer le cycle de vie d'un conteneur. Mais c’est à l’application elle-même de décider lesquels percevoir et comment réagir.
Il est clair que certains événements sont plus importants que d’autres. Par exemple, si une application ne tolère pas bien les crashs, elle doit accepter les messages signal : terminate (SIGTERM) et lancer sa routine de terminaison le plus rapidement possible pour capter 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 d'une application. Par exemple, après le lancement d’une application, celle-ci peut nécessiter un certain temps de préchauffage avant de pouvoir répondre aux requêtes. Ou bien l'application doit libérer des ressources d'une manière particulière lors de son arrêt.
Le principe d'immuabilité de l'image (IIP)
Il est généralement admis que les applications conteneurisées doivent rester inchangées après avoir été créées, même si elles sont exécutées dans des environnements différents. Cela nécessite d'externaliser le stockage des données au moment de l'exécution (en d'autres termes, d'utiliser des outils externes pour cela) et de s'appuyer sur des configurations externes spécifiques à l'exécution, plutôt que de modifier ou de créer des conteneurs uniques pour chaque environnement. Après toute modification apportée à l'application, l'image du conteneur doit être reconstruite et déployée dans tous les environnements utilisés. D'ailleurs, lors de la gestion des systèmes informatiques, un principe similaire est utilisé, connu sous le nom de principe d'immuabilité des serveurs et de l'infrastructure.
L'objectif d'IIP est d'empêcher la création d'images de conteneur distinctes pour différents environnements d'exécution et d'utiliser la même image partout avec la configuration spécifique à l'environnement appropriée. Suivre 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 caractère éphémère : une instance d'un conteneur est facile à créer et à détruire, elle peut donc être facilement remplacée par une autre instance à tout moment. Il peut y avoir de nombreuses raisons pour un tel remplacement : échec d'un test de maintenance, mise à l'échelle de l'application, transfert vers un autre hôte, épuisement des ressources de la plateforme ou autres situations.
En conséquence, les applications conteneurisées doivent maintenir leur état à l'aide de moyens externes ou utiliser des schémas distribués internes avec redondance pour cela. De plus, l'application doit démarrer et s'arrêter rapidement, et se préparer à une panne matérielle soudaine et fatale.
Une pratique qui permet de mettre en œuvre ce principe consiste à garder les conteneurs petits. Les environnements cloud peuvent sélectionner automatiquement un hôte sur lequel lancer une instance de conteneur. Ainsi, plus le conteneur est petit, plus il démarrera rapidement : il sera simplement copié plus rapidement sur l'hôte cible via le réseau.
Principe d'autoconfinement (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 en partant du principe que le système ne dispose que d'un noyau Linux pur, donc toutes les bibliothèques supplémentaires nécessaires doivent être placées dans le conteneur lui-même. Il doit également contenir des éléments tels que le moteur d'exécution du langage de programmation correspondant, la plate-forme d'application (si nécessaire) et d'autres dépendances qui seront requises lors de l'exécution de l'application conteneur.
Des exceptions sont faites pour les configurations qui varient d'un environnement à l'autre et doivent être fournies au moment de l'exécution, par exemple via un ConfigMap Kubernetes.
Une application peut inclure plusieurs composants conteneurisés, par exemple un conteneur SGBD distinct au sein d'une application Web conteneurisée. Selon le principe S-CP, ces conteneurs ne doivent pas être combinés en un seul, mais doivent être conçus de manière à ce que le conteneur SGBD contienne tout le nécessaire au fonctionnement de la base de données et que le conteneur de l'application Web contienne tout le nécessaire au fonctionnement du Web. application, le même serveur Web. Par conséquent, au moment de l'exécution, le conteneur de l'application Web dépendra du conteneur SGBD et y accédera selon les besoins.
Principe de confinement d'exécution (RCP)
Le principe S-CP définit comment le conteneur doit être construit et ce que doit contenir l'image binaire. Mais un conteneur n’est pas simplement une « boîte noire » qui n’a qu’une seule caractéristique : la taille du fichier. Lors de l'exécution, le conteneur prend d'autres dimensions : la quantité de mémoire utilisée, le temps CPU 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 vers la plateforme. Grâce aux profils de ressources de chaque conteneur (quantité de ressources CPU, mémoire, réseau et disque dont elle a besoin), la plate-forme peut effectuer de manière optimale la planification et la mise à l'échelle automatique, gérer la capacité informatique et maintenir 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 ses propres limites. Sinon, en cas de pénurie de ressources, la plate-forme est plus susceptible de l'inclure dans la liste des applications qui doivent être fermées ou migrées.
Lorsque nous parlons de donner la priorité au cloud, nous parlons de notre façon de travailler.
Ci-dessus, nous avons formulé un certain nombre de principes généraux qui constituent la base méthodologique pour la création d'applications conteneurisées 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 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 appliquées) selon la situation :
- Essayez de réduire la taille des images : supprimez les fichiers temporaires et n'installez pas de packages inutiles - plus la taille du conteneur est petite, plus il est assemblé et copié rapidement sur l'hôte cible via le réseau.
- Concentrez-vous sur les ID utilisateur arbitraires : n'utilisez pas la commande sudo ou tout autre ID utilisateur spécial pour lancer vos conteneurs.
- Marquer les ports importants : vous pouvez définir les numéros de port au moment de l'exécution, mais il est préférable de les spécifier à l'aide de la commande EXPOSE - cela permettra à d'autres personnes et programmes d'utiliser plus facilement vos images.
- Stocker les données persistantes sur des volumes : les données qui doivent rester après la destruction du conteneur doivent être écrites sur des volumes.
- Écrivez des métadonnées d'image : les balises, les étiquettes et les annotations facilitent l'utilisation des images - d'autres développeurs vous remercieront.
- Synchroniser l'hôte et les images : certaines applications conteneurisées nécessitent que le conteneur se synchronise avec l'hôte sur certains attributs, tels que l'heure ou l'ID de la machine.
- En conclusion, nous partageons des modèles et des bonnes pratiques qui vous aideront à mettre en œuvre plus efficacement les principes énumérés ci-dessus :
11 juin à 11.00hXNUMX
Ce que vous apprendrez :
- CoreOS immuable de Red Hat Enterprise Linux
- Maillage de services OpenShift
- Cadre opérateur
- Cadre natif
Source: habr.com