Docker est une plateforme populaire pour empaqueter des applications sous forme d’artefacts distribuables autonomes. Elle crée des images qui incluent tout ce dont vous avez besoin pour exécuter un logiciel particulier, comme son code source, les dépendances des paquets tiers et les caractéristiques de l’environnement requis.

Comme les images Docker peuvent être exécutées partout où Docker est installé, elles constituent un format viable pour distribuer vos applications CLI. L’écosystème Docker comprend Docker Hub comme registre public disponible par défaut, ce qui vous donne une chaîne d’outils complète pour publier, mettre à jour et documenter vos outils.

Voici comment utiliser Docker pour packager les applications CLI au lieu des gestionnaires de paquets traditionnels du système d’exploitation et des téléchargements binaires autonomes.

Pourquoi utiliser Docker pour les applications CLI ?

Docker permet aux utilisateurs d’installer plus rapidement et plus facilement votre nouvel utilitaire. Ils peuvent exécuter votre application avec Docker au lieu de chercher des instructions d’installation spécifiques à la plate-forme. Il n’y a pas d’extraction manuelle d’archives tar, de copie dans les dossiers système ou de modification du PATH.

Les logiciels Dockerisés permettent également aux utilisateurs de sélectionner facilement différentes versions, d’effectuer des mises à jour et de lancer des retours en arrière. Chaque version distincte que vous créez doit recevoir sa propre balise immuable qui identifie de manière unique son image Docker. Contrairement aux gestionnaires de paquets ordinaires, les utilisateurs peuvent facilement exécuter deux versions de votre logiciel côte à côte en démarrant des conteneurs basés sur des balises d’image différentes.

Un autre avantage est la facilité avec laquelle les utilisateurs peuvent essayer votre application en toute sécurité sans s’engager à long terme. Les gens peuvent hésiter à ajouter de nouveaux paquets à leurs machines, de peur que le logiciel ne parvienne pas à se nettoyer complètement lorsqu’il est retiré. Les conteneurs Docker possèdent leur propre système de fichiers privé ; la suppression d’un conteneur ne laisse aucune trace de son existence sur l’hôte. Cela peut inciter davantage d’utilisateurs à essayer votre application.

Une conséquence naturelle de la distribution Dockerisée est l’obligation pour les utilisateurs de faire tourner Docker sur leur machine. De nos jours, de nombreux développeurs l’exécutent systématiquement, c’est donc un choix assez sûr à faire. Si vous craignez d’exclure les utilisateurs qui ne veulent pas utiliser Docker, vous pouvez toujours proposer des options alternatives via vos canaux de distribution existants.

Pour aller plus loin : Comment déployer PostgreSQL en tant que conteneur Docker

Création d’une image Docker pour une application CLI

Les images Docker pour les applications CLI ne sont guère différentes de celles utilisées pour tout autre type de logiciel. L’objectif est de fournir une image aussi légère que possible tout en regroupant tout ce dont votre application a besoin pour fonctionner.

Il est généralement préférable de commencer par une image de base minimale qui exécute un système d’exploitation simplifié comme Alpine. Ajoutez uniquement les paquets dont votre logiciel a besoin, tels que son langage de programmation, son framework et ses dépendances.

Deux instructions essentielles du Dockerfile pour les outils CLI sont ENTRYPOINT et CMD. Ensemble, elles définissent le processus de premier plan qui sera exécuté lorsque les conteneurs seront lancés à partir de votre image. La plupart des images de base lancent par défaut un shell au démarrage du conteneur. Vous devriez changer cela afin que ce soit votre application qui s’exécute automatiquement, supprimant ainsi la nécessité pour les utilisateurs de l’exécuter manuellement dans le conteneur.

L’instruction ENTRYPOINT du Dockerfile définit le processus de premier plan du conteneur. Définissez-le sur l’exécutable de votre application :

ENTRYPOINT [« demo-app »]

L’instruction CMD fonctionne en tandem avec ENTRYPOINT. Elle fournit des arguments par défaut pour la commande qui est définie dans l’ENTRYPOINT. Les arguments fournis par l’utilisateur lors du démarrage du conteneur avec docker run remplaceront le CMD défini dans le Dockerfile.

Une bonne utilisation de CMD est lorsque vous souhaitez afficher une aide de base ou des informations sur la version lorsque les utilisateurs omettent une commande spécifique :

ENTRYPOINT [« demo-app »]
CMD [« –version »]

Voici quelques exemples montrant comment ces deux instructions entraînent l’exécution de différentes commandes lors de la création de conteneurs :

Démarrage d’un nouveau conteneur à partir de l’image « demo-app-image:latest ».

Exécute la commande « demo-app –version ».

docker run demo-app-image:latest

Exécute « demo-app demo –foo bar »

docker run demo-app-image:latest demo –foo bar

Aucun de ces exemples ne nécessite que l’utilisateur tape le nom de l’exécutable demo-app. Il est automatiquement utilisé comme processus de premier plan car il s’agit du POINT D’ENTRÉE configuré. La commande reçoit les arguments que l’utilisateur a donnés à docker run après le nom de l’image. Si aucun argument n’est fourni, la version par défaut –version est utilisée.

Ces deux instructions sont les éléments fondamentaux des outils CLI de logement des images Docker. Vous souhaitez que l’exécutable principal de votre application soit le processus de premier plan par défaut afin que les utilisateurs n’aient pas à l’invoquer eux-mêmes.

À lire également : Utiliser Hadolint pour lint vos Dockerfiles

Assemblage

Voici une image Docker qui exécute une application Node.js simple :

!/usr/local/bin/node

console.log(« Hello World ») ;

FROM node:16-alpine
WORKDIR /hello-world

COPY ./ .

RUN npm install

POINT D’ENTRÉE [« hello-world.js »]

La variante alpine de l’image de base de Node est utilisée pour réduire la taille globale de votre image. Le code source de l’application est copié dans le système de fichiers de l’image via l’instruction COPY. Les dépendances npm du projet sont installées et le script hello-world.js est défini comme point d’entrée de l’image.

Construisez l’image à l’aide de docker build :

docker build -t demo-app-image:latest

Maintenant vous pouvez exécuter l’image pour voir Hello World émis dans votre terminal :

docker run demo-app-image:latest

À ce stade, vous êtes prêt à pousser votre image vers Docker Hub ou un autre registre où elle peut être téléchargée par les utilisateurs. Toute personne ayant accès à l’image sera en mesure de démarrer votre logiciel en utilisant uniquement le CLI de Docker.

Gestion des données persistantes

La mise sous Docker d’une application CLI comporte quelques défis. Le plus important d’entre eux est la gestion de la persistance des données. Les données créées dans un conteneur sont perdues lorsque ce conteneur s’arrête, à moins qu’elles ne soient sauvegardées sur un volume Docker externe.

Vous devez écrire les données sur des chemins clairement définis sur lesquels les utilisateurs peuvent monter des volumes. Une bonne pratique consiste à regrouper toutes vos données persistantes dans un seul répertoire, tel que /data. Évitez d’utiliser trop d’emplacements qui nécessitent le montage de plusieurs volumes. Votre guide de démarrage doit documenter les volumes dont votre application a besoin afin que les utilisateurs puissent configurer la persistance lorsqu’ils créent leur conteneur.

Exécuter demo-app avec un volume de données monté sur /data

docker run -v demo-app-data:/data demo-app-image:latest

Pour aller plus loin : Stratégies de déploiements de production automatisés Docker

Autres problèmes possibles

Le problème du montage réapparaît lorsque votre commande doit interagir avec des fichiers sur le système de fichiers de l’hôte. Voici un exemple simple d’un outil de téléchargement de fichiers :

docker run file-uploader cp example.txt demo-server:/example.txt

Cela aboutit à la recherche du fichier example.txt dans le conteneur. Dans cette situation, les utilisateurs devront monter leur répertoire de travail afin que son contenu soit disponible pour le conteneur :

docker run -v $PWD:/file-uploader file-uploader cp example.txt demo-server:/example.txt

Il est également important de réfléchir à la manière dont les utilisateurs fourniront les valeurs de configuration à votre application. Si vous lisez normalement un fichier de configuration, n’oubliez pas que les utilisateurs devront en monter un dans chaque conteneur qu’ils créeront. Offrir des options alternatives telles que des drapeaux de ligne de commande et des variables d’environnement peut simplifier l’expérience pour des cas d’utilisation simples :

Définir la variable d’environnement LOGGING_DRIVER dans le conteneur

docker run -e LOGGING_DRIVER=json demo-app-image:latest

Un autre défi concerne les applications interactives qui nécessitent une saisie de l’utilisateur. Les utilisateurs doivent passer l’indicateur -it à docker run pour activer le mode interactif et allouer un pseudo-TTY :

docker run -it demo-app-image:latest

Les utilisateurs doivent se souvenir de définir ces drapeaux lorsque cela est nécessaire, sinon votre programme ne pourra pas recueillir d’entrée. Vous devez documenter les commandes qui nécessitent un TTY afin que les utilisateurs ne soient pas surpris par des erreurs inattendues.

Ces points de friction signifient que les applications Dockerisées peuvent devenir lourdes si elles ne sont pas spécifiquement conçues pour la conteneurisation. Les utilisateurs bénéficient d’une expérience optimale lorsque vos commandes sont pures, ne nécessitant aucune interaction avec le système de fichiers et une configuration minimale.

Lorsque cela est possible, un simple docker run image-name remplit l’objectif d’une installation et d’une utilisation sans restriction. Vous pouvez toujours conteneuriser des logiciels plus complexes, mais vous dépendez de plus en plus des utilisateurs qui ont une bonne connaissance pratique du Docker CLI et de ses concepts.

Conclusion

Docker n’est pas seulement destiné aux déploiements en nuage et aux services d’arrière-plan. Il est également de plus en plus populaire en tant que mécanisme de distribution pour les applications de console ordinaires. Vous pouvez facilement publier, consommer, exécuter et maintenir des logiciels à l’aide de l’unique CLI Docker que de nombreux praticiens du logiciel utilisent déjà au quotidien.

En proposant une image Docker prête à l’emploi pour votre application, vous offrez plus de choix aux utilisateurs. Les nouveaux venus peuvent démarrer avec une seule commande qui met en place un environnement préconfiguré avec toutes les dépendances.

Il n’y a aucun risque de polluer le système de fichiers ou l’environnement de leur hôte Docker, ce qui permet d’éviter les conflits avec d’autres paquets et garantit la possibilité de faire table rase du passé si nécessaire.

La construction d’une image Docker n’est généralement pas plus compliquée que les routines que vous utilisez déjà pour soumettre des constructions à différents gestionnaires de paquets de systèmes d’exploitation.

Les considérations les plus importantes sont de garder votre image aussi petite que possible et de vous assurer que le point d’entrée et la commande sont appropriés pour votre application. Les utilisateurs bénéficieront ainsi de la meilleure expérience possible lors de l’utilisation de votre logiciel Dockerisé.