Comment garbage collection le registre de conteneurs GitLab pour libérer du stockage –

Container Registry de GitLab fournit un endroit pratique pour stocker vos images Docker. Au fil du temps, Container Registry peut consommer votre espace disque à mesure que de nouvelles couches sont ajoutées. Voici comment libérer de l’espace de stockage en supprimant le matériel redondant.

Container Registry vous permet de stocker des images Docker avec le code source de votre projet. Si vous conservez de grandes images dans votre registre, vous pouvez trouver rapidement que votre coût de stockage dépasse vos attentes. GitLab conserve chaque couche indéfiniment, même après qu’il soit devenu redondant.

Définition d’une politique de nettoyage

La première étape pour regagner votre espace de stockage consiste à configurer une stratégie de nettoyage du registre de conteneurs. Les politiques de nettoyage sont appliquées individuellement à chaque projet. Cela signifie que vous pouvez personnaliser la période de rétention en fonction de chaque base de code.

Visitez votre projet dans GitLab et cliquez sur le lien «Paramètres» dans la barre latérale. Passez à la catégorie «CI / CD» et développez la section «Nettoyer les balises d’image» en bas de la page.

Basculez le bouton «Activé» sur la position marche pour activer la politique de nettoyage. Ensuite, choisissez quand exécuter la stratégie – «tous les jours» est une bonne valeur par défaut.

La section suivante, «Conserver ces balises», vous permet de définir des balises que la politique de nettoyage laissera seules. Les deux options, «conserver le plus récent» et «garder les balises correspondantes», sont indépendantes l’une de l’autre. Tu pourrais choisir de garder dev et nightly, complété par les cinq balises les plus récentes. La latest la balise est toujours inclus, en plus des balises définies.

La section suivante, «Supprimer ces balises», définit la liste blanche des balises à supprimer. Les balises qui ne correspondent pas au modèle de regex ne seront pas touchées. Ajustez la valeur «Supprimer les balises antérieures à» pour définir la durée de vie maximale de chaque balise, avant qu’elle ne soit nettoyée. Lorsque vous avez terminé, cliquez sur le bouton vert «Enregistrer».

Utilisation de l’API

L’application de politiques de nettoyage via l’interface utilisateur Web peut rapidement devenir fastidieuse. Utilisez plutôt l’API si vous modifiez plusieurs projets.

curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: <access_token>" --data-binary '{"container_expiration_policy_attributes":{"cadence":"1month","enabled":true,"keep_n":1,"older_than":"14d","name_regex":"","name_regex_delete":".*","name_regex_keep":"latest' "https://gitlab.example.com/api/v4/projects/<project_id>"

Vous devrez générer un jeton d’accès API en vous rendant sur votre page de profil dans GitLab. Utilisez le jeton comme <access_token> dans la commande ci-dessus. Ajustez l’URL pour qu’elle pointe vers votre projet – son ID se trouve sur sa page de projet dans GitLab.

L’exécution de la commande ci-dessus appliquera une politique de nettoyage du registre qui s’exécute tous les mois et nettoie les images de plus de 14 jours. La latest tag et le tag le plus récent (keep_n), sera conservé; tous les autres pourront être supprimés (.*).

Effets de la politique de nettoyage

La politique de nettoyage gère le non-étiquetage des images en fonction des critères que vous avez définis. Les balises seront supprimées de votre registre de conteneurs. Ils n’apparaîtront plus dans l’écran Container Registry de votre projet et ne pourront pas être extraits par les clients Docker.

Cependant, ne pas baliser une image n’est pas la même chose que la supprimer. La politique de nettoyage ne recycle pas les données, vous pouvez donc toujours voir une utilisation élevée du stockage même après l’élagage des balises désaffectées.

En effet, les couches d’image restent sur votre serveur GitLab, mises en cache pour référence future. Pour supprimer définitivement les données, vous devez ensuite exécuter la procédure de récupération de place de Container Registry.

Collecte des ordures

L’exécution de Garbage Collection supprimera toutes les couches d’image qui ne sont pas liées à une balise. Cela entraînera la suppression des images non marquées par votre politique de nettoyage. Il peut également disposer d’anciennes couches devenues redondantes lorsque vous avez poussé une nouvelle version d’une balise.

Le nettoyage de la mémoire doit être appelé manuellement via l’interface de ligne de commande de GitLab. Connectez-vous à votre serveur GitLab via SSH et exécutez la commande suivante:

sudo gitlab-ctl registry-garbage-collect

Le processus de nettoyage de la mémoire s’exécutera. Toutes les balises inutilisées dans votre registre de conteneurs seront recyclées. Garbage Collection recherche des images non balisées sur l’ensemble de votre instance GitLab.

En supposant que vous laissez la stratégie de nettoyage s’exécuter en premier, vous devriez maintenant constater une réduction saine de l’utilisation du stockage. Si c’est la première fois que vous exécutez le garbage collection sur une installation GitLab fréquemment utilisée, vous avez peut-être récupéré plusieurs gigaoctets d’espace.

Suppression de manifestes et de calques non balisés

Vous pouvez récupérer encore plus d’espace en demandant au garbage collection de supprimer également les manifestes d’image non balisés et les couches non référencées. C’est une opération plus destructrice, même si c’est normalement ce que vous vous attendez à voir.

sudo gitlab-ctl registry-garbage-collect -m

Ajout du -m flag supprimera tout calque non directement associé à un manifeste d’image étiqueté. Cela entraîne la perte des couches mises en cache et des étapes de construction intermédiaires.

Par défaut, Docker et GitLab Container Registry conservent toutes les couches créées, même si elles ne sont plus référencées. Cela signifie que vous pouvez toujours récupérer une couche précédemment connue à l’aide de son identifiant unique adressable par le contenu, même si elle ne possède plus de balise.

C’est pourquoi la suppression de ces calques n’est pas activée par défaut. Vous devez être conscient des implications avant d’exécuter la commande car cela pourrait avoir des conséquences graves dans certains flux de travail. Néanmoins, en utilisant le -m switch est souvent souhaitable – il libérera beaucoup plus d’espace disque et ne devrait pas avoir d’effets secondaires si vous ne référencez que des images en utilisant des noms de balises.

Exécution du nettoyage de la mémoire selon une planification

Les politiques de nettoyage s’exécutent automatiquement à la fréquence que vous avez configurée. Le nettoyage de la mémoire n’est pas configuré par défaut, c’est pourquoi une première exécution peut réduire considérablement l’utilisation du stockage.

Pour exécuter le ramasse-miettes selon un calendrier, vous devrez ajouter la commande à votre système crontab. Créer un fichier /etc/cron.d/registry-garbage-collection avec le contenu suivant pour exécuter le garbage collection tous les lundis à 2 heures du matin:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 2 * * 1  root gitlab-ctl registry-garbage-collect

Limitations de la récupération de place

Le temps nécessaire pour effectuer le garbage collection dépendra de la quantité de données à supprimer. Le nettoyage de la mémoire nécessite l’arrêt du service Container Registry pendant son exécution. Cela signifie que vos utilisateurs ne pourront pas extraire ou pousser des images tant que le processus n’est pas terminé.

Vous pouvez réduire l’impact des temps d’arrêt en basculant le registre en mode lecture seule, en exécutant la commande, puis en repassant en lecture-écriture. Le registre peut continuer à fonctionner mais les utilisateurs ne pourront pas envoyer d’images. De plus, les modes de commutation nécessitent la «reconfiguration» de GitLab (sudo gitlab-ctl reconfigure), ce qui peut en soi entraîner des temps d’arrêt en fonction de la configuration de votre installation.

Vous devez modifier les lignes suivantes dans /etc/gitlab/gitlab.rb:

registry['storage'] = {
    'maintenance' => {
      'readonly' => {
        'enabled' => true
      }
    }
  }

Courir sudo gitlab-ctl reconfigure, puis utilisez l’une des commandes de garbage collection. Une fois que c’est fait, désactivez le mode lecture seule en modifiant le enabled ligne dans votre gitlab.rb retour à false, puis reconfigurez GitLab à nouveau.