Pourquoi les conteneurs sont-ils importants ?

Effectué

Dans cette leçon, vous allez suivre l’équipe Tailspin, qui discute de certaines améliorations nécessaires à son processus DevOps. Dans ce scénario, l’équipe utilise Docker pour conteneuriser son application web. Elle met ensuite à jour son pipeline CI/CD pour le prendre en charge.

Un travail long et difficile

Les dernières semaines ont été particulièrement éprouvantes chez Tailspin. Les équipes peinent à respecter les délais pour diverses raisons, et la productivité dans l’entreprise est devenue une réelle préoccupation. Andy a convoqué des parties prenantes clés de l’équipe web de Space Game pour recueillir leurs commentaires en vue d’une prochaine présentation devant la direction.

Andy : Merci d’être venus. Je sais que les dernières semaines ont été très difficiles pour tout le monde, mais j’ai une bonne nouvelle. La direction organise une réunion à l’extérieur de l’entreprise demain. Elle aimerait connaître nos propositions de changement pour améliorer les performances. Ils m’ont invité à présenter une étude de cas sur nos réussites en DevOps et se sont dits prêts à considérer toutes nos idées. Je pensais donc saisir cette opportunité pour effectuer un brainstorming. Qui souhaite commencer ?

Tout le monde regarde Amita. Elle a été particulièrement frustrée ces derniers temps.

Amita : Je commence. Comme vous le savez, j’effectue des tests pour plusieurs équipes. C’est parfois difficile, car chaque équipe utilise sa propre pile technologique. Même quand elles utilisent les mêmes plateformes sous-jacentes comme .NET ou Java, elles ciblent souvent des versions différentes. J’ai parfois l’impression de passer la moitié de ma journée à préparer les environnements de test pour les rendre aptes à l’exécution du code. Quand quelque chose ne fonctionne pas, il m’est difficile de savoir s’il y a un bogue dans le code ou si j’ai configuré accidentellement la version 4.2.3 au lieu de la version 4.3.2.

Andy écrit sur le tableau blanc « Défis liés au versioning des dépendances pour l’AQ ».

Tim : J’aimerais ajouter un autre point : cette frustration est également due aux opérations. Certaines de nos équipes ont leurs propres spécifications de version, donc nous devons publier leurs applications sur leurs propres machines virtuelles juste pour nous assurer que leurs spécifications de version et de composant ne sont pas en conflit avec nos autres applications. Au-delà de la surcharge qu’implique la gestion du jeu de machines virtuelles supplémentaire, nos coûts sont également plus élevés que si nous pouvions exécuter ces applications côte à côte.

Andy écrit sur le tableau blanc « Surcharge due à la résolution de l’isolation des applications avec les machines virtuelles ».

Mara : Je souhaite également aborder l’aspect développement. Il y a quelques semaines, je travaillais sur le système de mise à jour de pair à pair. Tout fonctionnait sur ma machine. Mais quand je l’ai transmis au déploiement, il ne fonctionnait pas en production. J’avais oublié que je devais ouvrir le port 315 dans le cadre du service. Il nous a fallu plus d’une journée pour détecter le problème et comprendre ce qui se passait. Une fois le port ouvert en production, tout fonctionnait comme prévu.

Andy écrit sur le tableau blanc « Incohérences de configuration entre les phases de déploiement ».

Andy : Je pense que cette conversation est un bon début. Donnez-moi le temps d’examiner ces problèmes et de voir ce que je peux faire. Voici les préoccupations que vous avez exprimées :

• Défis liés au contrôle de version des dépendances pour l’assurance qualité
• Surcharge due à la résolution de l’isolation des applications avec les machines virtuelles
• Incohérences de configuration entre les phases de déploiement

Un conteneur pour tout regrouper

Le matin suivant, Andy organise une réunion pour présenter une nouvelle idée à l’équipe.

Andy : Hier, j’ai abordé avec certains collègues les défis auxquels nous sommes confrontés. Ils ont fait des suggestions intéressantes, notamment le recours à Docker. Et j’ai vraiment hâte d’essayer. Cette technologie assure l’empaquetage d’applications entières sous forme de conteneurs.

Amita : Qu’est-ce qu’un conteneur ? C’est une sorte de fichier .zip ?

Andy : Pas exactement. Cela ressemble davantage à une machine virtuelle légère conçue pour s’exécuter directement sur le système d’exploitation hôte. Quand vous générez votre projet, la sortie est un conteneur qui comprend votre logiciel et ses dépendances. Toutefois, il ne s’agit pas d’un système virtualisé complet. Il peut donc démarrer en moins d’une seconde.

Tim : Comment gère-t-il la sécurité et l’isolation ?

Andy : La sécurité et l’isolation sont gérées par le système d’exploitation hôte. Quand le conteneur s’exécute dans un processus hôte, il est isolé des autres processus de la même machine hôte. Cette isolation permet à votre conteneur de charger toutes les versions de composants dont il a besoin, quelle que soit l’activité des autres conteneurs. Cela signifie également que vous pouvez facilement exécuter plusieurs conteneurs simultanément sur le même hôte.

Amita : Cette solution semble idéale pour l’environnement de production, mais résout-elle les problèmes que nous rencontrons plus tôt dans le pipeline ?

Andy : Bien sûr. Le conteneur entier devient l’artefact, ce qui élimine la nécessité de transmettre le code source ou un ensemble de fichiers binaires. Ainsi, quand Mara travaille au développement, ses sessions de débogage s’exécutent localement sur le conteneur hébergé sur sa machine. Quant à Amita elle effectue les tests sur une copie du même conteneur, qui comprend déjà toutes les versions de dépendances nécessaires. Enfin, quand Tim gère notre environnement de production, les conteneurs qu’il supervise sont des copies autonomes des conteneurs développés par Mara et testés par Amita.

Mara : Est-il difficile de développer une application conteneur ? Devons-nous apporter des changements importants à notre code existant ?

Andy : Les conteneurs sont essentiellement une technologie d’empaquetage et de déploiement. Ils n’impactent pas le logiciel fondamental que nous écrivons. Nous pouvons simplement indiquer à nos outils qu’ils doivent produire un conteneur Docker quand la build est terminée. Ensuite, durant le débogage, l’application s’exécute à partir de ce conteneur local et non de notre serveur web local. En fait, certains outils tels que Visual Studio permettent même de basculer entre différents environnements de débogage comme Docker et IIS Express. Nous bénéficions ainsi de la flexibilité dont nous avons besoin. Pour tester le processus, j’ai dupliqué notre projet de site web la nuit dernière, puis je l’ai converti afin de le créer en tant que conteneur Docker. J’ai simplement eu besoin d’ajouter une configuration de conteneur de base sans apporter le moindre changement à notre code existant.

Mara : C’est bon à savoir. J’imagine même que l’on peut mettre à jour le pipeline de mise en production dans Azure Pipelines à partir de cette duplication pour générer et déployer la version Docker.

Andy : Vous lisez dans mon esprit !

Qu’est-ce que Docker ?

Docker est une technologie qui automatise l’empaquetage et le déploiement de conteneurs portables autonomes. Les conteneurs Docker peuvent être exécutés dès lors qu’un hôte Docker est disponible, et ce, aussi bien sur une machine de développement que sur un serveur départemental, dans un centre de données d’entreprise ou dans le cloud. Azure offre plusieurs moyens d’exécuter des applications conteneur, notamment par le biais d’App Service ou de clusters managés avec des technologies d’orchestration telles que Kubernetes.

L’équipe Tailspin a choisi d’utiliser des conteneurs Docker pour ce scénario, car ils apportent des réponses à tous ses problèmes :

• Défis liés au contrôle de version des dépendances pour l’assurance qualité : Les applications sont empaquetées sous forme de conteneurs qui incluent les versions appropriées de leurs dépendances.

• Surcharge due à la résolution de l’isolation des applications avec les machines virtuelles : Il est possible d’exécuter de nombreux conteneurs isolés sur le même hôte, ce qui apporte plusieurs avantages par rapport aux machines virtuelles : temps de démarrage plus court, plus grande efficacité des ressources, etc.

• Incohérences de configuration entre les phases DevOps : Les conteneurs sont transmis avec des manifestes qui automatisent la configuration requise, notamment les ports qui doivent être exposés.

L’adoption des conteneurs Docker peut être une étape clé vers une architecture de microservices. Nous approfondirons ce sujet plus tard.

Vérifiez vos connaissances

1.

Parmi les options suivantes, quelle est celle qui ne constitue pas une bonne raison d’utiliser Docker ?

Vous créez des applications mobiles et souhaitez qu’un seul conteneur mobile s’exécute sur différents systèmes d’exploitation.

Les dépendances requises par votre application sont spécifiques, et vous souhaitez empaqueter ces dépendances avec l’application elle-même pour le déploiement.

Vous souhaitez que les différentes phases de votre pipeline utilisent le même environnement que celui utilisé en production.

2.

Quelles sont les similarités entre les conteneurs et les machines virtuelles ?

Ils exécutent tous deux leur propre système d’exploitation virtualisé.

Ils assurent tous deux l’isolation des applications qu’ils contiennent.

Ils offrent les mêmes performances.

3.

Que représente la surcharge impliquée par la migration d’une application .NET Core existante pour utiliser un conteneur Docker ?

Une surcharge importante. Docker utilise ses propres langages de programmation et son propre framework de développement. Les applications doivent donc être regénérées.

Une surcharge relative. Le code d’application doit être ajusté pour charger les paramètres et données de configuration Docker.

Une très faible surcharge. L’application ne nécessite normalement aucune modification. Cependant, un manifeste Docker qui spécifie la configuration requise pour l’application doit être ajouté.

Vous devez répondre à toutes les questions avant de vérifier votre travail.