Docker : un aperçu rapide

L’année dernière, Sitecore a annoncé une prise en charge limitée de l’exécution de nos produits à l’intérieur de conteneurs. Pour en savoir plus sur le modèle de prise en charge actuel, consultez cet article article de la base de connaissances. Avec chaque version future, nous prévoyons d’augmenter notre prise en charge de l’exécution de nos produits dans des conteneurs. Pour tous ceux qui débutent dans l’exécution d’applications de cette manière, cet article fournira un aperçu de certains des concepts clés et fournira des liens pour en savoir plus sur chacun d’eux.

Regardez la vidéo accompagnant cet article ci-dessous, qui comprend des démonstrations de ces concepts. Ou regardez-le sur Découvrez Sitecore sur YouTube.

• Avez-vous déjà eu le problème de configurer un nouveau projet sur votre machine avec toutes les dépendances requises ?
• Que diriez-vous de gérer ces dépendances dans tous vos environnements non destinés à la production et de production ?
• Que se passe-t-il lorsque vous devez mettre à niveau une ou plusieurs de ces dépendances ?
• Avez-vous déjà développé par erreur une version d’une dépendance pour découvrir qu’une version différente est en production ?
• Que diriez-vous d’avoir une équipe avec des développeurs qui veulent exécuter différents systèmes d’exploitation (OS) ?
• Le problème ici est que vous déployez uniquement l’application seule et que vous vous appuyez sur l’environnement hôte pour fournir les dépendances. En réalité, l’hôte devrait être responsable du système d’exploitation et pas grand-chose d’autre.

Tous ces problèmes ont en commun les questions de cohérence, d’isolement et de reproductibilité. Ce sont les problèmes que Docker, et les conteneurs en général, ont été créés pour résoudre.

Lorsque vous déployez un conteneur, vous déployez en fait tout ce qui est nécessaire à l’exécution de cette application, à l’intérieur d’un seul artefact.

Comme vous pouvez le voir dans l’image, vous n’êtes pas seulement en train d’installer des suites de produits sur votre application, mais également sur ses dépendances et ses bibliothèques, ses ressources de marketing de configuration et tout ce dont elle a besoin pour s’exécuter. Le tout dans un seul et même actif que vous pouvez déplacer entre vos différents environnements.

Une question courante est de savoir en quoi un conteneur diffère d’une machine virtuelle. Ils ont un certain chevauchement dans les fonctionnalités qu’ils fournissent, mais la façon dont ils y parviennent est fondamentalement différente.

Si vous regardez le diagramme de la machine virtuelle sur la gauche, chacune des cases vertes représente un système d’exploitation entier. Cela signifie qu’il y a quatre systèmes d’exploitation complets présents sur cette infrastructure hôte, ce qui peut imposer une charge importante sur les ressources système et l’espace disque requis.

Comparez cela avec l’approche basée sur les conteneurs à droite. Ici, le noyau et les ressources du système d’exploitation hôte sont directement partagés par les conteneurs par le démon Docker. Cela signifie que les conteneurs sont beaucoup plus légers qu’une machine virtuelle, ce qui signifie que vous pouvez en exécuter beaucoup plus sur la même quantité de matériel.

Maintenant, les conteneurs vus dans l’exemple précédent auront été créés à partir d’une image. Une image est un modèle en lecture seule avec des instructions pour la création d’un conteneur Docker. Les images elles-mêmes sont construites sur le concept de couches, chaque couche s’appuyant sur la couche inférieure. Ce concept signifie qu’il est très simple de personnaliser les images existantes pour créer votre fonctionnalité personnalisée.

Si vous regardez l’image ci-dessus, vous pouvez voir que l’image Sitecore® Experience Platform™ (XP) est basée sur l’image 4.8-windowsservercore-ltsc2019. Nous prenons l’image Windows Server Core publiée par Microsoft et nous ajoutons une couche personnalisée par-dessus pour inclure le code Sitecore. Il peut s’agir d’une image permettant de créer un rôle de gestion de contenu (CM) ou de diffusion de contenu (CD), mais le concept reste le même.

Nous pouvons également prendre cette image Sitecore XP et la développer pour fournir des fonctionnalités supplémentaires. L’image du milieu illustrée ci-dessus prend l’image XP, puis superpose Sitecore PowerShell Extensions (SPE) par-dessus. Le diagramme de droite va encore plus loin, en utilisant l’image SPE que nous venons de créer et en ajoutant une couche pour Sitecore Experience Accelerator (SXA) par-dessus.

Le concept puissant de l’approche en couches est que ces couches sont partagées. Ainsi, l’image Windows Server Core avec laquelle nous avons commencé n’a besoin d’exister sur le disque qu’une seule fois, et les trois images ci-dessus s’y ajoutent.

Vous pouvez lire un bon aperçu de Docker, de ses cas d’utilisation et de l’architecture de l’application sur Docker Docs.

Vous vous demandez peut-être d’où viennent toutes ces images à l’origine. Eh bien, ils sont stockés dans des registres — vous pouvez avoir des registres publics ou privés. Le registre public le plus populaire est Docker Hub. Vous pouvez y trouver des images pour presque tous les logiciels modernes auxquels vous pouvez penser ! Pour importer une image sur votre ordinateur local, vous devez utiliser une commande Docker pull, par ex.

docker pull mcr.microsoft.com/dotnet/samples:dotnetapp

Cette commande affichera l’image mcr.microsoft.com/dotnet/core/samples qui a le tag dotnetapp. Une fois qu’il a été extrait, vous pouvez l’utiliser localement pour créer des conteneurs à partir de celui-ci. Pour ce faire, vous devez utiliser une simple commande d’exécution Docker, par ex.

docker exécuter mcr.microsoft.com/dotnet/samples:aspnetapp

Pour en savoir plus sur les registres, rendez-vous sur Docker Docs.

Les volumes sont un autre des concepts clés lorsque l’on travaille avec des conteneurs. Il existe de nombreuses occasions où il est utile de partager des fichiers entre l’hôte et le conteneur. En voici quelques bons exemples :

• Lorsque vous utilisez des ressources de marketing statiques, vous ne souhaitez pas recréer l’image et recréer votre conteneur pour voir les modifications.
• Lorsque vous travaillez avec des fichiers secrets que vous ne souhaitez peut-être pas inclure dans une image, par exemple des fichiers de licence.

Les volumes sont créés pour résoudre ce problème : ils vous permettent de désigner un dossier sur l’ordinateur hôte à partager et à rendre disponible dans le conteneur. Il s’agit d’une fonctionnalité puissante, car toutes les modifications que vous apportez au contenu du volume sont instantanément répercutées à l’intérieur du conteneur.

Vous pouvez en savoir plus sur les volumes sur Docker Docs.

Le dernier concept clé à aborder ici est la mise en réseau. L’une des raisons pour lesquelles les conteneurs et les services Docker sont si puissants est que vous pouvez les connecter ensemble dans un réseau interne créé par le démon Docker. Un bon exemple de ceci serait un système composé d’une application .NET Core avec un back-end SQL Server. Dans ce scénario, vous pouvez mettre en place deux conteneurs, l’un contenant l’application .NET Core et l’autre contenant SQL Server, et demander à Docker de créer un réseau entre les deux pour leur permettre de communiquer entre eux.

Pour en savoir plus sur la mise en réseau, rendez-vous sur Docker Docs.

Le site Web Docker propose un excellent ensemble de didacticiels pour vous aider à utiliser Docker pour le développement de vos applications, que vous pouvez voir ici :

• https://docs.docker.com/get-started/
• https://docs.docker.com/get-started/part2/
• https://docs.docker.com/get-started/part3/

Merci d’avoir lu et assurez-vous de #LearnSitecore suivre pour le contenu futur !

Rob Earlam, évangéliste technique, Sitecore
https://robearlam.com/