Comment créer une image Docker à l’aide d’un Dockerfile

Les compétences Docker sont très demandées, principalement parce que, grâce au Docker, nous pouvons automatiser le déploiement d’applications à l’intérieur de ce que l’on appelle des conteneurs, en créant des environnements sur mesure qui peuvent être facilement répliqués partout où la technologie Docker est prise en charge. Dans ce tutoriel, nous allons voir comment créer une image Docker à partir de zéro, à l’aide d’un Dockerfile. Nous allons apprendre les instructions les plus importantes que nous pouvons utiliser pour personnaliser notre image, comment construire l’image et comment exécuter des conteneurs basés sur celle-ci.

Dans ce tutoriel, vous allez apprendre :

• Comment créer une image Docker à l’aide d’un Dockerfile
• Certaines des instructions Dockerfile les plus fréquemment utilisées
• Comment obtenir la persistance des données dans les conteneurs

De nombreux conteneurs peuvent être créés à partir de la même image. Dans la suite de cet article, nous allons apprendre comment fournir les instructions nécessaires pour créer une image adaptée à nos besoins à l’intérieur d’un Dockerfile, comment construire l’image et comment exécuter un conteneur basé sur celle-ci.

Construire notre propre image à l’aide d’un Dockerfile

Pour construire notre propre image, nous utiliserons un Dockerfile. Un Dockerfile contient toutes les instructions nécessaires à la création et à la configuration d’une image. Une fois que notre Dockerfile est prêt, nous utiliserons la commande docker build pour construire l’image.

La première chose à faire est de créer un nouveau répertoire pour héberger notre projet. Pour les besoins de ce tutoriel, nous allons construire une image contenant le serveur web Apache, nous allons donc nommer le répertoire racine du projet « dockerized-apache » :

mkdir dockerized-apache

Ce répertoire est ce que nous appelons le contexte de construction. Pendant le processus de construction, tous les fichiers et répertoires qu’il contient, y compris le Dockerfile que nous allons créer, sont envoyés au démon Docker afin qu’ils soient facilement accessibles, à moins qu’ils ne soient répertoriés dans le fichier .dockerignore.

Créons notre Dockerfile. Le fichier doit s’appeler Dockerfile et contiendra, comme nous l’avons dit plus haut, toutes les instructions nécessaires à la création d’une image avec les fonctionnalités souhaitées. Nous lançons notre éditeur de texte préféré et commençons par écrire les instructions suivantes :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

La première instruction que nous devons fournir est FROM : avec elle, nous pouvons spécifier une image existante que nous utiliserons comme base (c’est ce qu’on appelle une image de base), pour créer la nôtre. Dans ce cas, notre image de base sera ubuntu. Outre le nom de l’image, nous avons également utilisé une balise, afin de spécifier la version de l’image que nous voulons utiliser, dans ce cas 18.10. Si aucune balise n’est spécifiée, la dernière balise est utilisée par défaut : cela entraînera l’utilisation de la dernière version disponible de l’image de base. Si l’image n’est pas déjà présente sur notre système, elle sera téléchargée depuis dockerhub.

Après l’instruction FROM, nous avons utilisé LABEL. Cette instruction est facultative, peut être répétée plusieurs fois et est utilisée pour ajouter des métadonnées à notre image. Dans ce cas, nous l’avons utilisé pour spécifier le mainteneur d’image.

L’instruction RUN

À ce stade, si nous exécutons docker build, nous ne produirons qu’une image identique à celle de base, à l’exception des métadonnées que nous avons ajoutées. Cela ne nous serait d’aucune utilité. Nous avons dit que nous voulions « dockeriser » le serveur web Apache, donc la prochaine chose à faire dans notre Dockerfile, c’est de fournir une instruction pour installer le serveur web dans le cadre de l’image. L’instruction qui nous permet d’accomplir cette tâche est EXÉCUTER :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2

L’instruction RUN est utilisée pour exécuter des commandes au-dessus de l’image. Une chose très importante à retenir est que pour chaque instruction RUN que nous utilisons, une nouvelle couche est créée et ajoutée à la pile. Sur ce point Docker est très intelligent : les couches déjà construites seront « mises en cache » : cela signifie que si nous construisons une image basée sur notre Dockerfile, et que nous décidons ensuite, par exemple, d’ajouter une autre instruction RUN (et donc une nouvelle couche) à la fin de celle-ci, le build ne partira pas de zéro, mais exécutera uniquement les nouvelles instructions.

Pour que cela se produise, bien sûr, les instructions déjà construites sur le Dockerfile ne doivent pas être modifiées. Il est même possible d’éviter complètement ce comportement lors de la construction d’une image, en utilisant simplement l’option --no-cache de la commande docker build.

Dans notre cas, nous avons utilisé l’instruction RUN pour exécuter les commandes apache2 apt-get update & apt-get -y install. Remarquez comment nous avons passé l’option -y à la commande apt-get install : cette option fait en sorte qu’une réponse affirmative est donnée automatiquement à toutes les confirmations requises par la commande. Ceci est nécessaire car nous installons le paquet de manière non interactive.

Exposition du port 80

Comme nous le savons, le serveur web Apache écoute sur le port 80 pour les connexions standard. Nous devons demander à Docker de rendre ce port accessible sur le conteneur. Pour accomplir cette tâche, nous utilisons la fonction EXPOSE et fournissons le numéro de port. Pour des raisons de sécurité, le port spécifié n’est ouvert qu’au moment du lancement du conteneur. Ajoutons cette instruction à notre Dockerfile :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

Construire l’image

À ce stade, nous pouvons déjà essayer de construire notre image. Depuis le répertoire racine de notre projet, « dockerized-apache », nous exécutons la commande suivante :

sudo docker build -t linuxconfig/dockerized-apache .

Examinons la commande. Tout d’abord, nous avons préfixé la commande avec sudo, afin de l’exécuter avec des privilèges administratifs. Il est possible d’éviter cela, en ajoutant un utilisateur au groupe docker, mais cela représente un risque de sécurité. L’option -t que nous avons fournie, abréviation de --tag, nous permet d’appliquer un nom de dépôt et éventuellement une balise à notre image si la compilation réussit.

Enfin, le . indique à docker de rechercher le fichier Dockerfile dans le répertoire courant. Dès que nous lançons la commande, le processus de construction commence. Les messages de progression et de build s’afficheront à l’écran :

Sending build context to Docker daemon 2.048
kB
Step 1/4 : FROM ubuntu:18.10
Trying to pull repository docker.io/library/ubuntu ...
[...]

En quelques minutes, notre image devrait être créée avec succès. Pour le vérifier, nous pouvons exécuter la commande docker images, qui renvoie une liste de toutes les images existantes dans notre dépôt Docker local :

sudo docker images
REPOSITORY                        TAG                 IMAGE ID
CREATED             SIZE
linuxconfig/dockerized-apache     latest              7ab7b6873614        2
minutes ago       191 MB

Comme prévu, l’image apparaît dans la liste. Comme nous pouvons le remarquer, puisque nous n’avons pas fourni de balise (seulement un nom de dépôt, linuxconfig/dockerized-apache), la dernière balise a été automatiquement appliquée à notre image. Un ID a également été attribué à l’image, 7ab7b6873614 : nous pouvons l’utiliser pour référencer l’image dans les commandes futures.

Lancement d’un conteneur basé sur l’image

Maintenant que notre image est prête, nous pouvons créer et lancer un conteneur basé sur celle-ci. Pour accomplir cette tâche, nous utilisons la commande docker run :

sudo docker run --name=linuxconfig-apache -d -p 8080:80
linuxconfig/dockerized-apache apachectl -D FOREGROUND

Examinons la commande ci-dessus. La première option que nous avons fournie était --name : avec elle, nous spécifions un nom pour le conteneur, dans ce cas « linuxconfig-apache ». Si nous avions omis cette option, un nom généré aléatoirement aurait été attribué à notre conteneur.

L’option -d (abréviation de --detach) fait fonctionner le conteneur en arrière-plan.

L’option -p, abréviation de --publish, est nécessaire pour publier un port de conteneur (ou une plage de ports) sur le système hôte. La syntaxe de l’option est la suivante :

-p localhost_port:container_port

Dans ce cas, nous avons publié le port 80 que nous avons précédemment exposé dans le conteneur, sur le port hôte 8080. Par souci d’exhaustivité, nous devons dire qu’il est également possible d’utiliser l’option -P (abréviation de --publish-all) à la place, ce qui fait que tous les ports exposés dans le conteneur sont mappés à des ports aléatoires sur l’hôte.

Les deux dernières choses que nous avons spécifiées dans la commande ci-dessus sont : l’image sur laquelle le conteneur doit être basé, et la commande à exécuter lorsque le conteneur est démarré, ce qui est facultatif. L’image est bien sûr linuxconfig/dockerized-apache, celle que nous built before.

La commande que nous avons spécifiée est apachectl -D FOREGROUND. Avec cette commande, le serveur web Apache est lancé en mode premier plan : c’est obligatoire pour qu’il fonctionne dans le conteneur. La commande docker run exécute la commande spécifiée sur un nouveau conteneur :

sudo docker run --name=linuxconfig-apache -d
-p 8080:80 linuxconfig/dockerized-apache apachectl -D FOREGROUND
a51fc9a6dd66b02117f00235a341003a9bf0ffd53f90a040bc1122cbbc453423

Quel est le numéro imprimé à l’écran ? Il s’agit de l’ID du contenant ! Une fois que le conteneur est opérationnel, nous devrions pouvoir accéder à la page servie par l’Apache VirtualHost par défaut à l’adresse localhost :8080 (le port 8080 sur l’hôte est mappé sur le port 80 sur le conteneur) :

Page de index.html Apache par défaut

Notre configuration fonctionne correctement. Si nous exécutons la commande docker ps, qui répertorie tous les conteneurs actifs dans le système, nous pouvons récupérer des informations sur notre conteneur : id (version courte, plus facile à référencer à partir de la ligne de commande pour un humain), l’image à partir de laquelle il a été exécuté, la commande utilisée, son heure de création et son état actuel, mappage des ports et nom.

sudo docker ps
CONTAINER ID        IMAGE                           COMMAND
CREATED             STATUS              PORTS                  NAMES
a51fc9a6dd66        linuxconfig/dockerized-apache   "apachectl -D FORE..."   28
seconds ago      Up 28 seconds       0.0.0.0:8080->80/tcp
linuxconfig-apache

Pour arrêter le conteneur, tout ce que nous avons à faire est de le référencer par son identifiant ou son nom, et d’exécuter la commande docker stop. Par exemple:

sudo docker stop linuxconfig-apache

Pour le redémarrer :

sudo docker start linuxconfig-apache

Exécuter la commande directement via le Dockerfile

Comme ici nous avons construit une image de base, et au moment de l’exécution, en utilisant la commande docker run, nous avons spécifié la commande à lancer lorsque le conteneur est démarré. Parfois, nous voulons spécifier ce dernier directement dans le Dockerfile. Nous pouvons le faire de deux manières : en utilisant CMD ou ENTRYPOINT.

Les deux instructions peuvent être utilisées dans le même but, mais elles se comportent différemment lorsqu’une commande est également spécifiée à partir de la ligne de commande. Voyons comment.

L’instruction CMD

L’instruction CMD peut essentiellement être utilisée sous deux formes. Le premier est le formulaire exécutif :

CMD ["/usr/sbin/apachectl", "-D", "FOREGROUND"]

L’autre est la forme coquille :

CMD /usr/sbin/apachectl -D FOREGROUND

L’exec de est généralement préféré. Il convient de noter que lors de l’utilisation du formulaire exec, un shell n’est pas invoqué, donc les expansions de variables ne se produiront pas. Si l’expansion de la variable est nécessaire, nous pouvons utiliser la forme du shell ou nous pouvons invoquer un shell directement dans le mode exec, comme :

CMD ["sh", "-c", "echo", "$HOME"]

L’instruction CMD ne peut être spécifiée qu’une seule fois dans le Dockerfile. Si plusieurs options CMD sont fournies, seule la dernière prendra effet. Le but de l’instruction est de fournir une commande par défaut à lancer au démarrage du conteneur :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

CMD ["/usr/sbin/apachectl", "-D", "FOREGROUND"]

La commande spécifiée avec CMD à l’intérieur du Dockerfile fonctionne par défaut et sera remplacée si une autre commande est spécifiée à partir de la ligne de commande lors de l’exécution de docker run.

L’instruction ENTRYPOINT

L’instruction ENTRYPOINT peut également être utilisée pour configurer une commande à utiliser lorsque le conteneur est démarré et, comme CMD, le formulaire exec et le formulaire shell peuvent être utilisés avec elle. La grande différence entre les deux est qu’une commande passée à partir de la ligne de commande ne remplacera pas celle spécifiée avec ENTRYPOINT : au lieu de cela, elle y sera ajoutée.

En utilisant cette instruction, nous pouvons spécifier une commande de base et la modifier avec les options que nous fournissons lors de l’exécution de la commande docker-run, ce qui fait que notre conteneur se comporte comme un exécutable. Voyons un exemple avec notre Dockerfile :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

ENTRYPOINT ["/usr/sbin/apachectl"]

Dans ce cas, nous avons remplacé l’instruction CMD par ENTRYPOINT et avons également supprimé l’option -D FOREGROUND du format exec. Supposons que nous reconstruisions maintenant l’image et que nous recréions le conteneur à l’aide de la commande suivante :

sudo docker run --name=linuxconfig-apache -d -p 8080:80
linuxconfig/dockerized-apache -D FOREGROUND

Lorsque le conteneur démarre, les arguments -D FOREGROUND sont ajoutés à la commande fournie dans le Dockerfile avec l’instruction ENTRYPOINT, mais uniquement si vous utilisez le formulaire exec. Cela peut être vérifié en exécutant la commande docker ps (ici, nous avons ajouté quelques options à la commande, pour mieux afficher et formater sa sortie, en sélectionnant uniquement les informations dont nous avons besoin) :

sudo docker ps --no-trunc --format
"{{.Names}}\t{{.Command }}"
linuxconfig-apache	"/usr/sbin/apachectl -D FOREGROUND"

Tout comme CMD, l’instruction ENTRYPOINT ne peut être fournie qu’une seule fois. S’il apparaît plusieurs fois dans le Dockerfile, seule la dernière occurrence sera prise en compte. Il est possible de remplacer le ENTRYPOINT par défaut de l’image à partir de la ligne de commande, en utilisant l’option --entrypoint de la commande docker run.

Combinaison de CMD et d’ENTRYPOINT

Maintenant que nous connaissons la particularité des instructions CMD et ENTRYPOINT, nous pouvons également les combiner. Que pouvons-nous obtenir en faisant cela ? Nous pouvons utiliser ENTRYPOINT pour spécifier une commande de base valide, et l’instruction CMD pour spécifier les paramètres par défaut de celle-ci.

La commande s’exécutera avec ces paramètres par défaut par défaut, à moins que nous ne les remplacions à partir de la ligne de commande lors de l’exécution de docker run. En nous en tenant à notre Dockerfile, nous pourrions écrire :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

ENTRYPOINT ["/usr/sbin/apachectl"]
CMD ["-D", "FOREGROUND"]

Si nous reconstruisons l’image à partir de ce Dockerfile, supprimons le conteneur précédent que nous avons créé et relançons la commande docker run sans spécifier d’argument supplémentaire, la commande /usr/bin/apachectl -D FOREGROUND sera exécutée. Si nous fournissons à la place des arguments, ils remplaceront ceux spécifiés dans le Dockerfile avec l’instruction CMD. Par exemple, si nous exécutons :

sudo docker run --name=linuxconfig-apache -d -p 8080:80
linuxconfig/dockerized-apache -X

La commande qui sera exécutée au démarrage du conteneur sera /usr/bin/apachectl -X. Vérifions-le :

sudo docker ps --no-trunc --format
"{{.Names}}\t{{.Command }}"
linuxconfig-apache	"/usr/sbin/apachectl -X"

La commande lancée, était comme prévu : l’option -X, soit dit en passant, fait en sorte que le démon httpd soit lancé en mode debug.

Copie de fichiers dans le conteneur

Notre serveur Apache « dockerisé » fonctionne. Comme nous l’avons vu, si nous naviguons vers localhost :8080, nous visualisons la page d’accueil Apache par défaut. Maintenant, disons que nous avons un site Web prêt à être livré avec le conteneur, comment pouvons-nous le « charger » pour qu’Apache le serve à la place ?

Eh bien, pour les besoins de ce tutoriel, nous allons simplement remplacer le fichier index.html par défaut. Pour accomplir cette tâche, nous pouvons utiliser l’instruction COPY. Supposons que nous ayons un fichier index.html alternatif à l’intérieur de la racine de notre projet (notre contexte de construction) avec ce contenu :

<html>
  <body>
    <h2>Hello!</h2>
    <h3>This file has been copied into the container with the COPY instruction!</h3>
  </body>
</html>

Nous voulons le charger et le copier dans le répertoire /var/www/html à l’intérieur du conteneur, donc à l’intérieur de notre Dockerfile, nous ajoutons l’instruction COPY :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

ENTRYPOINT ["/usr/sbin/apachectl"]
CMD ["-D", "FOREGROUND"]
COPY index.html /var/www/html/index.html

Nous reconstruisons l’image et le contenant. Si vous naviguez maintenant vers localhost :8080, nous verrons le nouveau message :

new message

L’instruction COPY peut être utilisée pour copier à la fois des fichiers et des répertoires. Lorsque le chemin de destination n’existe pas, il est créé à l’intérieur du conteneur. Tous les nouveaux fichiers et répertoires sont créés avec un UID et un GID de 0.

Une autre solution possible pour copier des fichiers à l’intérieur du conteneur est d’utiliser l’instruction ADD, qui est plus puissante que COPY. Avec cette instruction, nous pouvons copier des fichiers, des répertoires mais aussi des URL. De plus, si nous copions une archive tar locale avec un format compressé reconnu, elle sera automatiquement décompressée et copiée en tant que répertoire à l’intérieur du conteneur.

La stratégie idéale serait d’utiliser COPY à moins que les fonctionnalités supplémentaires fournies par ADD ne soient vraiment nécessaires.

Création d’un VOLUME

Dans l’exemple précédent, pour montrer le fonctionnement de l’instruction COPY, nous avons remplacé le fichier index.html par défaut de l’Apache VirtualHost par défaut à l’intérieur du conteneur.

Si nous arrêtons et redémarrons le conteneur, nous retrouverons toujours la modification que nous avons apportée, mais si le conteneur pour une raison quelconque est supprimé, toutes les données contenues sur sa couche inscriptible seront perdues avec lui. Comment résoudre ce problème ? Une approche consiste à utiliser l’instruction VOLUME :

FROM ubuntu:18.10
LABEL maintainer="egidio.docile@linuxconfig.org"

RUN apt-get update && apt-get -y install apache2
EXPOSE 80

ENTRYPOINT ["/usr/sbin/apachectl"]
CMD ["-D", "FOREGROUND"]
COPY index.html /var/www/html/index.html
VOLUME /var/www/html

L’instruction VOLUME prend un ou plusieurs répertoires (dans ce cas, /var/www/html) et les fait utiliser comme points de montage pour des volumes externes, nommés de manière aléatoire, générés lors de la création du conteneur.

De cette façon, les données que nous mettons dans les répertoires utilisés comme points de montage seront conservées à l’intérieur des volumes montés et existeront toujours même si le conteneur est détruit. Si un répertoire destiné à être utilisé comme point de montage contient déjà des données au moment de l’initialisation, ces données sont copiées à l’intérieur du volume qui y est monté.

Reconstruisons l’image et le conteneur. Nous pouvons maintenant vérifier que le volume a été créé et qu’il est en cours d’utilisation en inspectant le conteneur :

sudo docker inspect linuxconfig-apache
[...]
"Mounts": [
            {
                "Type": "volume",
                "Name": "8f24f75459c24c491b2a5e53265842068d7c44bf1b0ef54f98b85ad08e673e61",
                "Source": "/var/lib/docker/volumes/8f24f75459c24c491b2a5e53265842068d7c44bf1b0ef54f98b85ad08e673e61/_data",
                "Destination": "/var/www/html",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],
[...]

Comme nous l’avons déjà dit, le volume survivra même après la destruction du conteneur, de sorte que nos données ne seront pas perdues.

L’instruction VOLUME à l’intérieur du Dockefile, comme nous pouvons le voir dans la sortie de la commande docker inspect ci-dessus, permet de créer un volume nommé de manière aléatoire. Pour définir un volume nommé, ou pour monter un volume déjà existant à l’intérieur d’un conteneur, nous devons le spécifier au moment de l’exécution, lors de l’exécution de la commande docker run, en utilisant l’option -v (abréviation de --volume). Voyons un exemple :

sudo docker run --name=linuxconfig-apache -d -p 8080:80 -v
myvolume:/var/www/html linuxconfig/dockerized-apache

Dans la commande ci-dessus, nous avons utilisé l’option -v en spécifiant le nom du volume (très important : notez qu’il ne s’agit pas d’un chemin, mais d’un simple nom) et le point de montage à l’intérieur du conteneur en utilisant la syntaxe suivante :

<volume_name>:<mountpoint>

Lorsque nous exécutons une telle commande, le volume nommé « myvolume » sera monté sur le chemin spécifique à l’intérieur du conteneur (le volume sera créé s’il n’existe pas déjà). Comme nous l’avons dit précédemment, si le volume est vide, les données déjà existantes sur le point de montage à l’intérieur du conteneur seront copiées à l’intérieur de celui-ci. À l’aide de la commande docker volume ls, nous pouvons confirmer qu’un volume portant le nom que nous avons spécifié a été créé :

sudo docker volume ls
DRIVER              VOLUME NAME
local               myvolume

Pour supprimer un volume, nous utilisons la commande docker volume rm et fournissons le nom du volume à supprimer. Docker, cependant, ne nous permettra pas de supprimer un volume utilisé par un conteneur actif :

sudo docker volume rm myvolume
Error response from daemon: Unable to remove volume, volume still in use: remove
myvolume: volume is in use -
[95381b7b6003f6165dfe2e1912d2f827f7167ac26e22cf26c1bcab704a2d7e02]

Une autre approche de la persistance des données, particulièrement utile pendant le développement, consiste à lier et à monter un répertoire hôte à l’intérieur du conteneur. Cette approche a l’avantage de nous permettre de travailler sur notre code localement avec nos outils préférés et de voir l’effet des modifications immédiatement répercutées à l’intérieur du conteneur, mais présente un gros inconvénient : le conteneur devient dépendant de la structure du répertoire hôte.

Pour cette raison, puisque la portabilité est l’un des principaux objectifs de Docker, il n’est pas possible de définir un bind-mount à l’intérieur d’un Dockerfile, mais seulement au moment de l’exécution. Pour accomplir cette tâche, nous utilisons à nouveau l’option -v de la commande docker run, mais cette fois-ci, nous fournissons le chemin d’accès d’un répertoire à l’intérieur du système de fichiers hôte au lieu d’un nom de volume :

sudo docker run --name=linuxconfig-apache -d -p 8080:80 -v
/path/on/host:/var/www/html linuxconfig/dockerized-apache

Lors du lancement de la commande ci-dessus, le répertoire hôte /path/on/host sera monté sur /var/www/html à l’intérieur du conteneur. Si le répertoire sur l’hôte n’existe pas, il est créé automatiquement. Dans ce cas, les données du répertoire mountpoint à l’intérieur du conteneur (/var/www/html dans notre exemple) ne sont pas copiées dans le répertoire hôte qui y est monté, comme c’est le cas pour les volumes.

Conclusion

Dans ce tutoriel, nous avons appris les concepts de base nécessaires pour créer et construire une image Docker à l’aide d’un fichier Dockerfile et comment exécuter un conteneur basé sur celui-ci. Nous avons construit une image très simple qui nous a permis d’exécuter une version « dockerisée » du serveur web Apache. Dans la foulée, nous avons vu comment utiliser l’instruction FROM, qui est obligatoire pour spécifier une image de base sur laquelle travailler, l’instruction LABEL pour ajouter des métadonnées à notre image, l’instruction EXPOSE pour déclarer les ports à exposer dans le conteneur. Nous avons également appris à mapper ce ou ces ports au(x) port(s) au(x) port(s) du système hôte.

Nous avons appris à utiliser l’instruction RUN
pour exécuter des commandes sur l’image, et nous avons appris à spécifier une commande à exécuter lorsque le conteneur est démarré à la fois à partir de la ligne de commande et à l’intérieur du Dockerfile. Nous avons vu comment y parvenir en utilisant les instructions CMD et ENTRYPOINT, et quelles sont les différences entre les deux. Enfin, nous avons vu comment copier des données à l’intérieur du conteneur et comment obtenir la persistance des données à l’aide de volumes. Dans nos exemples, nous n’avons abordé qu’un petit sous-ensemble des instructions qui peuvent être utilisées dans un Dockerfile.

Pour une liste complète et détaillée, veuillez consulter la documentation officielle de Docker. En attendant, si vous voulez savoir comment construire une pile LAMP entière à l’aide de Docker et de l’outil docker-compose, vous pouvez jeter un coup d’œil à notre article sur Comment créer une pile LAMP basée sur docker à l’aide de docker-compose sur Ubuntu 18.04 Bionic Beaver Linux.