Les images Docker permettent de définir des environnements de travail qui sont ensuite implémentés dans des containers.

C’est à travers ces containers que vous pouvez manipuler ces environnements et exécuter des commandes.

Les images que vous utilisez sont ensuite stockées sur votre machine.

1. 🐋 Commandes Docker des images

À travers Docker, vous avez accès à plusieurs commandes ou outils pour gérer les images :

  • docker image : Outil pour gérer les images :
    • docker image ps : Liste vos images locales.
    • docker image pull : Récupère une image d’un registry.
    • docker image push : Envoie l’image sur un registry.
    • docker image remove : Supprime une image locale par le biais de son identifiant.
    • docker image prune : Supprime les images dangling (en suspend) ou unused (inutilisées).
  • docker images : Alias de docker image ps.
  • docker rmi : Alias de docker image remove.

2. 🗃️ Liste des images

Afficher la liste de vos images locales. Vous aurez alors les informations suivantes : nom, tag, ID hash, date de création et taille.

Plus vous utilisez d’images Docker, plus elles prennent de la place sur votre machine. De plus, toutes les images qui ont été “pré-construites” (build interrompu soit par une action manuelle, soit par une erreur de build) sont aussi stockées sur votre machine. Cela peut prendre rapidement de l’espace de stockage, surtout si les images sont mal optimisées et sont plus volumineuses qu’elles ne le devraient.

Vous aurez peut-être plusieurs images nommées <none>, ce sont généralement des images incomplètes créées suite à une erreur de build.

3. 🧹 Nettoyage

Docker met à disposition la commande docker image prune qui vous permet de supprimer toutes les images dangling (qui n’ont pas de nom). Vous pouvez aussi supprimer toutes les images inutilisées (qui n’ont pas de containers actifs), avec l’option --all.

Exécutez la commande docker image prune pour faire du bien à votre stockage local.

4. 🚀 Push sur registry

Au sein de votre équipe ou de votre organisation, vous avez versionné votre Dockerfile et les fichiers utilisés (pour rappel le poetry.lock et le pyproject.toml) permettant à tous ceux ayant accès à votre repository de pouvoir construire votre image et y rattacher un ou plusieurs container·s.

De cette manière, chaque personne qui va récupérer le Dockerfile devra construire l’image de son côté, donc chacun fera les mêmes actions et utilisera les mêmes ressources réseaux. Par ailleurs, dans le cadre d’un CI/CD, il faudra à chaque fois reconstruire l’image et recharger les dépendances des différents dépôts officiels.

Pour répondre à cette problématique, on stocke l’image sur un registry afin de récupérer l’image construite à la demande. L’image est buildée une seule fois, puis déposée sur le registry. Les personnes souhaitant récupérer l’image et les tâches de CI/CD vont récupérer l’image complète depuis le registry et l’utiliser directement, sans avoir besoin de la construire de leur côté.

4.1 Docker Hub

Il existe plusieurs solutions de registry :

  • Docker Hub : Solution officielle et publique de Docker.
  • Harbor : Solution privée et open-source de VMWare.
  • GitHub etGitLab mettent également une solution à disposition.

Pour le cas de ce TP, vous allez utiliser Docker Hub.

Créez un compte à partir de votre @ORT ou de votre compte GitHub et créez-vous un repository 3olen-tp-git-01-python, qui servira de repository pour votre image python de ce TP.

4.2 Push de l’image

Dans votre terminal, vous allez vous connecter à votre compte Docker par la commande docker login.

Vous allez devoir modifier le nom de votre image pour qu’il corresponde au nom d’image de votre repository :

3olen/tp-git-01-python => utilisateur_docker/3olen-tp-git-01-python.

Par ailleurs, il faudra aussi définir un tag à cette image afin d’avoir une référence claire et précise et vous saurez que ce tag (ou plutôt cette “version”) correspond à un état particulier de votre image, en l’occurrence une image python avec Poetry et la dépendence psutil.

Ceci va s’effectuer avec la commande docker tag :

# Remplacez "utilisateur_docker" par le nom de votre compte utilisateur
docker tag 3olen/tp-git-01-python utilisateur_docker/3olen-tp-git-01-python:1.0.0

Cette commande va créer un nouveau nom (ou un nouveau tag si on garde le même nom) de l’image “source” (à partir d’un tag, par défaut latest). Puisque le contenu des images (ou des tags) est identique, ils ont la même référence. Vous pouvez vous en rendre compte en listant vos images et vous remarquerez que “image ID” est la même valeur sur les deux lignes.

Dans ce cas, du coup, vous avez défini une image correspondant au nom de votre repository et vous l’avez tagguée en 1.0.0, en vous basant sur l’image que vous manipuliez jusqu’à présent (sur le tag latest).

Il ne reste plus qu’à pousser cette image sur votre repository :

# Remplacez "utilisateur_docker" par le nom de votre compte utilisateur
docker push utilisateur_docker/3olen-tp-git-01-python:1.0.0

Vérifiez ensuite sur la page de votre repository Docker Hub.

4.3 Utilisation de l’image du repository

Vous allez maintenant pouvoir remplacer vos utilisations de l’image 3olen/tp-git-01-python par l’image de votre repository (avec le tag poussé, bien sûr) :

  1. Supprimez l’image locale de 3olen/tp-git-01-python.
  2. Supprimez également l’image locale utilisateur_docker/3olen-tp-git-01-python:1.0.0, afin de pouvoir récupérer l’image à partir de votre repository.
  3. Faites un “search and replace” global sur votre projet afin d’utiliser la nouvelle image : utilisateur_docker/3olen-tp-git-01-python:1.0.0.
  4. Vérifiez bien que l’image n’existe plus avec docker images.
  5. Exécutez la commande python --version dans un container utilisant l’image de votre repository : 
    # Remplacez "utilisateur_docker" par le nom de votre compte utilisateur
docker run --rm -it utilisateur_docker/3olen-tp-git-01-python:1.0.0 python --version

Docker devrait vous informer que l’image n’existe pas localement et qu’il doit aller la chercher depuis les repositories qu’il connaît. L’image est alors pulled depuis votre repository via le réseau et accessible en local comme si vous l’aviez construite. Et, bien entendu, votre commande s’exécute et vous obtenez la version de python.

Vous pourriez, par ailleurs, faire la même chose avec l’image de n’importe lequel de vos camarades vu que nous avons défini un repository en “public”.

Et au sein d’un job de CI/CD, vous n’aurez jamais à construire les images, étant donné que les environnements d’exécution des tâches CI/CD sont supprimées à la volée. Vous utiliserez un registry duquel vous récupérez votre image.