Container Registry est obsolète et son abandon est planifié. Depuis le 15 mai 2024, Artifact Registry héberge les images du domaine gcr.io dans les projets qui n'ont pas encore utilisé Container Registry. Après le 18 mars 2025, Container Registry sera arrêté.

Pour commencer à gérer des conteneurs sur Google Cloud, utilisez Artifact Registry. Si vous utilisez Container Registry, découvrez comment passer à Artifact Registry pour gérer vos conteneurs sur Google Cloud.

Pour en savoir plus sur l'abandon et l'arrêt, consultez la page sur les abandons et les notes de version.

Cette page a été traduite par l'API Cloud Translation.

Dépannage

Dans cette section, nous expliquons comment résoudre les problèmes courants que vous pouvez rencontrer avec Container Registry et Docker.

Projets à l'échelle du domaine

Si vous rencontrez une erreur invalid reference format, l'une des causes possibles est que vous travaillez avec un projet à l'échelle du domaine.

Si votre projet est à l'échelle de votre domaine, l'ID de projet comprend le domaine suivi du signe deux-points (example.com:my-project). Pour en savoir plus sur l'utilisation des ID de projets incluant un domaine, consultez la section Projets à l'échelle du domaine.

Erreur d'état 405 : `v1 Registry API is disabled.`

Si vous êtes continuellement confronté à une erreur du type "v1 Registry API is disabled" lorsque vous essayez d'extraire ou de transférer des images, assurez-vous que votre nom d'hôte, l'ID de votre projet, le nom de l'image et son tag ou son condensé sont correctement orthographiés.

Pour voir les tags et le condensé de votre image, exécutez la commande suivante :

gcloud container images list-tags [HOSTNAME]/[PROJECT-ID]/[IMAGE]

Exemple :

gcloud container images list-tags gcr.io/my-project/my-image

Pour découvrir comment répertorier les tags et les condensés d'images, consultez la page Gérer les images.

Problèmes liés aux autorisations

Dans les sections suivantes, vous trouverez la description des solutions à des problèmes spécifiques liés aux autorisations. Veillez à toujours vous assurer que vous disposez des autorisations requises pour les transferts ou extractions. Consultez la section Autorisations et rôles.

Problèmes d'autorisation liés à l'accès uniforme au niveau du bucket

Si vous avez activé l'accès uniforme au niveau du bucket sur un bucket de stockage utilisé par Container Registry, des problèmes d'accès peuvent survenir lors de l'extraction et du transfert dans Container Registry.

Pour résoudre les problèmes d’accès, assurez-vous de disposer des autorisations nécessaires pour le transfert ou l'extraction. Ces autorisations sont répertoriées dans la section Autorisations et rôles.

Problèmes d'autorisation liés à la configuration de Docker sur votre ordinateur local

Si vous rencontrez une erreur permission denied comme celle illustrée dans l'exemple suivant :

FATA[0000] Post http://var/run/docker.sock/v1.17/images/gcr.io/container-engine-docs/example/push?tag=: dial unix /var/run/docker.sock: permission denied
ERROR: (gcloud.docker) A Docker command did not run successfully.
Tried to run: 'docker push gcr.io/container-engine-docs/example'
Exit code: 1

Il peut être nécessaire de vous ajouter au groupe d'utilisateurs docker.

Exécutez la commande suivante dans la fenêtre de votre interface système ou de votre terminal :

  sudo usermod -a -G docker ${USER}

Redémarrez votre système après vous être ajouté au groupe d'utilisateurs docker.

Problèmes d'autorisations lors de la communication avec Container Registry

Si vous rencontrez une erreur d'autorisation semblable à celle-ci :

Permission denied: Unable to create the repository, please check that you have access to do so

Vérifiez que la facturation est activée pour votre projet.
Vérifiez l'accès :
1. Assurez-vous que vous êtes authentifié pour gcloud en exécutant la commande suivante :
```
gcloud init
```
2. Vérifiez que Docker est configuré pour utiliser gcloud en tant qu'assistant d'identification pour Container Registry en exécutant la commande suivante :
```
gcloud auth configure-docker
```
3. Vérifiez que docker-credential-gcloud peut être exécuté :
```
docker-credential-gcloud list
```
  Vous devez voir un objet JSON dont l'une des clés est votre registre cible. Exemple :
```
{
  "https://asia.gcr.io": "oauth2accesstoken",
  "https://eu.gcr.io": "oauth2accesstoken",
  "https://gcr.io": "oauth2accesstoken",
  "https://us.gcr.io": "oauth2accesstoken"
}
```
4. Ensuite, vérifiez que vous avez l'autorisation d'écrire dans Cloud Storage au sein du projet vers lequel vous souhaitez transférer des données. Si ce n'est pas le cas, demandez à un administrateur d'accorder l'accès à votre compte utilisateur et réessayez.
5. Si le problème persiste bien que vous ayez obtenu l'autorisation requise, il se peut que le jeton d'accès obtenu ne comporte pas l'un des deux champs d'application suivants :
  - https://www.googleapis.com/auth/devstorage.read_write
  - https://www.googleapis.com/auth/devstorage.full_control
  Pour vérifier ce point, commencez par obtenir le jeton d'accès vous-même. Le processus requis varie d'une application à l'autre. Par exemple, si vous utilisez un jeton d'accès à partir d'un compte de service Compute Engine par défaut, vous pouvez suivre les instructions décrites ici.
  
  Une fois que vous avez obtenu le jeton d'accès vous-même, vous pouvez exécuter la commande suivante pour examiner les champs d'application utilisés dans l'obtention du jeton d'accès :
```
curl -H "Authorization: Bearer <your access token>" https://www.googleapis.com/oauth2/v1/tokeninfo
```
  Si les champs d'application mentionnés n'y figurent pas, corrigez le problème dans votre code pour vous assurer de les inclure lors de l'obtention du jeton d'accès. Par exemple, pour les jetons générés spécifiquement pour le compte de service par défaut sur votre machine virtuelle Compute Engine, vous devrez corriger le paramètre des champs d'application pour cette machine virtuelle et la recréer.

Problèmes d'autorisation lors du stockage et de la sortie d'images

Pour accéder au bucket de stockage Container Registry, l'instance de VM qui stocke ou sort des images doit être correctement configurée avec les niveaux d'accès et les autorisations IAM requis. Pour en savoir plus sur les paramètres requis, consultez Utiliser Container Registry avec Google Cloud.

Erreur ImagePullBackoff de Google Kubernetes Engine

GKE renvoie une erreur ImagePullBackoff lorsqu'il ne parvient pas à extraire une image d'un registre. L'erreur peut se produire si l'image ne peut pas être ou parce que vos nœuds ne disposent pas d'autorisations à extraire du registre. Par défaut, les nœuds GKE sont autorisés à extraire des images de Container Registry lorsque le registre se trouve dans le même projet Google Cloud que vos nœuds.

La documentation GKE explique comment identifier l'origine du problème et de le résoudre.

Application des règles d'administration

Les contraintes liées aux règles d'administration peuvent affecter l'utilisation Container Registry lorsqu'ils s'appliquent à des services que Container Registry y compris les contraintes qui nécessitent l'utilisation clés de chiffrement gérées par le client (CMEK).

Erreur "Bad Request" lors de l'envoi d'une image

Lorsque l'API Cloud Storage figure dans la liste des règles Deny pour la contrainte constraints/gcp.restrictNonCmekServices, vous ne pouvez pas transférer d'images vers Container Registry si les buckets de stockage sous-jacents ne sont pas chiffrés avec CMEK. Le message suivant est renvoyé :

unknown: Bad Request

Lorsque constraints/gcp.restrictCmekCryptoKeyProjects est configuré, les buckets de stockage doivent être chiffrés avec une CryptoKey provenant d'un projet, d'un dossier ou d'une organisation autorisés. Les buckets existants non conformes doivent être configurés pour utiliser la clé requise par défaut.

Pour chiffrer vos buckets de stockage, consultez Instructions pour Cloud Storage Le nom du bucket d'un hôte de registre se présente sous l'un des formats suivants :

artifacts.PROJECT-ID.appspot.com pour les images stockées sur l'hôte gcr.io
STORAGE-REGION.artifacts.PROJECT-ID.appspot.com pour les images stockées sur asia.gcr.io, eu.gcr.io ou us.gcr.io.

Le sujet Pub/Sub gcr n'a pas été créé automatiquement

Lorsque vous activez l'API Container Registry dans un projet Google Cloud, Container Registry tente de créer automatiquement une rubrique Pub/Sub avec l'ID de rubrique gcr à l'aide de clés de chiffrement gérées par Google.

Lorsque l'API Pub/Sub figure dans la liste de règles Deny pour la contrainte constraints/gcp.restrictNonCmekServices, les sujets doivent être chiffrés avec CMEK. Les requêtes de création d'un sujet sans chiffrement CMEK échoueront.

Pour créer le sujet gcr avec le chiffrement CMEK, consultez les instructions Pub/Sub pour chiffrer les sujets.

Limites de quota

Si vous dépassez la limite de quota de Container Registry, un message d'erreur de ce type s'affiche :

Error: Status 429 trying to pull repository [...] "Quota Exceeded."

Pour éviter de dépasser la limite de quota fixée, vous avez deux possibilités :

Augmenter le nombre d'adresses IP qui communiquent avec Container Registry. Les quotas sont appliqués par adresse IP.
Ajouter des tentatives qui introduisent un délai. Par exemple, vous pouvez utiliser un intervalle exponentiel entre les tentatives.

Point de terminaison de registre non valide avec boot2docker

Si vous rencontrez des problèmes pour accéder à Container Registry depuis un environnement boot2docker :

docker push gcr.io/example/sample

Error response from daemon: invalid registry endpoint https://gcr.io/v0/:
  unable to ping registry endpoint https://gcr.io/v0/
v2 ping attempt failed with error: Get https://gcr.io/v2/:
  x509: certificate has expired or is not yet valid
v1 ping attempt failed with error: Get https://gcr.io/v1/_ping:
  x509: certificate has expired or is not yet valid.
If this private registry supports only HTTP or HTTPS with an unknown CA
certificate, please add `--insecure-registry gcr.io` to the daemon's
arguments. In the case of HTTPS, if you have access to the registry's CA
certificate, no need for the flag; simply place the CA certificate at
/etc/docker/certs.d/gcr.io/ca.crt

Il peut être nécessaire de redémarrer boot2docker :

boot2docker stop
boot2docker start

Erreur lors du transfert d'une image au niveau de la racine

Lorsque vous essayez de transférer une image de conteneur, le transfert échoue avec un message qui inclut les éléments suivants:

Pushing to root-level images is disabled

Ce message indique que vous avez tagué l'image avec le nom d'hôte et l'image, mais que vous n'avez pas inclus l'ID du projet.

Taguez l'image en utilisant le format de chemin d'accès à l'image approprié :

HOSTNAME/PROJECT-ID/IMAGE :TAG

Exemple : gcr.io/web-project/web-app:1.0.

Docker sur Mac

Si vous rencontrez des problèmes avec Docker sur Mac, vous devrez peut-être essayer une solution de contournement. Parmi les erreurs possibles, citons par exemple une absence de réponse lors d'opérations Docker de transfert/d'extraction, ou encore une erreur réseau semblable à celle-ci :

Post https://us.gcr.io/v2/[repo name]/blobs/uploads/: dial tcp xx.xxx.xx.xx:xxx: i/o timeout

Si vous rencontrez ce type d'erreur, essayez de suivre les étapes ci-dessous :

Exécutez la commande docker-machine restart default dans le terminal Mac pour redémarrer le daemon Docker.
Assurez-vous que l'option "Securely store docker logins in macOS keychain" (Stocker les identifiants docker de manière sécurisée dans le trousseau macOS) n'est pas activée dans le menu des préférences de Docker.
Veillez à utiliser la version la plus récente de Docker.