Suivi de fin de vie (EOL)

Pourquoi le suivi EOL est important

Utiliser un runtime après sa date de fin de vie est un risque de sécurité : les mainteneurs upstream cessent de publier des correctifs pour les CVE. En pratique, de nombreuses équipes continuent d’utiliser des images EOL faute d’alerte automatique.

imglife intègre le suivi EOL dans le cycle de vie des images pour vous avertir avant l’EOL, pas après.

Source de données

imglife récupère les données EOL depuis endoflife.date, une base de données communautaire des cycles de release de centaines de produits (Alpine Linux, Go, Node.js, Python, Ubuntu, Debian, etc.).

Vous pouvez aussi utiliser un fichier YAML local comme source — utile pour les environnements air-gappés ou les runtimes personnalisés non couverts par endoflife.date.

Alertes EOL dans le rapport d’état

Quand vous exécutez imglife status, chaque ligne d’image inclut :

Image	Date EOL	État
alpine:3.21.3-core1.0.0	2026-11-01	✅ OK
alpine:3.18.6-core1.0.0	❌ EOL	❌ Expiré
node:20.9.0-core1.0.0	2026-04-30	⚠️ < 30 jours

Le seuil d’alerte est configurable :

export IMGLIFE_ALERT_CRITICAL_DAYS=30  # alerter quand l'EOL est dans 30 jours (défaut)

Configuration de la source de données EOL

Dans votre imglife.yaml :

lifecycle:
  eol_provider: endoflife # défaut — récupérer depuis endoflife.date
  eol_target: git # stocker le cache dans git (défaut)
  eol_data_file: eol-data.yaml

Pour les environnements air-gappés, passez en fichier local :

lifecycle:
  eol_provider: local
  eol_data_file: eol-data.yaml

Le format du fichier eol-data.yaml reproduit la réponse de l’API endoflife.date :

alpine:
  - cycle: "3.21"
    eol: "2026-11-01"
    latest: "3.21.3"
  - cycle: "3.20"
    eol: "2026-04-01"
    latest: "3.20.6"
golang:
  - cycle: "1.22"
    eol: "2026-02-01"
    latest: "1.22.1"

Mise à jour du cache EOL

imglife eol update

Récupère des données fraîches depuis endoflife.date pour chaque produit référencé dans sync.entries[].lifecycle.product — ainsi que pour les cycles encore référencés par les build records applicatifs — et fusionne le résultat dans eol-data.yaml.

La fusion est déterminante : un tag miroir supprimé par keep_last ne contribue plus aucun cycle, alors qu’une application peut toujours tourner dessus. Conserver les cycles connus dans le cache est ce qui évite l’apparition de ⚠️ N/A dans le rapport de statut. Utilisez imglife eol update --prune pour reconstruire le fichier à partir des seuls cycles collectés.

Si un cycle manque malgré tout à la lecture, imglife se replie sur les cycles voisins : un cycle plus récent que tout ce que connaît endoflife.date hérite du statut du cycle précédent si celui-ci est encore supporté, et un cycle plus ancien que tous les cycles connus est signalé ⚠️ outdated plutôt qu’inconnu.

En CI, exécutez cette commande dans un job planifié (ex. hebdomadaire) pour maintenir le cache à jour. Voir Images de base — GitLab CI pour un exemple.

Configuration par image

Le suivi EOL est configuré par entrée de sync :

sync:
  entries:
    - source: docker.io/library/alpine
      tag_regex: '^3\.\d+\.\d+$'
      target: registry.example.com/mirrors/alpine
      lifecycle:
        product: alpine # correspond à une clé dans eol-data.yaml / endoflife.date
        track: minor # dériver le cycle du tag : "3.21.3" → "3.21"

Le champ track indique à imglife comment dériver la clé de cycle EOL depuis le tag de l’image :

Valeur `track`	Exemple tag	Cycle dérivé
`minor`	`3.21.3`	`3.21`
`major`	`22.04`	`22`

EOL dans la commande `check`

imglife check peut aussi exposer les données EOL dans les pipelines CI applicatifs. Quand une image de base approche de sa fin de vie, la commande check :

Avec les flags par défaut : avertit mais réussit
Avec --strict : fait échouer le job si la base est à ou après son EOL

# Dans le pipeline CI de votre application :
imglife check --base registry.example.com/bases/alpine:3.18.6-core1.0.0 --strict

Cibles de stockage pour les données EOL

imglife prend en charge deux cibles pour persister le cache EOL :

Cible	Description
`git` (défaut)	Écrit `eol-data.yaml` sur le système de fichiers local ; committez-le dans git
`pkgregistry`	Envoie le fichier vers le Package Registry (utile quand un commit depuis le CI est impossible)

Définissez la cible dans lifecycle.eol_target dans votre configuration.