🥇Conseils Docker : Nettoyez votre machine des encombrants

Bonjour Habr ! Je vous présente la traduction de l'article "Conseils Docker : Nettoyez votre machine locale" l'auteur Luc Juggery.

Aujourd'hui, nous allons parler de la manière dont Docker utilise l'espace disque de la machine hôte, et nous allons également voir comment libérer cet espace des vestiges d'images et de conteneurs inutilisés.

Consommation totale

Docker est un outil formidable, et il y a peu de gens qui en doutent aujourd'hui. Il y a seulement quelques années, ce produit nous a donné une toute nouvelle façon de construire, de livrer et de faire fonctionner n'importe quel environnement, permettant ainsi d'économiser considérablement les ressources processeur et la mémoire vive. En outre (et pour certains, c'est peut-être le plus important), Docker nous a permis de simplifier et d'unifier de manière incroyable la gestion du cycle de vie des environnements de travail utilisés.

Cependant, toutes ces merveilles de la vie moderne ont un coût. Lorsque nous lançons des conteneurs, téléchargeons ou créons nos propres images, déployons des écosystèmes complexes, nous avons un prix à payer. Et ce prix se paie aussi, en partie, en espace disque.

Si vous ne vous êtes jamais demandé combien d'espace est réellement occupé sur votre machine par Docker, vous pourriez être désagréablement surpris par le résultat de cette commande :

$ docker system df

Cela affiche l'utilisation du disque par Docker sous différents angles :

images – taille totale des images qui ont été téléchargées depuis les dépôts d'images et construites sur votre système ;
conteneurs – volume total d'espace disque utilisé par les conteneurs en cours d'exécution (c'est-à-dire le volume total des couches en lecture-écriture de tous les conteneurs) ;
volumes locaux – volume des stockages locaux montés sur les conteneurs ;
cache de construction – fichiers temporaires générés par le processus de construction des images (lors de l'utilisation de l'outil BuildKit, disponible à partir de la version 18.09 de Docker).

Je parie qu'après cette simple énumération, vous brûlez d'envie de nettoyer votre disque de ses déchets et de redonner vie à vos précieux gigaoctets (note de traduction : surtout si vous payez mensuellement pour ces gigaoctets).

Utilisation du disque par les conteneurs

Chaque fois qu'un conteneur est créé sur la machine hôte, plusieurs fichiers et répertoires sont créés dans le répertoire /var/lib/docker, parmi lesquels il convient de noter les suivants :

Le répertoire /var/lib/docker/containers/ID_conteneur – lorsque vous utilisez le pilote de journalisation standard, c'est ici que les journaux d'événements sont enregistrés au format JSON. Des journaux trop détaillés, ainsi que ceux qui ne sont lus par personne et ne sont pas traités d'une autre manière, deviennent souvent la cause de remplissages de disques.
Le répertoire /var/lib/docker/overlay2 – contient des couches en lecture-écriture des conteneurs (overlay2 est le pilote préféré dans la plupart des distributions Linux). Si le conteneur enregistre des données dans son système de fichiers, c'est dans ce répertoire qu'elles seront placées.

Imaginons un système sur lequel Docker est installé pour la première fois, sans jamais avoir exécuté de conteneurs ou construit des images. Son rapport sur l'utilisation de l'espace disque ressemblera à ceci :

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Lançons un conteneur, par exemple, NGINX :

$ docker container run --name www -d -p 8000:80 nginx:1.16

Que se passe-t-il avec le disque :

les images occupent 126 Mo, c'est justement ce NGINX que nous avons lancé dans le conteneur ;
les conteneurs occupent un ridicule 2 octets.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

À en juger par la sortie, nous n'avons pas encore d'espace que nous pourrions libérer. Comme 2 octets, c'est manifestement dérisoire, imaginons que notre NGINX ait, à la surprise générale, écrit quelque part 100 Mégaoctets de données et créé un fichier test.img de cette taille.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Examinons à nouveau l'utilisation de l'espace disque sur l'hôte. Nous verrons que le conteneur (containers) occupe maintenant 100 Mégaoctets.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Je pense que votre esprit curieux se demande déjà où se trouve notre fichier test.img. Cherchons-le :

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

Sans entrer dans les détails, il convient de noter que le fichier test.img est commodément situé au niveau de lecture-écriture, géré par le pilote overlay2. Si nous arrêtons notre conteneur, l'hôte nous indiquera que cet espace peut en principe être libéré :

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Comment pouvons-nous procéder ? En supprimant le conteneur, ce qui entraînera le nettoyage de l'espace correspondant au niveau de lecture-écriture.

Avec la commande suivante, vous pouvez supprimer tous les conteneurs installés d'un seul coup et nettoyer votre disque de tous les fichiers qu'ils ont créés au niveau de lecture-écriture :

$ docker container prune
AVERTISSEMENT ! Cela supprimera tous les conteneurs arrêtés.
Êtes-vous sûr de vouloir continuer ? [y/N] y
Conteneurs supprimés :
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Espace total récupéré : 104,9 Mo

Ainsi, nous avons libéré 104,9 Mo en supprimant le conteneur. Mais comme nous n'utilisons plus l'image téléchargée auparavant, celle-ci devient également candidate à la suppression et à la libération de nos ressources :

$ docker system df
TYPE           TOTAL      ACTIF     TAILLE      RÉCUPÉRABLE
Images         1          0          126M       126M (100 %)
Conteneurs     0          0          0B         0B
Volumes locaux 0          0          0B         0B
Cache de construction  0          0          0B         0B

Attention : tant que l'image est utilisée par au moins un conteneur, vous ne pourrez pas utiliser cette astuce.

La sous-commande prune, que nous avons utilisée ci-dessus, n'a d'effet que sur les conteneurs arrêtés. Si nous souhaitons supprimer non seulement les conteneurs arrêtés, mais aussi les conteneurs en cours d'exécution, nous devons utiliser l'une de ces commandes :

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

Remarques : si lors du démarrage du conteneur vous utilisez le paramètre —rm, tout l'espace disque qu'il occupait sera libéré lors de son arrêt.

Utilisation du disque par les images

Il y a quelques années, une taille d'image de plusieurs centaines de mégaoctets était tout à fait normale : l'image d'Ubuntu pesait 600 Mo, tandis que l'image de Microsoft .Net pesait plusieurs giga-octets. À cette époque, le téléchargement d'une seule image pouvait avoir un impact considérable sur votre espace libre sur le disque, même si vous partagiez des niveaux entre les images. Aujourd'hui – grâce aux grands – les images pèsent beaucoup moins, mais même dans ce cas, il est possible de saturer rapidement les ressources disponibles si certaines précautions ne sont pas prises.

Il existe plusieurs types d'images qui ne sont pas directement visibles par l'utilisateur final :

des images intermédiaires, sur lesquelles d'autres images sont basées – elles ne peuvent pas être supprimées si vous utilisez des conteneurs basés sur ces « autres » images;
les images pendantes – ce sont des images intermédiaires, auxquelles aucun des conteneurs en cours d'exécution ne fait référence – elles peuvent être supprimées.
Avec la commande suivante, vous pouvez vérifier la présence d'images pendantes dans votre système :

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     il y a 12 minutes      71.3MB

Vous pouvez les supprimer de la manière suivante :

$ docker image rm $(docker image ls -f dangling=true -q)

Nous pouvons également utiliser la sous-commande prune :

$ docker image prune
AVERTISSEMENT ! Cela supprimera toutes les images pendantes.
Êtes-vous sûr de vouloir continuer ? [y/N] y
Images supprimées :
supprimé : sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
supprimé : sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
supprimé : sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
supprimé : sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
supprimé : sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Espace total récupéré : 12.9kB

Si nous voulons par contre supprimer toutes les images (et pas seulement celles pendantes) avec une seule commande, nous pouvons procéder ainsi :

$ docker image rm $(docker image ls -q)

Utilisation du disque avec des volumes

Les volumes sont utilisés pour stocker des données en dehors du système de fichiers du conteneur. Par exemple, si nous voulons conserver les résultats d'une application afin de les utiliser par la suite. Un exemple courant est celui des bases de données.

Lançons un conteneur MongoDB, montons un volume externe par rapport au conteneur, et restaurons une sauvegarde de la base de données (nous l'avons disponible dans le fichier bck.json) :

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

Les données seront sur la machine hôte dans le répertoire /var/lib/docker/volumes. Mais pourquoi pas en lecture-écriture au niveau du conteneur ? Parce que dans le Dockerfile de l'image MongoDB, le répertoire /data/db (où MongoDB stocke ses données par défaut) est défini comme un volume.

Notes en passant : de nombreuses images, dont la mise en œuvre nécessite la création de données, utilisent des volumes pour sauvegarder ces données.

Lorsque nous avons fini de jouer avec MongoDB et que nous arrêtons (ou même supprimons) le conteneur, le volume ne sera pas supprimé. Il continuera à occuper notre précieux espace disque tant que nous ne le supprimerons pas explicitement avec cette commande :

$ docker volume rm $(docker volume ls -q)

Ou nous pouvons utiliser la sous-commande prune que nous connaissons déjà :

$ docker volume prune
AVERTISSEMENT ! Cela supprimera tous les volumes locaux non utilisés par au moins un conteneur.
Êtes-vous sûr de vouloir continuer ? [y/N] y
Volumes supprimés :
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Espace total récupéré : 25,82 Go
luc@saturn:~$

Utilisation du disque pour le cache de construction d'images

Dans Docker 18.09, le processus de création d'images a subi quelques modifications grâce à l'outil BuildKit. Cet outil augmente la vitesse du processus, optimise la gestion du stockage et la sécurité. Ici, nous ne détaillerons pas toutes les spécificités de cet outil excellent, nous nous concentrerons simplement sur la façon dont il impacte l'utilisation de l'espace disque.

Supposons que nous avons une application Node.Js très simple :

le fichier index.js lance un serveur HTTP simple, qui répond par une chaîne pour chaque requête reçue :
le fichier package.json définit les dépendances, dont seule expressjs est utilisée pour exécuter le serveur HTTP :

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('/', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

Le Dockerfile pour construire l'image ressemble à ceci :

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

Construisons l'image de la manière habituelle, sans utiliser BuildKit :

$ docker build -t app:1.0 .

Si nous vérifions l'utilisation de l'espace disque, nous verrons que seul l'image de base (node:13-alpine) et l'image finale (app:1.0) occupent de l'espace :

TYPE           TOTAL      ACTIF     TAILLE       RÉCUPÉRABLE
Images         2          0          109.3MB    109.3MB (100%)
Conteneurs     0          0          0B         0B
Volumes Locaux  0          0          0B         0B
Cache de Construction    0          0          0B         0B

Construisons la deuxième version de notre application, déjà avec l'utilisation de BuildKit. Pour cela, nous devons simplement définir la variable DOCKER_BUILDKIT sur 1 :

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

Si nous vérifions maintenant l'utilisation du disque, nous verrons que le cache de construction (build-cache) est impliqué :

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    11         0          8.949kB    8.949kB

Pour le nettoyer, nous allons utiliser la commande suivante :

$ docker builder prune
WARNING! Cela supprimera tout le cache de construction inutilisé.
Êtes-vous sûr de vouloir continuer ? [y/N] y
Objet du cache de construction supprimé :
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Espace total récupéré : 8.949kB

Tout nettoyer !

Ainsi, nous avons examiné le nettoyage de l'espace disque occupé par les conteneurs, images et volumes. Cela est aidé par la sous-commande prune. Mais elle peut également être utilisée au niveau du système Docker, et elle nettoiera tout ce qu'elle peut :

$ docker system prune
WARNING! Cela supprimera :
  - tous les conteneurs arrêtés
  - tous les réseaux non utilisés par au moins un conteneur
  - toutes les images inutilisées
  - tout le cache de construction inutilisé

Êtes-vous sûr de vouloir continuer ? [y/N]

Si pour une raison quelconque vous économisez de l'espace disque sur une machine avec Docker, il est conseillé d'adopter l'utilisation régulière de cette commande.

Source : habr.com

Conseils Docker : Nettoyez votre machine des déchets