Aller au contenu

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 ?
  • monservice a-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 ?

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.

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.

Dans votre pipeline CI applicatif, après avoir construit et poussé votre image :

Terminal window
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.

Terminal window
imglife app list

Les build records s’accumulent avec le temps. imglife app purge supprime les anciens records selon une politique de rétention :

Terminal window
imglife app purge --keep 3 --dry-run # aperçu : garder les 3 révisions les plus récentes par projet
imglife app purge --keep 3 # appliquer

Relation 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.

Quand vous exécutez imglife status, imglife :

  1. Liste toutes les images déclarées dans la section build:.
  2. Interroge le Package Registry pour tous les build records.
  3. Croise quelles images applicatives sont construites sur quelle base.
  4. 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.

registry:
url: https://gitlab.example.com
project_id: 42
api_url: https://gitlab.com # nécessaire uniquement pour gitlab.com

Credentials : GITLAB_TOKEN avec les scopes read_packages, write_packages.