Blogue

Technologie
Virtualisation d’environnement avec Docker
8 septembre 2017
par Erick Girard

Au niveau du développement, la virtualisation n’est pas un nouveau phénomène. Elle est présente sous une forme ou une autre depuis un certain nombre d’années et ses bénéfices sont reconnus. Depuis 2013, un nouveau venu est arrivé : Docker.

Docker

Wikipedia définit Docker ainsi :

Docker est un logiciel libre qui automatise le déploiement d’applications dans des conteneurs logiciels. Selon la firme de recherche sur l’industrie 451 Research, « Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n’importe quel serveur Linux ». Ceci permet d’étendre la flexibilité et la portabilité d’exécution d’une application, que ce soit sur la machine locale, un cloud privé ou public, une machine nue, etc.

La définition de Wikipedia représente bien la réalité des choses, à un détail près, Docker n’automatise pas vraiment le déploiement cependant il en fait parti en tant que facilitateur. Il est aussi à noter que Docker n’est plus strictement lié à Linux (autant en tant que système hôte que système invité) depuis l’intégration native avec Hyper-V dans Windows 10 et Windows Server 2016.

Typiquement, la réflexion porte à la question suivante : quelle est la différence entre Docker et une machine virtuelle classique? Fondamentalement, la différence entre un conteneur Docker et une machine virtuelle est la quantité de layers entre le logiciel hébergé et le métal (les ressources physiques de la machine).

Docker container

machine virtuelle

  
Dans le cas de Docker, comme on peut l’observer ici, les ressources de la machine sont partagées à travers chaque container. De ce fait, un seul système d’opération est présent ici et les performances sont plus grandes puisque l’architecture est plus légère.Dans le cas de machines virtuelles, chaque instance possède une certaine quantité de ressources qui sont ensuite allouées aux applications hébergées. Ainsi, chacune possède son propre système d’opération et les performances sont moindres.

L’utilisation de Docker ici repose principalement sur quatre piliers :

Départ Simple

Voici un petit projet pour démontrer comment intégrer simplement Docker dans une application à déployer.

Prenons en exemple un projet « dotnet core » créé par l’utilitaire de ligne de commande.

mkdir aspnetcore-docker
cd aspnetcore-docker
dotnet new mvc .

Si on lance l’application avec la ligne de commande dotnet run, l’application devrait se lancer normalement. Il faut maintenant créer les fichiers de manifeste Dockerfile qui pourront configurer l’exécution de Docker.

Exemple de fichier Dockerfile fourni par Microsoft dans son répertoire Docker aspnetcore-build :

FROM microsoft/aspnetcore-build AS builder
WORKDIR /source

# Start by restoring the dependencies
COPY *.csproj .
RUN dotnet restore

# copies the rest of your code
COPY . .
RUN dotnet publish --output /publish/ --configuration Release

# Start your application
FROM microsoft/aspnetcore
WORKDIR /publish
COPY --from=builder /publish .
ENTRYPOINT ["dotnet", "aspnetcore-docker.dll"]

Décomposons les instructions :

FROM microsoft/aspnetcore-build AS builder
WORKDIR /source

Ici, on référence l’image Docker aspnetcore-build et on l’identifie sous le nom de builder. Cette image sera référencée plus tard.

COPY *.csproj .
RUN dotnet restore

Ensuite, on rend disponible le fichier csproj dans le container et on effectue une restauration des dépendances avec « dotnet restore ».

COPY . .
RUN dotnet publish --output /publish/ --configuration Release

À cette étape, le contenu du répertoire courant est rendu disponible au container et la commande de publication est effectuée en mode production dans le répertoire « /publish » du container.

FROM microsoft/aspnetcore
WORKDIR /publish
COPY --from=builder /publish .
ENTRYPOINT ["dotnet", "aspnetcore-docker.dll"]

Finalement, à la dernière étape, on utilise une référence vers l’image aspnetcore (cette image est pour l’exécution d’application dotnet core plutôt que le build. L’instruction workdir indique le dossier à partir duquel le container va travailler. L’instruction copy va effectuer sa copie à partir du container builder (défini à partir de aspnetcore-build au début). Finalement, la dernière ligne indique la commande qui sera effectuée au démarrage du container.

Avant de lancer le container, il est important de le construire avec cette commande :

docker build -t aspnetcore-docker .

Le paramètre -t ici va appliquer un tag et donc un nom familier au container.

Exemple de résultat d’un build :

Ensuite, pour exécuter l’application, il faut effectuer la commande suivante :

docker run -it -p 5000:80 aspnetcore-docker

Il est à noter ici que dans la ligne de commande un message affiche « Now listening on: http://+:80 ». Ce message indique qu’à l’intérieur du container, kestrel (le serveur web intégré de dotnet) héberge l’application sur le port 80, mais à l’extérieur du container, le port public est 5000. Il est important de considérer les différences.

Dans ce cas présent, l’application sera maintenant disponible au port 5000 sur la machine locale.

Conclusion

En quelques minutes, nous avons fait un survol de l’utilisation de Docker et ses intérêts pour une application. Les containers sont cependant un monde vaste et d’autres subtilités sont présentes aussi. Dans un futur article, nous examinerons l’utilisation de Docker avec Docker Compose (composition et orchestration de containers) et Docker Swarm (groupage de services en grappe – cluster) pour créer des architectures fluides et bien distribuées.