Composants vs. Services

La construction d'applications à l'aide de composants est une approche souhaitable. Dans le cas des monolithes, cela est généralement réalisé en utilisant des bibliothèques comme composants et en les compilant ou en les liant dans un seul programme ou processus qui y accède à l'aide d'appels de fonction « in-process ». En revanche, les « services » dans une application centrée sur les microservices sont des composants « out-of-process » qui communiquent entre eux à l'aide d'une requête de service web (web service) ou d'un appel de procédure distante (remote procedure call). La Figure 12.8 illustre la manière dont les composants sont accédés dans une architecture monolithique (monolithic architecture) par rapport à une architecture de microservices.

Figure 12.8 Les composants d'une architecture monolithique sont accédés différemment par rapport aux composants d'une architecture de microservices. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Comme indiqué précédemment, les services utilisés par les applications centrées sur les microservices sont déployables indépendamment afin que les modifications apportées à un service n'affectent pas les autres services. Cela suppose que les services sont bien encapsulés et conçus avec des limites de service minimalement cohésives. L'utilisation d'appels de services web et de RPC (remote procedure call) facilite cet objectif. Un service web (web service) est une unité logicielle disponible en tant que ressource sur Internet. Un appel de procédure distante (RPC) (remote procedure call (RPC)) est un protocole de requête-réponse utilisé par un programme pour accéder aux services d'autres programmes sur un réseau. Cependant, cette approche présente des inconvénients. Les RPC sont plus coûteux que les appels in-process, et les API distantes doivent donc être à grain plus grossier (c'est-à-dire que les API à grain grossier exposent plus de méthodes dans leurs interfaces par opposition aux API à grain fin).

Un défi lié à l'utilisation des services est la modification de l'attribution des responsabilités entre les composants. Cela peut être difficile, surtout si le service se compose de plusieurs processus déployés ensemble, tels qu'un processus d'application et un processus de magasin de données qui ne sont utilisés que par ce service. Un autre défi est qu'il peut être difficile de définir correctement les limites de service des composants. En d'autres termes, la difficulté est d'intégrer le logiciel dans un composant (component) qui peut être utilisé comme un service. Les services utilisent des API, donc toute modification de l'API doit être coordonnée avec les autres composants. Les modifications d'API doivent être rétrocompatibles afin que les composants qui n'utilisent pas la dernière version mise à jour de l'API puissent toujours fonctionner. Enfin, les tests sont également plus compliqués.

SOA vs. Microservices

L'architecture de microservices n'est pas le premier style architectural à utiliser des composants autonomes et à implémenter des capacités métier individuelles. Le style architectural orienté services, un style de conception logicielle bien établi, commande la même approche. Une architecture orientée services (SOA) (service-oriented architecture (SOA)) exige que les applications conformes soient structurées comme des services discrets, réutilisables et interopérables qui communiquent via un bus de services d'entreprise (enterprise service bus) (ESB) via des protocoles de message tels que SOAP,1 ActiveMQ,2 ou Apache Thrift.3

Un bus de services d'entreprise (ESB) (enterprise service bus (ESB)) implémente un système de communication de type bus entre les fournisseurs de services et les consommateurs de services qui interagissent. Les services, l'ESB et les protocoles de messagerie constituent collectivement une application SOA. Dans la Figure 12.9, l'architecture présentée à gauche illustre une SOA typique par rapport à l'architecture de microservices typique illustrée à droite. Comme c'est le cas pour les services dans une architecture de microservices, les services SOA peuvent être mis à jour indépendamment. Cependant, l'ESB représente un point de défaillance unique pour l'ensemble du système.

Figure 12.9 Dans une SOA, les services communiquent via un ESB, par rapport à une architecture de microservices où les services communiquent généralement via des protocoles REST. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Contrairement aux services dans une SOA, les microservices communiquent généralement entre eux de manière sans état en utilisant des protocoles REST légers implémentés via HTTP. De plus, les microservices peuvent être implémentés en utilisant différents langages de programmation et cadriciels car ils peuvent communiquer via des API agnostiques au langage de programmation. Les avancées dans les technologies de conteneurisation (containerization) permettent de déployer, de mettre à niveau, de faire évoluer et de redémarrer les microservices indépendamment, en contrôlant mieux leurs cycles de vie. En cas de défaillance d'un microservice, le reste de l'application n'est pas affecté. Ainsi, les applications utilisant des microservices peuvent être plus tolérantes aux pannes car elles ne dépendent pas d'un seul ESB comme c'est le cas pour les applications SOA.

Défis des microservices

Les microservices améliorent la capacité d'une équipe de développement à tirer parti du développement distribué. Le temps de développement peut être réduit car les microservices peuvent être développés simultanément. Cependant, il existe des défis connus liés au passage à une architecture de microservices. En plus de la complexité et de l'efficacité, qui sont deux défis majeurs d'une architecture basée sur les microservices, les huit catégories de défis suivantes ont été identifiées.

Journalisation des microservices

Les microservices sont des systèmes distribués et, par conséquent, la journalisation traditionnelle est inefficace pour déterminer quels microservices ont échoué. À mesure que de plus en plus de microservices sont ajoutés, la complexité de la journalisation des activités des microservices augmente de manière exponentielle et devient plus difficile à gérer. En particulier, l'agrégation de journaux est nécessaire pour suivre les erreurs qui pourraient s'étendre sur plusieurs microservices, comme le montre la Figure 12.10.

Figure 12.10 Une architecture de microservices est configurée pour utiliser l'agrégation de journaux et le traçage distribué, qui sont généralement utilisés dans un système distribué basé sur les microservices. L'agrégation de journaux fait référence au stockage de divers niveaux d'avertissements et d'erreurs pour un ensemble combiné de microservices. Le traçage distribué aide à relier les informations journalisées par plusieurs services afin qu'elles puissent être suivies comme un seul fil d'exécution. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Exemple d'architecture web native

La Figure 12.12 illustre un exemple d'architecture web native, une application infonuagique native (cloud-native application) basée sur le web. Cette application infonuagique native se compose de plusieurs microservices qui sont déployés et gérés sur le nuage. Chaque microservice est autonome et indépendant du langage de programmation et du cadriciel. Les microservices sont conteneurisés et gérés par un orchestrateur de conteneurs (container). Chaque microservice contient son propre magasin de données qui correspond le mieux à ses besoins en données. Certains de ces magasins de données sont des bases de données relationnelles, tandis que d'autres sont des bases de données NoSQL.

Figure 12.12 Une application web native tire parti des fonctionnalités des plateformes infonuagiques modernes.8 (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'un des microservices stocke son état dans un cache Redis distribué. Une passerelle d'API (API gateway) est utilisée pour acheminer le trafic entre les applications clientes et les microservices. Plus important encore, cette application infonuagique native tire pleinement parti des fonctionnalités d'extensibilité et de résilience (resiliency) des plateformes infonuagiques modernes.

Applications basées sur les microservices

Comme indiqué précédemment, les microservices sont basés sur un patron d'architecture logicielle où chaque fonctionnalité d'une application monolithique correspondante est placée dans son propre microservice car elle implémente une capacité métier distincte. Ces microservices sont déployés et exécutés dans des conteneurs qui communiquent via des API d'application, des flux d'événements et des courtiers de messages. Les outils d'ordonnancement et d'orchestration gèrent ces conteneurs car ils aident à coordonner et à planifier les conteneurs utilisés pour implémenter les services d'application s'exécutant sur des ressources informatiques. Les équipes de développement de microservices peuvent rapidement ajouter de nouvelles capacités chaque fois que les besoins de l'entreprise changent.

Les microservices peuvent également être mis à l'échelle, lorsqu'une seule capacité est soumise à une charge trop importante, indépendamment des autres microservices. Cela réduit le temps et les coûts associés à la nécessité de mettre à l'échelle une autre instance de l'application entière. Généralement, la mise à l'échelle est réalisée en conteneurisant les microservices et en gérant les conteneurs à l'aide d'un cadriciel de gestion de conteneurs (par exemple, K8s) fourni par une plateforme infonuagique. Une autre alternative consiste à tirer parti de la fonction en tant que service (Function as a Service) (par exemple, AWS Lambdas ou fonctions Google/Microsoft) dans le cadre des microservices et à s'appuyer sur la ou les plateformes infonuagiques pour gérer l'extensibilité.

Les microservices sont également distribués et faiblement couplés, ce qui les rend plus faciles à itérer. Parce que les microservices sont indépendants et communiquent uniquement via des API, les équipes peuvent soumettre du code pour les microservices via un pipeline DevOps. Une fois testés, les microservices peuvent être déployés automatiquement, ce qui facilite l'itération des équipes aussi rapidement que nécessaire pour apporter de la valeur aux utilisateurs finaux. De plus, ces itérations sont minimales, et s'il y a une instance où un microservice échoue, le reste de l'application reste fonctionnel, ce qui rend les mises à jour moins risquées.

Langages et cadriciels les mieux adaptés aux microservices

Le langage de programmation et le cadriciel sont choisis en fonction de ce qui convient le mieux à la fonctionnalité fournie par le microservice. Les applications infonuagiques natives sont polyglottes, ce qui signifie que les microservices sont indépendants du langage et du cadriciel, ce qui permet de choisir différentes piles technologiques et cadriciels pour différents microservices d'une seule application infonuagique native (cloud-native application).

Cadriciel basé sur les conteneurs

Un conteneur est une unité logicielle standardisée qui isole logiquement une application, lui permettant de s'exécuter indépendamment des ressources physiques. L'empaquetage d'une unité logicielle standardisée qui isole une application, lui permettant de s'exécuter indépendamment des ressources physiques, est la conteneurisation (containerization). Les conteneurs fournissent des environnements cohérents, complets et portables pour l'exécution d'applications partout, y compris tous les fichiers système et les dépendances nécessaires à l'exécution des applications. La conteneurisation facilite la création d'applications infonuagiques natives et maximise les avantages des conteneurs. Les conteneurs empêchent les microservices d'interférer les uns avec les autres. Ils empêchent les applications de consommer toutes les ressources partagées de l'hôte. Ils permettent également plusieurs instances du même microservice.

Les conteneurs améliorent l'efficacité et l'efficience de DevOps grâce à des constructions, des tests et des déploiements rationalisés. Ils fournissent également des environnements de production cohérents, isolés des autres applications et processus. Parce que les conteneurs peuvent s'exécuter de manière cohérente partout, ils facilitent les environnements de calcul hybrides et multinuages. Les conteneurs sont légers car ils sont isolés de la couche du système d'exploitation d'un système informatique. Cela les rend efficaces et peu gourmands en ressources. Les conteneurs sont portables car ils incluent toutes les dépendances et configurations requises, ainsi, eux et le code qu'ils contiennent, peuvent être déplacés entre différents environnements.

La Figure 12.13 montre comment les conteneurs en production peuvent s'exécuter sur n'importe quelle ressource informatique dotée d'une plateforme de conteneurisation. Les conteneurs sont extensibles en raison de leur petite taille, ce qui facilite le démarrage, la mise à l'échelle ou l'arrêt rapide des conteneurs en fonction de l'utilisation. Les conteneurs peuvent être rentables car ils nécessitent moins de ressources et sont plus faciles à mettre à l'échelle.

Figure 12.13 Une image est construite pour déployer une application dans des conteneurs qui s'exécutent sur différentes ressources informatiques. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les conteneurs sont des instances d'une image de conteneur (container image). Une image de conteneur (container image) représente un état binaire qui est construit en « superposant » une application et ses dépendances sur la « couche » requise de binaires et de bibliothèques du système d'exploitation, ce qui établit une relation parent-enfant entre les couches d'image. La Figure 12.14 montre le processus de construction d'une image. Par exemple, à la racine de l'arbre parent-enfant se trouve une couche qui fournit un système de fichiers formaté. Au-dessus de cette couche se trouve une image de base qui pourrait contenir Ubuntu, Debian, CentOS ou un autre système d'exploitation. Cette image de base peut alors être un parent d'une autre image, telle qu'une image qui ajoute Python. Enfin, une autre image au-dessus de l'image Python peut contenir l'application qui a été implémentée en Python, telle qu'une application web Django. Django est un cadriciel d'application web à code source ouvert, qui est un cadriciel logiciel qui facilite le développement, la maintenance et l'extensibilité des applications web. En effet, ces couches d'images sont organisées en une hiérarchie d'images où chaque couche crée un instantané.

Figure 12.14 Les images sont construites comme des couches d'une application, de ses dépendances et d'autres couches requises. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Un avantage de cette structure hiérarchique est qu'elle permet de partager des images à différents niveaux de la hiérarchie. Si vous souhaitez exécuter l'application web Django, vous extrayez l'intégralité de la hiérarchie de l'image construite. Cependant, d'autres couches de la hiérarchie peuvent être partagées avec d'autres éléments (par exemple, la couche Python), réduisant ainsi le besoin de déplacer des piles d'applications entières. L'image de conteneur construite est un artefact indépendant et autonome qui peut être déployé dans n'importe quel environnement doté d'un environnement d'exécution de conteneur (par exemple, Docker) installé. L'Open Container Initiative est une communauté qui tente de gouverner et d'aborder l'uniformité et la normalisation des environnements d'exécution et des images de conteneurs. Il s'agit d'une initiative importante pour que les conteneurs puissent « construire une fois et exécuter partout ».

Cadriciel basé sur les API

Les microservices qui dépendent les uns des autres communiquent à l'aide d'API bien définies. Ces API aident à configurer les couches d'infrastructure pour faciliter le partage des ressources entre elles. Les API connectent les microservices et les conteneurs tout en simplifiant la maintenance et la sécurité. Elles permettent aux microservices de communiquer entre des services autrement faiblement couplés sans partager les mêmes piles technologiques, bibliothèques ou cadriciels. Les microservices infonuagiques natifs utilisent des API légères basées sur des protocoles tels que le transfert d'état représentationnel (representational state transfer) pour exposer leurs fonctionnalités. Le style architectural pour fournir des standards entre les ressources afin qu'elles puissent communiquer entre elles sur le Web est appelé transfert d'état représentationnel (REST) (representational state transfer (REST)).

Cadriciel orchestré dynamiquement

Comme déjà mentionné, la couche d'ordonnancement et d'orchestration d'un cadriciel d'informatique en nuage (cloud computing) gère les conteneurs dans lesquels les microservices sont déployés. À mesure que les applications s'étendent sur plusieurs conteneurs déployés sur plusieurs serveurs, leur exploitation devient plus compliquée. Les outils d'orchestration de conteneurs (par exemple, Kubernetes) peuvent aider à coordonner et à planifier de nombreux conteneurs (container). Ils peuvent également aider à faire évoluer les instances de conteneurs pour fournir plus de puissance de calcul. Par exemple, l'outil d'orchestration, représenté comme « Maître » dans la Figure 12.15, déploie les microservices dans des conteneurs (instances uniques, initialement) d'une application sur une ressource informatique.

Figure 12.15 L'orchestration de conteneurs est utilisée pour gérer les microservices dans une application infonuagique native. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

À mesure que la consommation des ressources informatiques par les microservices augmente, des ressources supplémentaires sont ajoutées, et l'outil d'orchestration commencera à ordonnancer et à mettre à l'échelle les microservices. Une plateforme d'orchestration (orchestration platform) aide à planifier les microservices et les conteneurs et optimise l'utilisation de la ressource informatique. En revanche, une application monolithe (monolith) n'est pas conçue pour tirer parti d'une plateforme d'orchestration et nécessite l'utilisation d'équilibreurs de charge. D'autres services, tels que la découverte de services, doivent également être effectués manuellement. Par exemple, si les microservices doivent communiquer entre eux, ils ne peuvent pas trouver les adresses IP de leurs conteneurs respectifs et vérifier s'ils sont en cours d'exécution. Cela est géré automatiquement par la plateforme d'orchestration (c'est-à-dire Microsoft AKS, Amazon AWS EKS, Google GKE). Une plateforme d'orchestration exécute généralement des charges de travail en plaçant les conteneurs correspondants dans des pods qui s'exécutent sur des nœuds (c'est-à-dire une machine virtuelle ou physique). Plusieurs nœuds sont généralement regroupés en grappes pour assurer l'extensibilité. Les pods sont les plus petites unités de calcul déployables ; ils regroupent plusieurs conteneurs, fournissent des ressources de stockage et de réseau partagées, et spécifient comment exécuter les conteneurs. La plateforme d'orchestration fournit un support lorsqu'un pod qui contient un microservice conteneur en cours d'exécution tombe en panne. Dans ce cas, un autre pod est rapidement mis en place et automatiquement intégré au champ d'application de ce service. La Figure 12.16 montre comment les conteneurs de microservices sont mis à l'échelle et gérés en cas de défaillance.

Figure 12.16 L'orchestration de conteneurs est utilisée pour la mise à l'échelle automatique et la vérification de l'état de santé des microservices dans une application infonuagique native mise à l'échelle. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

DevOps Agile et automatisation via CI/CD

DevOps est une méthodologie qui combine le développement logiciel agile et les opérations informatiques pour livrer des logiciels plus rapidement et de meilleure qualité. Parce que DevOps et le cloud natif se concentrent sur différents aspects du processus de développement d'applications, ils se complètent mutuellement en facilitant l'agilité. DevOps se concentre sur les principes et les pratiques utilisés dans le développement et les opérations. Un objectif de DevOps est de s'assurer que tous les membres de l'équipe sont polyvalents, afin qu'ils aient une mentalité unique pour améliorer l'expérience client, répondre plus rapidement aux besoins de l'entreprise et s'assurer que l'innovation est équilibrée avec les besoins de sécurité et opérationnels. Le cloud natif, d'autre part, se concentre sur l'environnement d'application et sur la façon de mettre à l'échelle et de livrer des logiciels plus efficacement.

L'utilisation d'un pipeline DevOps pour migrer une application vers une architecture de microservices permet d'atteindre les objectifs d'automatisation, de discipline et de répétabilité tout en réduisant certains des défis déjà identifiés. À mesure qu'une application infonuagique native (cloud-native application) progresse dans le pipeline DevOps, elle évolue également vers la livraison continue (continuous delivery).

La Figure 12.17 montre l'intégration et le déploiement continus (CI/CD) (continuous integration and continuous deployment (CI/CD)), qui est un ensemble de principes de fonctionnement DevOps qui permettent aux équipes de développement de se concentrer sur des intégrations rapides et fréquentes de nouveau code dans l'application en développement ainsi que sur une livraison ou un déploiement rapide et fréquent de nouvelles itérations de l'application. Cela permet aux équipes de livrer des modifications de code plus fréquemment et de manière plus fiable. Une équipe DevOps établit un pipeline CI/CD, qui est une série d'étapes nécessaires à l'intégration et à la livraison ou au déploiement qui comprend le processus de construction par lequel l'application est compilée, construite, empaquetée et testée. La partie intégration continue (continuous integration) automatise le processus de compilation, de construction, d'empaquetage et de test de l'application, lui permettant de s'exécuter indépendamment des ressources physiques, ce qui permet un processus d'intégration plus cohérent. Cela améliore la communication de l'équipe et conduit à une meilleure qualité logicielle. La partie livraison continue (continuous delivery) va plus loin et automatise également l'étape de déploiement. Au cours de cette phase, l'application est déployée dans des environnements d'infrastructure sélectionnés. Les paquets construits pendant l'IC sont déployés dans plusieurs environnements (par exemple, développement, staging). La construction de l'application subit des tests d'intégration et de performance. Enfin, l'application est déployée en production et mise à la disposition des utilisateurs finaux.

Figure 12.17 Un pipeline DevOps est utilisé pour une application infonuagique native à mesure que les mises à jour de son code de microservices y progressent. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Mise à l'échelle élastique et dynamique (montée/descente)

Les applications infonuagiques natives tirent parti de l'élasticité du nuage en mettant à l'échelle les microservices. Les microservices qui nécessitent des ressources supplémentaires peuvent être mis à l'échelle à la demande pour répondre à une capacité accrue. Le microservice peut également être réduit lorsque l'utilisation diminue. Les ressources qui ont été allouées pendant la montée en charge peuvent être désallouées lorsqu'elles ne sont plus nécessaires. Une application infonuagique native peut ainsi s'adapter aux ressources augmentées ou diminuées et s'adapter selon les besoins.

Docker

Docker est une plateforme à code source ouvert qui crée, déploie et gère des conteneurs à l'aide d'un système d'exploitation commun. Il isole les ressources, permettant à plusieurs conteneurs d'utiliser le même système d'exploitation sans conflit. Docker est devenu la norme pour la technologie des conteneurs (container). Un avantage offert par les conteneurs est la portabilité. Les conteneurs Docker peuvent être déployés n'importe où, sur n'importe quelle machine virtuelle physique ou dans le nuage. L'utilisation de Docker aide à réduire la taille du développement et fournit des empreintes plus petites des systèmes d'exploitation dans les conteneurs. Généralement mesurés en mégaoctets, les conteneurs Docker utilisent beaucoup moins de ressources que les machines virtuelles et démarrent presque immédiatement. Les conteneurs Docker sont légers, ce qui les rend facilement extensibles. La Figure 12.18 illustre un aperçu du processus Docker.

Figure 12.18 Une image Docker est construite à partir d'un Dockerfile pour déployer une application qui s'exécute dans un conteneur Docker. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Pour déployer des applications à l'aide de Docker, la première étape typique consiste à créer un Dockerfile. Le Dockerfile est un document texte qui contient des instructions pour construire une image Docker. Une image Docker peut être basée sur une autre image avec des personnalisations supplémentaires. Les images Docker sont une collection de couches immuables où chaque instruction d'un Dockerfile crée une couche dans l'image. Une fois construites, les images Docker deviennent des modèles immuables pour la création de conteneurs Docker, qui sont des instances en cours d'exécution de ces images contenant tout le nécessaire pour que l'application fonctionne.

Kubernetes

Kubernetes est une plateforme d'orchestration (orchestration platform) à code source ouvert utilisée pour automatiser le déploiement, la mise à l'échelle et la gestion des charges de travail basées sur des conteneurs. Un exemple de plateforme Kubernetes est présenté à la Figure 12.19.

Figure 12.19 Une application infonuagique native est déployée dans un environnement Kubernetes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La charge de travail (workload) fait référence à une application exécutée sur Kubernetes. Le nœud maître Kubernetes comprend le plan de contrôle, qui comporte plusieurs composants importants, notamment un contrôleur de services, un contrôleur de nœuds, un contrôleur de points de terminaison, un contrôleur de réplication et un ordonnanceur. Ces composants sont responsables de fonctionnalités telles que l'équilibrage de charge en distribuant efficacement les requêtes réseau entre les conteneurs ; les conteneurs auto-réparateurs en les vérifiant régulièrement pour leur bonne santé et où les conteneurs défaillants sont remplacés ou redémarrés automatiquement ; les conteneurs à mise à l'échelle automatique en les ajoutant ou en les supprimant en fonction de la demande ; le déploiement automatisé pour gérer la configuration et le déploiement des conteneurs dans le nuage ; la gestion du stockage pour gérer les besoins de stockage de tous les conteneurs ; et la gestion du réseau entre les conteneurs.

Le nœud maître Kubernetes comprend plusieurs composants, dont le serveur API Kubernetes, qui joue un rôle crucial dans la gestion des charges de travail basées sur des conteneurs (container). De plus, la grappe Kubernetes se compose de nœuds de travail, chacun contenant un kubelet. Travaillant en tandem avec le nœud maître, le kubelet gère des tâches telles que l'ordonnancement et assure le bon fonctionnement des applications déployées au sein des nœuds de travail. Kubernetes est devenu la plateforme privilégiée pour le déploiement d'applications infonuagiques natives. Dans cet écosystème, les microservices d'une application infonuagique native interagissent sur le réseau, déployés et mis à l'échelle au sein d'une grappe Kubernetes.

Pour déployer une application infonuagique native dans un environnement Kubernetes, les conteneurs de microservices, extraits d'un registre, sont déployés dans des pods. Un pod est une petite unité logique qui exécute un conteneur au sein d'un nœud de travail dans la grappe Kubernetes. Une grappe est un ensemble d'un ou plusieurs nœuds. Les pods sont un groupe d'un ou plusieurs conteneurs avec des ressources de stockage et de réseau partagées et une spécification pour la façon dont les conteneurs sont exécutés. Les conteneurs ne doivent être planifiés ensemble dans un seul pod que s'ils sont étroitement couplés et doivent partager des ressources. Les pods sont éphémères, ce qui signifie qu'ils sont des ressources non permanentes. Kubernetes gère les pods plutôt que les conteneurs directement. Le serveur API sur le nœud maître Kubernetes communique avec le nœud de travail pour déployer le conteneur dans un pod et le démarrer. Les répliques de pods peuvent être augmentées pour mettre à l'échelle le microservice conteneurisé qu'il contient. Si un pod échoue, un nouveau est créé. Kubernetes gère ces déploiements pendant toute la durée du déploiement jusqu'à ce que le pod soit supprimé. En d'autres termes, il garantit que tous les pods et répliques sont en cours d'exécution.

La découverte de services est un autre service important fourni par la plateforme Kubernetes. À mesure que les pods sont ajoutés et répliqués, une adresse IP interne est fournie pour le pod, rendant le conteneur accessible. Les pods sont éphémères, de sorte que les adresses IP peuvent changer à mesure que de nouveaux pods sont créés. Les capacités de registre de services et de découverte de services résolvent ce problème en créant des services Kubernetes. Un service Kubernetes est une abstraction qui définit un ensemble logique de pods et une politique pour y accéder de manière fiable.

Terraform

Terraform est un outil IaC à code source ouvert utilisé pour construire, mettre à jour et versionner les ressources infonuagiques et sur site. Parmi les cas d'utilisation de Terraform, on trouve la gestion des grappes Kubernetes et le provisionnement de ressources dans le nuage, entre autres.

GitLab et GitHub CI/CD

GitLab est une plateforme DevOps basée sur le nuage utilisée pour surveiller, tester et déployer le code d'application. GitLab comprend un dépôt Git basé sur le nuage ainsi que plusieurs fonctionnalités DevOps telles que CI/CD, la sécurité et des outils de développement d'applications. L'outil CI/CD peut être utilisé pour automatiser les tests, le déploiement et la surveillance des applications. GitLab peut également être utilisé pour l'analyse de sécurité, l'analyse statique et les tests unitaires. GitHub est une plateforme de développement basée sur le nuage utilisée pour le développement logiciel, la collaboration et la sécurité. GitHub comprend également un dépôt Git basé sur le nuage et plusieurs fonctionnalités DevOps similaires à GitLab.

Red Hat OpenShift

OpenShift est la plateforme d'applications infonuagiques de Red Hat. Elle comprend plusieurs produits logiciels de conteneurisation, y compris la plateforme de conteneurs OpenShift qui fonctionne sur le système d'exploitation Red Hat Linux et Kubernetes. OpenShift est une plateforme en tant que service (Platform as a Service) (PaaS) qui inclut la plateforme Kubernetes, les images de conteneurs (container) Docker, ainsi que des fonctionnalités exclusives à la plateforme OpenShift. Ces fonctionnalités incluent les définitions de pipeline CI/CD, les outils d'automatisation des conteneurs, l'interface de ligne de commande Kubernetes et les fonctionnalités de sécurité. OpenShift fournit un environnement de développement robuste et multilingue, ainsi que tous les composants logiciels nécessaires pour prendre en charge les applications. OpenShift est une application à code source ouvert et téléchargeable gratuitement qui permet aux développeurs de déployer rapidement des applications web, mobiles et IoT.

Tanzu

Le logiciel d'application infonuagique de VMWare, Tanzu, anciennement connu sous le nom de Cloud Foundry, est une plateforme d'application modulaire qui fournit un riche ensemble d'outils de développement et un chemin pré-établi vers la production pour construire et déployer des applications rapidement et en toute sécurité sur n'importe quel nuage public (public cloud) conforme ou une grappe (cluster) Kubernetes sur site. Tanzu fournit une chaîne d'approvisionnement de résultats opérationnels et de sécurité pour l'environnement de développement via des configurations conçues avec des principes opérationnels et de sécurité afin que les applications puissent être poussées en production rapidement, exécutées et mises à l'échelle en toute sécurité. Ces principes incluent l'exécution du code dans un environnement de test et l'assurance que le code fonctionne correctement, l'application d'une analyse de sécurité afin que l'application qui passe en production soit auditée et conforme aux politiques de sécurité, et le déploiement de l'application dans des environnements de production qui peuvent inclure plusieurs environnements de grappes pouvant s'exécuter et s'adapter en production.

Node

Node est un environnement d'exécution JavaScript côté serveur, multiplateforme et à code source ouvert, qui peut être utilisé pour développer des outils et des applications côté serveur en JavaScript. Parmi les exemples d'applications en temps réel, on trouve les chats, les fils d'actualité et d'autres microservices. Par exemple, Node peut être utilisé pour créer des serveurs virtuels et définir les routes qui connectent les microservices à des API externes telles que les API du système d'exploitation, y compris les bibliothèques HTTP et de système de fichiers, par rapport aux API JavaScript spécifiques aux navigateurs.