Retour aux articles
blog — devops — zsh$ cat devops.md# 18 mars 2025Google tue ContainerRegistry et personne n'estsurpris
7 min de lecture

GCR ferme le 18 mars 2025. Google force la migration vers Artifact Registry. Un autre produit au cimetière, une autre migration forcée.

DockerGCPDevOpsCloud

Google Container Registry arrête d’accepter les pushs aujourd’hui. 18 mars 2025. Si ton CI/CD pousse encore vers gcr.io, il vient de casser

C’est pas une surprise. Google l’a annoncé en mai 2023. Presque deux ans de préavis. “Migrez vers Artifact Registry,” qu’ils ont dit. “Meilleures fonctionnalités,” qu’ils ont promis. “Expérience plus unifiée”

Traduction: on a construit un nouveau truc, maintenant bouge tes affaires ou elles disparaissent

Pourquoi GCR meurt

La raison officielle de Google? Artifact Registry est “plus moderne” et “supporte plus de types d’artefacts.” Ça gère les images Docker, les charts Helm, les packages npm, les artefacts Maven, tout au même endroit

La vraie raison? GCR marchait très bien, mais ça faisait pas partie de leur grande vision unifiée. Alors ils ont construit Artifact Registry, ont attendu que suffisamment de monde migre, et maintenant ils tuent l’ancien truc

C’est le manuel Google:

  1. Construire un nouveau truc
  2. Rendre les gens dépendants
  3. Construire un truc encore plus nouveau
  4. Forcer la migration
  5. Répéter tous les 3-5 ans

Souviens-toi que Container Registry était déjà un remplacement pour d’anciennes solutions d’hébergement Docker. Maintenant il est remplacé. Qu’est-ce qui remplace Artifact Registry en 2028? Fais tes paris

Ce qui se passe maintenant

Aujourd’hui, 18 mars 2025: Plus de push vers gcr.io. Ton pipeline CI/CD qui pousse des images? Mort. Tes builds automatisés? Cassés

3 juin 2025: Les pulls s’arrêtent aussi. Tu peux plus récupérer d’images. Rien

14 octobre 2025: Deadline finale. Les images que t’as pas migrées? Parties pour toujours

Google t’a donné presque deux ans de préavis. Ils t’ont aussi donné trois deadlines différentes à suivre, un outil de migration qui nécessite encore un autre composant gcloud, et zéro compensation pour ton temps d’ingénierie

La marche forcée vers Artifact Registry

Voici ce que tu dois faire si c’est pas déjà fait:

1. Créer des dépôts Artifact Registry

gcloud artifacts repositories create my-docker-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Migration forcée depuis GCR"

Le format d’URL change. C’est plus gcr.io/project-id/image:

# Ancien format GCR
gcr.io/my-project/my-app:v1.2.3

# Nouveau format Artifact Registry
us-central1-docker.pkg.dev/my-project/my-repo/my-app:v1.2.3

Plus de caractères à taper. La région est obligatoire dans l’URL. Plus de fun pour tout le monde

2. Copier tes images

Google fournit gcrane pour la copie en masse:

gcrane cp -r gcr.io/your-project \
  us-central1-docker.pkg.dev/your-project/my-repo

Ça marche bien pour 10 images. T’as 500 images sur plusieurs projets et régions? Bloque ta semaine

3. Mettre à jour chaque référence

Tes manifestes Kubernetes:

# Chercher et remplacer partout
image: gcr.io/my-project/my-app:v1.2.3
# Ça devient
image: us-central1-docker.pkg.dev/my-project/my-repo/my-app:v1.2.3

Tes pipelines CI/CD. Tes Dockerfiles. Tes charts Helm. Tes scripts de déploiement. Tes runbooks. Ta documentation. Chaque référence gcr.io codée en dur dans toute ta stack

T’en rates une? C’est un incident de prod à 3h du matin

4. Mettre à jour l’authentification partout

gcloud auth configure-docker us-central1-docker.pkg.dev

Chaque machine de dev. Chaque runner CI. Chaque agent de déploiement. Chaque endroit qui tire des images

Quelqu’un oubliera. Quelque chose cassera

5. Tout tester

Parce que tu vas absolument rater un truc

La surprise du coût dont personne parle

Artifact Registry est plus cher. Vraiment plus cher

Container Registry: $0.026 par GB par mois (tarif multi-régional Google Cloud Storage)

Artifact Registry: $0.10 par GB par mois

C’est presque 4x plus cher pour le stockage! Mêmes images, mêmes données, coût quadruplé

“Mais Artifact Registry a des dépôts régionaux!” Bien sûr. Si tu co-localises avec ton compute, t’économises sur l’egress. Ça pourrait compenser l’augmentation du stockage. Ou pas

Dans tous les cas, ta facture augmente. Pas parce que tu stockes plus. Pas parce que t’utilises plus de fonctionnalités. Parce que Google l’a décidé

Calcule ton stockage GCR actuel. Multiplie par 4. C’est ta nouvelle baseline. Budget en conséquence

C’est ça le problème avec Google Cloud

Google Cloud a d’excellentes technologies. Les produits marchent bien. L’infrastructure est solide. Puis ils la tuent

Le cimetière Google est rempli de produits sur lesquels les gens ont construit des business:

  • Google Reader
  • Google Code
  • Inbox
  • Cloud IoT Core
  • Cloud Functions Gen 1
  • Container Registry

Tous les 2-3 ans, un truc sur lequel t’as construit ton infra est déprécié. Tu reçois un préavis de 12-24 mois. Tu te précipites pour migrer. Tu réécris tout. Tu mets à jour chaque référence. Tu reformes ton équipe

Puis dans 3 ans, ils déprécient le remplacement

C’est pas de l’innovation. C’est du chaos pour le plaisir du chaos

La comparaison AWS que personne veut entendre

AWS supporte encore les API EC2 de 2006. Dix-neuf ans! Toujours fonctionnelles. Toujours supportées

Ils te forcent pas à migrer d’EC2 Classic vers VPC vers EC2-NextGen tous les deux ans. Ils ajoutent des nouvelles fonctionnalités, déprécient des trucs vraiment obsolètes, mais te font pas réécrire ton infra tous les trois ans parce qu’un PM a décidé que ça correspondait plus à la roadmap

Azure c’est pareil. Une fois qu’un truc sort, il reste

Google traite l’infrastructure comme des produits grand public. Livrer vite, itérer, tuer quand un truc plus brillant arrive. Ça marche pour les apps. Ça échoue catastrophiquement pour l’infra de prod qui doit tourner pendant une décennie

Ta base de données devrait pas nécessiter une migration majeure tous les trois ans. Ton registre de conteneurs non plus

Que faire

Si t’es sur GCP: Migre vers Artifact Registry immédiatement. T’as jusqu’au 3 juin avant que les pulls s’arrêtent. Budget du temps d’ingé supplémentaire. Budget des coûts plus élevés. Mets à jour tes plans de reprise après sinistre pour tenir compte de la dépréciation d’Artifact Registry par Google en 2027

Si tu choisis un cloud: Souviens-toi de ce moment. Quand t’évalues GCP vs AWS vs Azure, tiens compte de la taxe de migration. Tous les 3 ans, budget 2-3 mois de temps d’ingé pour migrer vers ce que Google décide être la nouvelle mode

Si t’es multi-cloud: Garde ton registre de conteneurs quelque part de stable. AWS ECR existe depuis 2015 sans aucune migration forcée. Docker Hub va nulle part. Harbor est auto-hébergé. Choisis un truc qui disparaîtra pas parce qu’un PM a changé la roadmap

La vraie leçon

Ton infrastructure devrait pas nécessiter de réécritures majeures tous les 3 ans parce qu’un vendeur a changé de stratégie

Container Registry marchait. C’était simple, rapide et pas cher. Ça faisait exactement une chose: stocker des images de conteneurs. Et ça le faisait bien

Mais c’était pas assez “unifié”, pas assez “moderne”, ça correspondait pas à la nouvelle vision Artifact. Alors maintenant c’est mort

Marque ton calendrier pour 2028. C’est quand ils annonceront Artifact Registry 2.0 et déprécieront la version actuelle. T’as lu ça ici en premier

Migre aujourd’hui. T’as jusqu’au 3 juin avant que tes déploiements cassent. 14 octobre avant que tes images disparaissent

Container Registry, mai 2015 - mars 2025. Une autre victime de l’incapacité de Google à maintenir des produits à long terme. Repose en paix aux côtés des 200+ autres services dans le cimetière

Au moins ils t’ont donné 77 jours entre “les pushs s’arrêtent” et “les pulls s’arrêtent” comme période de grâce. Quelle générosité

Update: Talos Linux utilisait encore GCR 8 mois après la fermeture

6 novembre 2025: Talos v1.11.5 sort. Utilise encore gcr.io/etcd-development/etcd:v3.6.5

C’est ça. Huit mois après que GCR ait arrêté d’accepter les pulls, Talos sort une version qui en dépend

La timeline est absurde:

  • 18 mars 2025: GCR arrête d’accepter les pushs
  • 3 juin 2025: GCR arrête d’accepter les pulls
  • 6 novembre 2025: Talos v1.11.5 sort, essaie de pull depuis gcr.io

Comment tu déploies une distro Kubernetes qui pull depuis un registry mort depuis 5 mois?

Le fix: v1.12.0-beta.0 switch enfin vers registry.k8s.io/etcd

Si t’es bloqué sur v1.11.5, patche-le toi-même:

cluster:
  etcd:
    image: registry.k8s.io/etcd:v3.5.16  # ou quay.io/coreos/etcd:v3.5.16

C’est ça qui arrive quand les dépendances de projet sont pas mises à jour. GCR a annoncé la fermeture en mai 2023. Talos avait deux ans pour corriger ça. Ils ont sorti une release cassée 8 mois après la deadline

Upgrade vers v1.12.0-beta.0 ou patche ta config. Attends pas une release stable qui pourrait encore référencer des registries morts

Vous avez aimé cet article ?

Faites-le savoir ! Un partage, c'est toujours apprécié.

À propos de l'auteur

Sofiane Djerbi

Sofiane Djerbi

Architecte Cloud & Kubernetes, Expert FinOps. J'aide les entreprises à construire des infrastructures scalables, sécurisées et rentables.

Commentaires