Comment utiliser Docker Commit pour modifier les images de conteneur

Une caractéristique des conteneurs Docker est l'immuabilité. A tout moment, vous pouvez détruire et recréer des conteneurs pour rétablir l'état initial. Utilisation du docker commit , vous pouvez appliquer de nouvelles modifications à une image de conteneur, mais ce n'est pas aussi simple que prévu.

Explorons comment valider les modifications apportées à une nouvelle image de conteneur avec le docker commit commande !

Quand valider les modifications apportées à une nouvelle image de conteneur

Les conteneurs sont conçus pour être immuables (non modifiés), alors pourquoi voudriez-vous valider les modifications apportées à un conteneur ? Il y a plusieurs raisons.

Lors du développement d'un nouveau service conteneurisé pour tester rapidement les modifications.
Corrigez rapidement les bogues d'un service de production sans avoir à corriger l'image source au préalable.
Utilisez commit pour prendre un instantané d'une image et exporter l'image vers un nouveau serveur.

Bien que ceux-ci ne couvrent pas tous les scénarios potentiels, ce sont quelques-uns qui rendent l'utilisation de docker commit un cas d'utilisation parfait.

Valider les modifications d'une image simple

Pour une commande apparemment simple, cette commande fait beaucoup.

Ci-dessous un exemple simple commit commande. À l'aide d'un ID de conteneur en cours d'exécution, d3fdd3517e0a dans cet exemple, une nouvelle image est créée dans un référentiel appelé myrepository et nommé changedimage .

L'image d'origine est étiquetée comme version2 , ce qui n'est pas nécessaire, mais utile pour suivre les modifications entre des images portant le même nom.

Les deux myrepository et changedimage sont choisis arbitrairement, mais ceux-ci reflètent généralement des ressources correctement étiquetées telles que customimages/alpine-linux .

docker commit d3fdd3517e0a myrepository/changedimage:version2

Les conteneurs Docker sont une série d'images en lecture seule avec une couche en lecture-écriture au-dessus. Dans l'exemple ci-dessus, Docker suspend le conteneur en cours d'exécution. Cette pause permet d'éviter la corruption accidentelle des données pendant que Docker crée l'image

Étant donné que cette pause pourrait entraîner des interruptions de service, vous pouvez utiliser --pause=false . Cela pourrait corrompre les données, car les écritures pourraient ne pas être terminées avec succès.

De plus, le commit l'opération omet les données contenues dans les volumes montés dans le conteneur. Étant donné que les volumes ne font pas partie du système de fichiers lui-même du conteneur, Docker les ignore.

Une fois l'opération de validation terminée, Docker crée alors un nouveau calque avec les modifications de l'image d'origine sous le nouveau nom d'image de conteneur.

Prérequis

Le seul prérequis de ce tutoriel est Docker lui-même. Cela peut être installé via le logiciel Docker Desktop sous Windows ou installé via un package sous Linux.

Connexe :Déploiement de votre premier conteneur Docker sous Windows

Commiting Changes to a New Docker Container Image

Examinons maintenant quelques scénarios courants que le docker commit commande peut être utile pour.

Commencez par dérouler une image de conteneur Alpine Linux à partir du référentiel Docker public. Alpine est connu pour ses conteneurs minces, comme indiqué par la taille d'environ 5 Mo.

# Pull the latest Alpine Linux image
docker pull alpine
# List all Docker images
docker images

Développement et test de conteneurs

Le principal cas d'utilisation de docker commit est le développement d'une nouvelle image de conteneur. Cette image peut finalement être utilisée comme base pour d'autres images, ou comme conteneur de production lui-même.

Dans l'extrait d'exemple ci-dessous, Docker est :

Exécution de l'alpine extrait précédemment photo
Ouverture d'un shell interactif pour installer un package
Installation du paquet htop

# Open an interactive shell to the Docker Alpine Linux container
docker run -it a24bb4013296 bin/sh
# Install the HTOP package
apk add htop

Vous pouvez voir ci-dessous que le package est correctement installé dans le conteneur en exécutant le htop commande.

Une fois que vous avez installé le package sur le nouveau "calque", vous devez maintenant valider cette modification sur l'image de base d'origine. Pour ce faire :

Exécutez docker ps -a pour localiser l'ID du conteneur.
À l'aide de l'ID de conteneur, validez le contenu du calque actuel dans une nouvelle image de base.

Dans l'exemple ci-dessous, la nouvelle image est nommée alpine-htop et marqué version1 . L'image est étiquetée pour faciliter le suivi des versions d'image Docker portant le même nom.

# List all Docker containers regardless of status, -a or --all to show every container
docker ps -a
# Commit the layer to a new image named alpine-htop and tagged version1
docker commit b57e066d5bfa alpine-htop:version1
# List all images available
docker images

Correction de bogues dans les images de production

Souvent, vous pouvez avoir un service de production qui a une erreur. Il peut y avoir un correctif connu et vous pouvez appliquer un correctif plus rapidement que de modifier les configurations existantes et de les redéployer. Utilisation de docker commit , vous pouvez rapidement appliquer le correctif, puis travailler en arrière-plan pour mettre à jour les autres composants nécessaires.

Cet exemple d'extrait ci-dessous illustre l'installation de NGINX dans une image Alpine Linux Docker.

# First List the available images
docker images
# Run an interactive session for the alpine-htop image
docker run -it a24bb4013296 bin/sh
# Install the NGINX package
apk add nginx
# Create the location for the NGINX PID file
mkdir /run/nginx
# Verify that NGINX is installed
nginx -v
# Run NGINX
/usr/sbin/nginx
# Verify that NGINX is properly running
ps | grep nginx
# Kill the NGINX process
kill 18
# Verify that the NGINX process is no longer active
ps | grep nginx

Validez le nouveau conteneur NGINX créé ci-dessus dans une nouvelle image nommée alpine-nginx et avec la balise version1 . Le balisage de l'image est une bonne pratique, pour aider à différencier les différentes versions de la même image.

# List all Docker containers regardless of status, -a or --all to show every container
docker ps -a
# Commit the changes to a new image named alpine-nginx
docker commit 37043139525c alpine-nginx:version1
# Verify that the new image was created
docker images

Tous les exécutables ne pourront pas être exécutés en arrière-plan, et NGINX n'est pas différent. Pour exécuter correctement ce conteneur, avec NGINX exécuté en arrière-plan, transmettez le -g 'daemon off;' option vers NGINX.

# Run the NGINX container in the background
docker run -d f6b46a3b76be /usr/sbin/nginx -g 'daemon off;'
# Verify that the container is running
docker ps -a

Enfin, utilisez le --change switch pour exposer le port 80. En utilisant le --change paramètre, le EXPOSE 80 La commande sera écrite dans le DockerFile du conteneur. Une fois cette modification effectuée, démarrez le nouveau conteneur. Une fois le nouveau conteneur démarré, arrêtez le conteneur précédent qui a été exécuté de manière incorrecte sans le port exposé. Cela aidera à faire la transition en douceur du conteneur non fonctionnel vers le conteneur fonctionnel.

# List all running containers
docker ps -a
# Commit the changes to a new image with an exposed port 80
docker commit --change "EXPOSE 80" c649c813d985 alpine-nginx:version2
# List the running containres
docker ps -a
# List all Docker images
docker images
# Run the newly created image
docker run -d c71f0f9cef7b /usr/sbin/nginx -g 'daemon off;'
# List running containers
docker ps -a
# Stop the prior container without the exposed port 80
docker stop c649c813d985
# List running containers
docker ps -a

Instantané d'une image Docker

Enfin, qu'en est-il d'un scénario dans lequel vous pourriez avoir besoin d'un instantané, une image ponctuelle, d'un conteneur en cours d'exécution pour déplacer le conteneur vers un nouveau serveur ? Le docker commit La commande fonctionne bien pour cela, comme vous pouvez le voir ci-dessous.

Les commandes ci-dessous créent un conteneur en cours d'exécution que nous allons arrêter et valider dans un nouveau alpine-nginx version.

# List running Docker containers
docker ps -a
# Create a new running Docker NGINX container
docker run -d c71f0f9cef7b
# List running Docker containers
docker ps -a
# Stop the Docker container
docker stop 7ff99f2bcf6b
# Create a new alpine-nginx version to export
docker commit 7ff99f2bcf6b alpine-nginx:version3
# List the Docker images available
docker images

Exportez l'image Docker dans un fichier. Dans cet exemple, le fichier d'exportation est nommé export.tar , mais nommez le fichier en fonction de vos besoins. Enfin, importez le export.tar fichier dans Docker, démontrant le processus de bout en bout.

Assurez-vous d'exporter en utilisant le format repo:tag si vous souhaitez que ces étiquettes soient conservées lors de la réimportation de l'image.

# Save the image to a file on the local disk
docker save -o export.tar alpine-nginx:version3
# Verify that the image exists
ls
# Remove the just exported Docker image
docker rmi 39ca9e64828a
# List Docker images and verify that the image is removed
docker images
# Load the Docker image back in
docker load -i export.tar
# List Docker images and show that the image has been loaded back in
docker images

Options supplémentaires pour la commande Docker Commit

Tirer parti des options supplémentaires disponibles pour le commit commande, de nombreux scénarios différents sont pris en charge.

Mise en pause du conteneur

Pour ne pas suspendre le conteneur pendant son exécution, vous pouvez transmettre le --pause=false commande pour désactiver la fonction de pause. Ceci est souvent utilisé lors de la sauvegarde d'un service de production et que la suspension de ce service serait préjudiciable.

La commande pause a également un raccourci de -p qui peut être plus rapide à utiliser. Sachez cependant qu'en contournant la mise en pause du conteneur, vous risquez de corrompre les données en cas d'écriture sur le système de fichiers, ce qui pourrait entraîner l'écriture de données incomplètes ou corrompues.

Laisser un message de validation

De nombreux développeurs connaissent bien le fait de fournir un bon message de validation. Tout comme pour l'utilisation du contrôle de code source, vous souhaitez idéalement envoyer un message utile expliquant pourquoi une nouvelle version du conteneur a été validée.

Cela peut être fait en utilisant le --message="message to commit" commande. Comme précédemment, il existe une version abrégée de cette commande, -m . Pour voir la liste des messages de commit Docker, utilisez l'docker history commande.

Définir l'auteur

Pour indiquer correctement qui crée la modification, vous pouvez fournir une valeur d'auteur qui donnera un contexte supplémentaire à la personne qui effectue la modification. Ceci peut être utilisé via le --author="Jane Author ([email protected])" . Cette commande peut également être utilisée via le raccourci -a . Utilisation de docker inspect vous pourrez récupérer une liste JSON d'informations sur le conteneur, y compris des étiquettes telles que l'auteur.

Appliquer les modifications DockerFile en parallèle

Enfin, la commande la plus compliquée pouvant être utilisée dans le docker commit la commande est le change paramètre. Ce paramètre applique les modifications du conteneur au DockerFile en même temps que le commit.

Vous pouvez utiliser le change paramètre en passant des instructions au Dockerfile comme ceci, --change="ENV TEST true" . Cette commande place le texte, ENV TEST true dans le DockerFile. Désormais, lorsque le conteneur redémarrera, les modifications que vous désignez ici seront déjà appliquées.

Au lieu du --change nom, vous pouvez prendre un raccourci et utiliser le -c alias.

Avec cette commande, vous pouvez également enchaîner plusieurs --change paramètres ensemble. Cela vous permet d'ajouter facilement plusieurs modifications à un DockerFile en une seule commande de validation.

Modifier les options de paramètres

Vous ne pouvez utiliser que quelques commandes avec le change paramètre comme indiqué ci-dessous.

CMD – L'instruction CMD prend la forme CMD ["executable","parameter1","parameter2"] . C'est la méthode préférée, mais gardez à l'esprit qu'un seul CMD peut exister dans un DockerFile à la fois. Le dernier CMD sera celle qui prendra effet. L'objectif principal de CMD est de fournir des commandes d'exécution par défaut pour un conteneur lors de sa création.
ENTRYPOINT – Semblable à la commande CMD, ENTRYPOINT utilise la syntaxe de ENTRYPOINT ["executable","parameter1","parameter2"] . Cette syntaxe soulève la question de savoir pourquoi utiliser ENTRYPOINT plutôt que CMD ?

La commande ENTRYPOINT exécute un exécutable en tant que processus principal de PID 1 . Cette action vous permet ensuite d'arrêter le processus à l'aide de docker stop gracieusement. De plus, vous pouvez utiliser CMD avec ceci en omettant le executable partie qui transmet ces paramètres dans le ENTRYPOINT exécutable.
ENV – Étant donné que la plupart des applications consomment des variables d'environnement, la commande ENV vous permet de les définir simplement dans le format clé-valeur de ENV key=value . Accédez à ces variables clé=valeur en tant que variables d'environnement Linux standard.
EXPOSE – La commande EXPOSE expose un port et un protocole facultatif en dehors du conteneur. Cette commande mappe les ports du conteneur vers l'extérieur du conteneur et permet aux conteneurs d'interagir avec des ressources externes telles qu'un serveur Web diffusant du contenu.
LABEL – La commande LABEL ajoute des métadonnées à un conteneur. Vous pouvez ajouter des métadonnées en utilisant le format LABEL version="2.0" pour afficher les métadonnées supplémentaires, utilisez la commande docker image inspect.
ONBUILD – La commande ONBUILD ajoute une instruction à exécuter ultérieurement lorsque l'image est utilisée comme base pour une autre construction de conteneur. Ce paramètre utilise les commandes ADD et RUN pour ajouter du contenu avec la commande ADD ou RUN un exécutable.
USER -La commande USER définit le nom d'utilisateur (ou UID) et éventuellement le groupe d'utilisateurs (ou GID) à utiliser lors de l'exécution de l'image. Cela ressemble à USER myuser:mygroup en pratique.
VOLUME :avec la plupart des conteneurs, il est nécessaire d'accéder aux données d'une manière ou d'une autre. La commande VOLUME créera un point de montage avec un nom spécifié qui le marque comme contenant un volume monté en externe. Ceci est couramment utilisé comme ceci, VOLUME ["/data"] .
WORKDIR – Enfin, la commande WORKDIR définit le répertoire de travail des commandes CMD ou ENTRYPOINT. Ceci est utilisé comme suit, WORKDIR /path/to/directory . WORKDIR est utile lorsque vous devez démarrer un exécutable mais que l'emplacement n'est pas dans la variable d'environnement PATH par défaut.

Conclusion

Le docker commit commande est étonnamment complexe. Bien qu'il existe une syntaxe simple, avec la possibilité d'ajouter des modifications DockerFile lors de l'utilisation de la commande commit, vous pouvez rapidement apporter des modifications qui persistent lors de la prochaine création du conteneur via DockerFile.

Cette commande n'est peut-être pas nécessaire dans toutes les situations, mais pour un dépannage rapide et pour les conteneurs d'instantanés qui peuvent être facilement déplacés entre les serveurs, la commande commit devient rapidement très utile !