Modèle trois niveaux

Le problème qu’imglife résout

Une organisation typique utilisant Docker fait face à plusieurs problèmes cumulatifs :

Prolifération des registries — chaque équipe tire depuis Docker Hub directement, créant des dépendances cachées sur la disponibilité et les licences externes.
Dérive des images de base — différents projets utilisent des versions différentes de la même image de base sans coordination.
Angle mort EOL — personne ne sait quelles images approchent de leur fin de vie jusqu’à ce qu’un scanner CVE sonne l’alarme.
Lacunes d’audit — il est impossible de répondre à “quelles applications utilisent Alpine 3.19 en ce moment ?”

imglife adresse tous ces problèmes avec une seule architecture.

Les trois niveaux

Niveau 1 — Miroirs

Les miroirs sont des copies directes et non modifiées des images publiques upstream, stockées dans votre registry privé.

docker.io/library/alpine:3.21.3  ──copie──▶  registry.example.com/mirrors/alpine:3.21.3
docker.io/library/golang:1.22    ──copie──▶  registry.example.com/mirrors/golang:1.22
quay.io/prometheus/prometheus    ──copie──▶  registry.example.com/mirrors/prometheus:...

Pourquoi des miroirs ?

Vos builds ne dépendent plus de la disponibilité réseau externe.
Vous contrôlez quels tags upstream existent dans votre environnement.
Le rate limiting Docker Hub n’affecte plus vos pipelines CI.
Vous disposez d’une traçabilité complète de quand chaque tag upstream a été tiré.

Les miroirs sont gérés par imglife sync.

Niveau 2 — Images de base

Les images de base sont construites au-dessus de vos miroirs. Elles ajoutent les outils standards de l’organisation, les configurations de sécurité et les métadonnées. C’est là que les politiques de votre équipe sont appliquées.

registry.example.com/mirrors/alpine:3.21.3
  + template Dockerfile (ca-certificates, tzdata, CA org, etc.)
  + labels OCI (date de build, révision git, date EOL, référence image de base)
  ──build──▶ registry.example.com/bases/alpine:3.21.3-core1.0.0

Le format de tag encode à la fois la version upstream et la version de build de l’organisation : <version-upstream>-core<version-org>. Cela signifie :

alpine:3.21.3-core1.0.0 → Alpine upstream 3.21.3, première version de build org
alpine:3.21.3-core1.1.0 → même upstream, configuration org mise à jour

Les images de base sont gérées par imglife build.

Niveau 3 — Images applicatives

Les images applicatives sont l’output final construit par les équipes individuelles. Elles utilisent vos images de base comme FROM :

ARG BASE_IMAGE
FROM ${BASE_IMAGE}

COPY monapp /usr/local/bin/
CMD ["monapp"]

L’insight clé : les équipes applicatives ne construisent pas leur propre base. Elles consomment celle que vous publiez. Quand vous mettez à jour votre base (nouvelle version Alpine, outillage patché), elles reconstruisent avec la nouvelle base et enregistrent le fait via imglife register.

Le système de build records

Quand une image applicative est construite, imglife register stocke un enregistrement JSON dans le Package Registry liant :

Le tag de l’image applicative (registry.example.com/apps/monservice:1.2.0)
L’image de base sur laquelle elle a été construite (registry.example.com/bases/alpine:3.21.3-core1.0.0)
La révision git et le nom du projet
L’horodatage de build

Cela crée un graphe de dépendances complet. Quand vous lancez imglife status, il peut répondre : “Quelles applications sont encore sur Alpine 3.19 ?”

Rapports d’état

imglife status génère un README Markdown avec trois tables — une par niveau. Chaque ligne montre :

Image	Version	Plateformes	EOL	État
alpine	3.21.3-core1.0.0	linux/amd64, linux/arm64	2026-11-01	✅ OK
golang	1.21.6-core1.0.0	linux/amd64	❌ EOL	❌ Expiré

La colonne état agrège les données EOL (depuis endoflife.date) avec votre politique de rétention.

CI conscient de l’EOL

La commande imglife check est conçue pour s’exécuter dans les pipelines CI applicatifs. Elle :

Lit le BASE_IMAGE utilisé dans le Dockerfile.
Interroge le Package Registry pour la dernière version disponible.
Compare l’image de base avec la dernière disponible.
Signale si la base est obsolète ou approche de l’EOL.

Avec --strict, elle fait échouer le job CI si la base est dépassée, forçant les équipes applicatives à rester à jour.

Résumé

Niveau	Géré par	Produit par	Chemin registry
Miroirs	`imglife sync`	CI dépôt base-images	`registry/mirrors/`
Bases	`imglife build`	CI dépôt base-images	`registry/bases/`
Applicatif	Équipes app	CI dépôt app	`registry/apps/`