Package Registry
Qu’est-ce que le Package Registry ?
Section intitulée « Qu’est-ce que le Package Registry ? »imglife utilise un Package Registry comme base de données légère pour les build records. Chaque fois qu’une image applicative est construite et enregistrée, un fichier JSON de métadonnées est stocké dans le package registry. imglife peut ensuite interroger ces données pour générer des rapports d’état et répondre à des questions comme :
- Quelles applications utilisent actuellement
bases/alpine:3.19? monservicea-t-il été reconstruit depuis la dernière mise à jour de l’image de base ?- Y a-t-il des build records orphelins pour des images qui n’existent plus ?
Backends supportés
Section intitulée « Backends supportés »imglife supporte trois backends, tous accessibles via la même interface :
| Provider | Implémentation | Cas d’usage |
|---|---|---|
| GitLab | GitLab Generic Package Registry | Défaut ; fonctionne avec les instances self-hosted et GitLab.com |
| Gitea | Gitea Generic Package Registry | Instances Gitea self-hosted |
| S3 | AWS S3 ou tout stockage compatible S3 | Air-gappé, MinIO, Garage, Cloudflare R2, etc. |
Configurez le provider dans la section registry: de votre imglife.yaml.
Contenu d’un build record
Section intitulée « Contenu d’un build record »Un build record est un petit fichier JSON :
{ "image": "registry.example.com/apps/monservice:1.2.0", "base": "registry.example.com/bases/alpine:3.21.3-core1.0.0", "revision": "a3f8b1c", "project": "myteam/monservice", "platforms": ["linux/amd64", "linux/arm64"], "built_at": "2026-04-01T10:00:00Z", "custom_fields": {}}Les records sont stockés en utilisant le tag de l’image comme clé. Publier un nouveau record pour le même tag écrase le précédent.
Publication d’un build record
Section intitulée « Publication d’un build record »Dans votre pipeline CI applicatif, après avoir construit et poussé votre image :
imglife register \ --image registry.example.com/apps/monservice:1.2.0 \ --base registry.example.com/bases/alpine:3.21.3-core1.0.0 \ --revision "$CI_COMMIT_SHA" \ --project "myteam/monservice"imglife lit le label OCI BASE_IMAGE_REF de l’image poussée pour auto-détecter la base si --base est omis et que le label est présent.
Voir imglife register pour la référence complète.
Interrogation des build records
Section intitulée « Interrogation des build records »imglife app listimglife app list --project myteam/monserviceimglife app list --detailedimglife app list --output jsonPurge des records obsolètes
Section intitulée « Purge des records obsolètes »Les build records s’accumulent avec le temps. imglife app purge supprime les anciens records selon une politique de rétention :
imglife app purge --keep 3 --dry-run # aperçu : garder les 3 révisions les plus récentes par projetimglife app purge --keep 3 # appliquerRelation avec imglife cleanup : cleanup lit tous les build records survivants pour déterminer quelles base-images sont encore référencées — ces images sont protégées de la suppression même si elles sont anciennes. En exécutant app purge avant cleanup dans le même pipeline, cleanup peut immédiatement libérer les base-images qui n’étaient plus référencées que par les records supprimés.
Voir imglife app pour les détails.
Comment imglife status utilise le registry
Section intitulée « Comment imglife status utilise le registry »Quand vous exécutez imglife status, imglife :
- Liste toutes les images déclarées dans la section
build:. - Interroge le Package Registry pour tous les build records.
- Croise quelles images applicatives sont construites sur quelle base.
- Génère le tableau Markdown d’état à trois niveaux.
Le résultat est un instantané complet de tout votre inventaire d’images, indiquant notamment quels projets applicatifs sont à jour.
Configuration par provider
Section intitulée « Configuration par provider »registry: url: https://gitlab.example.com project_id: 42 api_url: https://gitlab.com # nécessaire uniquement pour gitlab.comCredentials : GITLAB_TOKEN avec les scopes read_packages, write_packages.
registry: provider: gitea url: https://gitea.example.com owner: myorg repo: base-imagesCredentials : GITEA_TOKEN avec le scope package.
registry: provider: s3 bucket: imglife-builds region: eu-west-1Credentials : AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY.
registry: provider: s3 url: http://garage.internal:3900 # surcharge de l'endpoint bucket: imglife region: garage prefix: buildsMêmes credentials :
AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY.