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 :
Assurez-vous que vous êtes authentifié pour
gcloud
en exécutant la commande suivante :gcloud init
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
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" }
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.
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ôtegcr.io
STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
pour les images stockées surasia.gcr.io
,eu.gcr.io
ouus.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.