Kishan Gohil, développeur de systèmes Cloud, a récemment participé à l’événement « Ignite The Tour » de Microsoft à Londres. Dans cet article, il aborde un sujet d’actualité brûlant : les conteneurs.
Microsoft a organisé son événement tant attendu Ignite The Tour à Londres les 16 et 17 janvier 2020 – et quel événement de deux jours ! Les participants ont eu droit aux fonctionnalités les plus récentes et les plus performantes de la plateforme cloud Microsoft Azure. L’ordre du jour comprenait un programme de sessions de démonstration (y compris Microsoft AI & Azure Arc) ainsi que des présentations sur de nombreux sujets importants. Un sujet clé qui a attiré de nombreux participants était l’utilisation des conteneurs et les fonctionnalités des conteneurs dans Azure.
Il n’y a aucun doute à ce sujet : les conteneurs sont arrivés et c’est l’une des tendances les plus chaudes aujourd’hui et elle ne fera que s’amplifier et s’améliorer en 2020.
Qu’est-ce qu’un conteneur exactement ?
Un conteneur est une ressource isolée qui a été empaquetée avec tout le code, les packs et les dépendances afin qu’une application puisse être rapidement déployée et exécutée d’une plateforme à une autre. Un conteneur vise une virtualisation complète pour les « choses » requises par l’application et tout est autonome. Ce qui est encore mieux, c’est que les conteneurs offrent un nouveau niveau d’efficacité et de portabilité, car la virtualisation se fait sur le système d’exploitation et non sur le matériel ou l’infrastructure.
Quelle est la vision dʼAzure sur les conteneurs ?
De nombreuses présentations à Ignite The Tour se sont concentrées sur les fonctionnalités d’Azure avec des conteneurs, qui atteignent toutes le même objectif : moderniser votre empreinte applicative et Cloud par le biais de la virtualisation. Il existe plusieurs fonctionnalités sur Azure qui valent la peine d’être prises en compte en ce qui concerne les conteneurs, mais pour que les choses restent rapides et faciles en tant qu’offre PaaS, il existe trois services importants.
● Azure Kubernetes Service (ou AKS) est l’offre Azure PaaS qui offre un service facile à utiliser pour déployer et gérer efficacement des applications conteneurisées. L’utilisation dʼAKS nous donne un cluster Kubernetes entièrement géré, donc il n’y a rien à gérer, cʼest « Kubernetes Cluster as a Service ». Kubernetes lui-même nous facilite déjà la tâche en tant qu’orchestrateur de conteneurs et maintenant, avec AKS, quelque chose qui était censé être facile devient plus facile.
● Azure Container Instances (ou ACI) est une technologie sans serveur. Il nous fournit un moyen d’exécuter des conteneurs sur Azure sans avoir besoin de serveurs / machines virtuelles. L’exécution d’ACI dans Azure est un moyen rapide de mettre en place un conteneur de manière isolée. Cependant, il ne fournit pas d’orchestration de la manière dont vous obtenez sur AKS. Personnellement, je me tournerais vers ACI pour tester les conteneurs, mais AKS pour mes charges de travail de production.
● Web Apps for Containers (qui fait partie d’Azure App Service) prend en charge l’exécution de conteneurs. Il s’agit d’un autre excellent candidat pour exécuter une charge de travail de production spécifiquement pour une application Web, qu’il s’agisse d’une nouvelle application ou d’une application migrée/modernisée. Cʼest un moyen rapide et facile de déployer une application web, et offre les avantages dʼun App Service tels que la mise à l’échelle du nombre dʼexembres dʼapplications et l’utilisation dʼun DNS personnalisé pour donner à votre page Web une URL plus sophistiquée. Publiez simplement votre image Docker dans l’App Service plutôt que dans votre code !
Que sont Docker et Kubernetes ?
De nombreuses personnes pensent que ces deux produits sont la même chose ou des concurrents directs. En fait, Kubernetes est un outil d’orchestration de conteneurs tandis que Docker est la plateforme de conteneurs. Docker est devenu un mot plus généralisé pour nous lorsque nous parlons de conteneurs. En fait, nous devons comparer Docker Swarm et Kubernetes en tant que deux orchestrateurs, tandis que Docker Engine est la plateforme de conteneur (considérez-le comme la « chose » qui exécute vos conteneurs pour vous).
Kubernetes et Docker Swarm sont donc similaires, mais Kubernetes est le « préféré », étant largement utilisé par Azure, AWS et GCP ! L’utilisation de Kubernetes et Docker (Moteur) ensemble est la plus courante de nos jours.
Les conteneurs sont-ils complètement nouveaux ?
Non, pas complètement.
Dans leur forme actuelle, les conteneurs sont la prochaine grande nouveauté (ou la grande nouveauté actuelle) dans l’ère des charges de travail Cloud. Avant Azure, vous pouviez exécuter des applications Java « in-container » dans Apache Tomcat / WebLogic Server. Ici, le conteneur était le servlet et il exécutait une ou plusieurs applications. Cependant, nous avions besoin de machines virtuelles, nous avions besoin de beaucoup d’infrastructure, nous avions besoin de support, nous avions besoin de correctifs, ce n’était pas un service géré et ce n’était certainement pas facile à mettre à l’échelle.
Pourquoi utiliser des conteneurs ?
L’un des cas d’utilisation les plus courants (mentionné dans Ignite The Tour dans plusieurs sessions) est l’idée d’utiliser un conteneur pour empaqueter, moderniser et migrer rapidement une application existante afin d’obtenir la charge de travail sur Azure. Compte tenu de la portabilité des conteneurs, nous sommes en mesure d’exécuter l’application sur nos environnements de développement local avec le même code, les mêmes packages et les mêmes dépendances que nous le ferions en production. Cela permet donc aux développeurs de moderniser une application et de la faire fonctionner sur Azure.
Un autre cas d’utilisation mentionné était d’utiliser des conteneurs pour remplacer la plupart des machines virtuelles pour certaines charges de travail et certains traitements. Une façon courante de le faire déjà est d’utiliser des conteneurs (et non des machines virtuelles) en tant qu’agents pour exécuter leur processus CI/CD via Azure DevOps. Microsoft a fourni des agents Linux et Windows basés sur des conteneurs sur Azure DevOps pour exécuter vos pipelines Azure CI/CD. Ces conteneurs sont configurés avec une quantité massive de packs et de bibliothèques courants dont vous avez besoin pour créer, empaqueter et déployer d’autres ressources, services et applications Azure (et non Azure). C’est un énorme avantage parce quʼil est rapide à utiliser, qu’il n’y a rien à gérer et qu’il n’y a pas de coûts d’infrastructure ou de stockage.
Et ensuite ?
Il n’y a pas si longtemps, l’idée était de migrer des VM/serveurs physiques sur site vers des VM Azure afin de pouvoir évoluer rapidement et bénéficier de services basés sur le cloud. C’est ainsi qu’est née l’idée du « lift and shift », qui permet de mettre le pied dans le Cloud. Cependant, beaucoup ne faisaient que traiter le Cloud comme une machine virtuelle. Dans le Cloud, mais avec une perspective vraiment limitée.
Je pense qu’il y a maintenant une nouvelle direction avec les conteneurs. Remplacez les machines virtuelles par des conteneurs ou modernisez et migrez les applications dans un conteneur hébergé dans le Cloud. Espérons que cela nous pousse dans un espace moderne de migration vers le Cloud – alors éloignons-nous du « lift and shift » où le « shift » semble être une activité ponctuelle et pensons davantage à « migrer et innover » ou « bouger et améliorer ».
Continuons à réfléchir à de nouveaux moyens de faciliter la livraison rapide des applications et des services. Après tout, nous voyons continuellement de plus en plus de services innovants lancés sur Azure, AWS et GCP – les limites sont définitivement repoussées quant à ce qui est possible sur le Cloud !
Vous voulez en savoir plus sur la façon dont vous pouvez vous associer à Cloudreach pour migrer et moderniser vos applications vers le Cloud à l’aide de Microsoft Azure ? Cliquez ici.
