Pourquoi l’orchestration des conteneurs est-elle importante ?
Dans cette leçon, vous suivez l’équipe Tailspin qui découvre les stratégies de mise en œuvre d’une nouvelle directive de la direction. L’équipe examine de quelle manière Kubernetes permet de faciliter la transition vers une architecture de microservices.
L’avenir est plus petit
Quelque chose se trame chez Tailspin. Lors d’une récente réunion hors site, Andy a présenté les récentes réussites de son équipe avec Azure DevOps, qui ont été bien reçues. Andy a également présenté une démonstration du récent projet de preuve de concept de l’équipe à l’aide de conteneurs Docker. Ces démonstrations ont conduit à une série de conversations productives sur l’avenir technique de l’organisation. Le lendemain, Andy rentre partager les nouvelles avec l’équipe web de Space Game.
Andy : Les choses se sont vraiment bien passées lors de ma présentation hier. La direction est impressionnée par le travail que nous avons fait jusqu’à présent et nous a donné une mission spéciale.
Tim : Oh-oh. Je suis là depuis assez longtemps pour voir arriver un piège comme celui-là à des kilomètres.
Andy : Non, c’est une excellente opportunité pour nous. La direction a apprécié notre démo de conteneur Docker et souhaite que nous envisagions l’adoption d’une architecture de microservices.
Amita : Des microservices ? Comme les applications pour téléphones et montres ?
Andy : Non, les microservices sont des applications typiques, comme notre application web. La principale différence est qu’au lieu de créer et de déployer une application monolithique unique, nous refactorisons tous les composants qui seraient mieux maintenus et gérés en tant que services autonomes. Nous créons ensuite ces services pour être bons à ce qu’ils font et les déployons pour qu’ils fonctionnent de manière indépendante.
Tim : Tout ça ne me plaît pas. Je gère déjà un grand nombre de services dans nos environnements. Je ne sais pas si je pourrai en prendre beaucoup plus.
Andy : C’est un problème compréhensible. Heureusement, il existe des outils excellents pour gérer une multitude de conteneurs dans un environnement donné. Nous avons été invités à produire une solution à plusieurs conteneurs pour notre application web orchestrée avec Kubernetes. Ils souhaitent également savoir en quoi cela affectera notre processus DevOps.
Mara : J’ai lu des choses sur Kubernetes. Azure offre une excellente prise en charge avec Azure Kubernetes Service, et je sais qu’il y a une prise en charge des pipelines dans Azure DevOps.
Amita : Ce processus semble complexe. Comment cela va-t-il affecter les tests ?
Mara : Ça ne devrait pas trop changer. Kubernetes offre un moyen de déployer vers différents espaces de noms. Cela nous permet de partitionner nos déploiements afin de pouvoir avoir des environnements entiers dédiés au test et à la production. Et étant donné qu’ils s’exécutent tous dans le même cluster et utilisent les mêmes conteneurs, l’expérience de test devrait offrir ce que nous nous attendons à voir en production.
Amita : Est-il difficile d’effectuer le suivi de l’emplacement de chaque environnement ?
Mara : Non, nous pouvons utiliser des environnements Azure DevOps pour faire tout cela. Vous pourrez déterminer où se trouve chaque service et comment il s’est retrouvé là via le portail. Tout est automatisé via le pipeline. Il n’y aura donc rien à suivre manuellement. Le seul problème que j’ai à présent est l’impact que cela aura sur notre expérience de développement.
Andy : La bonne nouvelle est que l’impact est minime. En supposant que nos projets sont configurés pour créer des conteneurs Docker, tout ce que nous avons à déployer dans Kubernetes est un fichier manifeste qui décrit les services et leurs déploiements.
Mara : Vous avez pensé à ce que nous allons refactoriser en tant que deuxième conteneur ? Je sais que plusieurs équipes nous ont demandé de rendre nos classements disponibles par le biais d’une API web.
Andy : J’ai une longueur d’avance. J’ai dupliqué le projet Docker la nuit dernière et refactorisé la fonctionnalité de données de classement dans son propre microservice. On va se retrouver avec un conteneur pour le site web et un autre pour une API de classement. Les deux conteneurs sont configurés pour avoir leurs propres points de terminaison publics que nous pouvons partager avec quiconque souhaite utiliser le site ou l’API, quelle que soit la technologie utilisée par l’application. Si la charge augmente de façon substantielle pour l’un ou l’autre, nous pouvons mettre à l’échelle les conteneurs indépendamment.
Mara : Ce projet m’a l’air génial ! Commençons à mettre à jour le pipeline de mise en production.
Présentation de Kubernetes
Kubernetes est une plateforme d’orchestration de conteneurs open source permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. Il fournit une infrastructure pour l’exécution de systèmes distribués de manière déclarative et réactive. Il peut exécuter des conteneurs sur plusieurs hôtes, ce qui permet une utilisation efficace des ressources et une meilleure fiabilité.
L’équipe Tailspin a choisi d’utiliser Kubernetes pour ce scénario, car la plateforme correspond à tous les besoins :
Complexité des déploiements à plusieurs conteneurs : Kubernetes est tout d’abord conçu pour automatiser les processus de déploiement et de gestion des déploiements de conteneurs.
Cohérence entre les environnements et les phases : tout comme les conteneurs garantissent un déploiement cohérent pour les applications qu’ils contiennent, Kubernetes garantit un déploiement cohérent pour les conteneurs gérés par un cluster.
Prise en charge Azure DevOps : Azure DevOps offre une prise en charge de première classe pour l’utilisation de Kubernetes.
Facilité de développement : l’impact de Kubernetes sur un projet source est comparable à celui de l’ajout de la prise en charge de Docker, qui est minime et limité à la configuration déclarative.
L’adoption de Kubernetes simplifie considérablement le processus d’adoption d’une architecture de microservices qui utilise plusieurs conteneurs Docker.