Dépannage du registre de conteneurs

Avant d'examiner des problèmes spécifiques, essayez ces étapes de dépannage :

1. Vérifiez que l'horloge système de votre client Docker et de votre serveur GitLab sont synchronisées (par exemple, via NTP).

2. Pour les registres basés sur S3, vérifiez que vos autorisations IAM et vos identifiants S3 (y compris la région) sont corrects. Pour plus d'informations, consultez la politique IAM exemple.

3. Vérifiez les erreurs dans les journaux du registre (par exemple, /var/log/gitlab/registry/current) et les journaux de production GitLab (par exemple, /var/log/gitlab/gitlab-rails/production.log).

4. Vérifiez le fichier de configuration NGINX pour le registre de conteneurs (par exemple, /var/opt/gitlab/nginx/conf/gitlab-registry.conf) pour confirmer quel port reçoit les requêtes.

5. Vérifiez que les requêtes sont correctement transmises au registre de conteneurs :

   shellCopy

   curl --verbose --noproxy "*" https://<hostname>:<port>/v2/_catalog
   

   La réponse doit inclure une ligne avec Www-Authenticate: Bearer contenant service="container_registry". Par exemple :

   plaintextCopy

   < HTTP/1.1 401 Unauthorized
   < Server: nginx
   < Date: Fri, 07 Mar 2025 08:24:43 GMT
   < Content-Type: application/json
   < Content-Length: 162
   < Connection: keep-alive
   < Docker-Distribution-Api-Version: registry/2.0
   < Www-Authenticate: Bearer realm="https://<hostname>/jwt/auth",service="container_registry",scope="registry:catalog:*"
   < X-Content-Type-Options: nosniff
   <
   {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":
   [{"Type":"registry","Class":"","Name":"catalog","ProjectPath":"","Action":"*"}]}]}
   * Connection #0 to host <hostname> left intact
   

Erreur : ... x509: certificate signed by unknown authority {#error--x509-certificate-signed-by-unknown-authority}

Lors de l'utilisation d'un certificat auto-signé avec le registre de conteneurs, vous pourriez rencontrer une erreur similaire dans vos jobs de pipeline CI/CD :

Error response from daemon: Get registry.example.com/v1/users/: x509: certificate signed by unknown authority

Cette erreur se produit car le démon Docker exécutant la commande attend un certificat signé par une autorité de certification reconnue, et non un certificat auto-signé.

Pour résoudre cette erreur, configurez Docker pour approuver les certificats auto-signés. Pour obtenir de l'aide sur la configuration de Docker, consultez Configurer les certificats auto-signés.

Pour des informations supplémentaires, consultez le ticket 18239.

La tentative de connexion Docker échoue avec : 'token signed by untrusted key' {#docker-login-attempt-fails-with-token-signed-by-untrusted-key}

Le registre s'appuie sur GitLab pour valider les identifiants Si le registre ne parvient pas à authentifier des tentatives de connexion valides, vous obtenez le message d'erreur suivant :

# docker login gitlab.company.com:4567
Username: user
Password:
Error response from daemon: login attempt to https://gitlab.company.com:4567/v2/ failed with status: 401 Unauthorized

Et plus précisément, cela apparaît dans le fichier journal /var/log/gitlab/registry/current :

level=info
msg="token signed by untrusted key with ID: "TOKE:NL6Q:7PW6:EXAM:PLET:OKEN:BG27:RCIB:D2S3:EXAM:PLET:OKEN""
level=warning msg="error authorizing context: invalid token" go.version=go1.12.7 http.request.host="gitlab.company.com:4567"
http.request.id=74613829-2655-4f96-8991-1c9fe33869b8 http.request.method=GET http.request.remoteaddr=10.72.11.20
http.request.uri="/v2/" http.request.useragent="docker/19.03.2 go/go1.12.8 git-commit/6a30dfc
kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.2 \(linux\))"

(Sauts de ligne ajoutés pour la lisibilité.)

GitLab utilise le contenu des deux parties de la paire de clés du certificat pour chiffrer le jeton d'authentification du registre. Ce message signifie que ces contenus ne correspondent pas.

Vérifiez quels fichiers sont utilisés :

• grep -A6 'auth:' /var/opt/gitlab/registry/config.yml

  yamlCopy

  ## Container registry certificate
     auth:
       token:
         realm: https://gitlab.my.net/jwt/auth
         service: container_registry
         issuer: omnibus-gitlab-issuer
    -->  rootcertbundle: /var/opt/gitlab/registry/gitlab-registry.crt
         autoredirect: false
  

• grep -A9 'Container Registry' /var/opt/gitlab/gitlab-rails/etc/gitlab.yml

  yamlCopy

  ## Container registry key
     registry:
       enabled: true
       host: gitlab.company.com
       port: 4567
       api_url: http://127.0.0.1:5000 # internal address to the registry, is used by GitLab to directly communicate with API
       path: /var/opt/gitlab/gitlab-rails/shared/registry
  -->  key: /var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key
       issuer: omnibus-gitlab-issuer
       notification_secret:
  

La sortie de ces commandes openssl doit correspondre, prouvant que la paire cert-clé est valide :

/opt/gitlab/embedded/bin/openssl x509 -noout -modulus -in /var/opt/gitlab/registry/gitlab-registry.crt | /opt/gitlab/embedded/bin/openssl sha256
/opt/gitlab/embedded/bin/openssl rsa -noout -modulus -in /var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key | /opt/gitlab/embedded/bin/openssl sha256

Si les deux parties du certificat ne correspondent pas, supprimez les fichiers et exécutez gitlab-ctl reconfigure pour régénérer la paire. La paire est recréée en utilisant les valeurs existantes dans /etc/gitlab/gitlab-secrets.json si elles existent. Pour générer une nouvelle paire, supprimez la section registry dans votre /etc/gitlab/gitlab-secrets.json avant d'exécuter gitlab-ctl reconfigure.

Si vous avez remplacé la paire auto-signée générée automatiquement par vos propres certificats et vous êtes assuré que leurs contenus correspondent, vous pouvez supprimer la section 'registry' dans votre /etc/gitlab/gitlab-secrets.json et exécuter gitlab-ctl reconfigure.

Erreur du registre GitLab avec AWS S3 lors de l'envoi de grandes images {#aws-s3-with-the-gitlab-registry-error-when-pushing-large-images}

Lors de l'utilisation d'AWS S3 avec le registre GitLab, une erreur peut se produire lors de l'envoi de grandes images. Recherchez l'erreur suivante dans le journal du registre :

level=error msg="response completed with error" err.code=unknown err.detail="unexpected EOF" err.message="unknown error"

Pour résoudre l'erreur, spécifiez une valeur chunksize dans la configuration du registre. Commencez avec une valeur comprise entre 25000000 (25 Mo) et 50000000 (50 Mo).

{{< tabs >}}

{{< tab title="Linux package (Omnibus)" >}}

1. Modifiez /etc/gitlab/gitlab.rb :

   rubyCopy

   registry['storage'] = {
     's3' => {
       'accesskey' => 'AKIAKIAKI',
       'secretkey' => 'secret123',
       'bucket'    => 'gitlab-registry-bucket-AKIAKIAKI',
       'chunksize' => 25000000
     }
   }
   

2. Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.

{{< /tab >}}

{{< tab title="Self-compiled (source)" >}}

1. Modifiez config/gitlab.yml :

   yamlCopy

   storage:
     s3:
       accesskey: 'AKIAKIAKI'
       secretkey: 'secret123'
       bucket: 'gitlab-registry-bucket-AKIAKIAKI'
       chunksize: 25000000
   

2. Enregistrez le fichier et redémarrez GitLab pour que les modifications prennent effet.

{{< /tab >}}

{{< /tabs >}}

Prise en charge des anciens clients Docker {#supporting-older-docker-clients}

Le registre de conteneurs Docker fourni avec GitLab désactive le manifeste schema1 par défaut. Si vous utilisez encore d'anciens clients Docker (1.9 ou antérieur), vous pourriez rencontrer une erreur lors de l'envoi d'images. Consultez le ticket 4145 pour plus de détails.

Vous pouvez ajouter une option de configuration pour la compatibilité ascendante.

{{< tabs >}}

{{< tab title="Linux package (Omnibus)" >}}

1. Modifiez /etc/gitlab/gitlab.rb :

   rubyCopy

   registry['compatibility_schema1_enabled'] = true
   

2. Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.

{{< /tab >}}

{{< tab title="Self-compiled (source)" >}}

1. Modifiez le fichier de configuration YAML que vous avez créé lors du déploiement du registre. Ajoutez l'extrait suivant :

   yamlCopy

   compatibility:
       schema1:
           enabled: true
   

2. Redémarrez le registre pour que les modifications prennent effet.

{{< /tab >}}

{{< /tabs >}}

Erreur de connexion Docker {#docker-connection-error}

Une erreur de connexion Docker peut se produire lorsqu'il y a des caractères spéciaux dans le nom du groupe, du projet ou de la branche. Les caractères spéciaux peuvent inclure :

• Tiret bas initial
• Trait d'union/tiret final
• Double trait d'union/tiret

Pour contourner ce problème, vous pouvez modifier le chemin du groupe, modifier le chemin du projet ou modifier le nom de la branche. Une autre option consiste à créer une règle de push pour éviter cette erreur sur toute l'instance.

Erreurs d'envoi d'images {#image-push-errors}

Vous pourriez être bloqué dans des boucles de nouvelle tentative lors de l'envoi d'images Docker, même si docker login réussit.

Ce problème se produit lorsque NGINX ne transmet pas correctement les en-têtes au registre, généralement dans des configurations personnalisées où le SSL est déchargé vers un proxy inverse tiers.

Pour plus d'informations, consultez Docker push through NGINX proxy fails trying to send a 32B layer #970.

Pour résoudre ce problème, mettez à jour votre configuration NGINX pour activer les URL relatives dans le registre :

{{< tabs >}}

{{< tab title="Linux package (Omnibus)" >}}

1. Modifiez /etc/gitlab/gitlab.rb :

   rubyCopy

   registry['env'] = {
     "REGISTRY_HTTP_RELATIVEURLS" => true
   }
   

2. Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.

{{< /tab >}}

{{< tab title="Self-compiled (source)" >}}

1. Modifiez le fichier de configuration YAML que vous avez créé lors du déploiement du registre. Ajoutez l'extrait suivant :

   yamlCopy

   http:
       relativeurls: true
   

2. Enregistrez le fichier et redémarrez GitLab pour que les modifications prennent effet.

{{< /tab >}}

{{< tab title="Docker Compose" >}}

1. Modifiez votre fichier docker-compose.yaml :

   yamlCopy

   GITLAB_OMNIBUS_CONFIG: |
     registry['env'] = {
       "REGISTRY_HTTP_RELATIVEURLS" => true
     }
   

2. Si le problème persiste, assurez-vous que les deux URL utilisent HTTPS :

   yamlCopy

   GITLAB_OMNIBUS_CONFIG: |
     external_url 'https://git.example.com'
     registry_external_url 'https://git.example.com:5050'
   

3. Enregistrez le fichier et redémarrez le conteneur :

   shellCopy

   sudo docker restart gitlab
   

{{< /tab >}}

{{< /tabs >}}

Activer le serveur de débogage du registre {#enable-the-registry-debug-server}

Vous pouvez utiliser le serveur de débogage du registre de conteneurs pour diagnostiquer les problèmes. L'endpoint de débogage peut surveiller les métriques et l'état de santé, ainsi qu'effectuer du profilage.

[!warning] Des informations sensibles peuvent être disponibles via l'endpoint de débogage. L'accès à l'endpoint de débogage doit être restreint dans un environnement de production.

Le serveur de débogage optionnel peut être activé en définissant l'adresse de débogage du registre dans votre configuration gitlab.rb.

registry['debug_addr'] = "localhost:5001"

Après avoir ajouté le paramètre, reconfigurez GitLab pour appliquer la modification.

Utilisez curl pour demander la sortie de débogage au serveur de débogage :

curl "localhost:5001/debug/health"
curl "localhost:5001/debug/vars"

Métriques Prometheus {#prometheus-metrics}

Prometheus fournit des métriques que vous pouvez utiliser pour surveiller et résoudre les problèmes de performance de votre registre de conteneurs.

Les sections suivantes :

• Vous montrent comment activer les métriques Prometheus
• Répertorient toutes les métriques Prometheus exportées par le registre de conteneurs, organisées par composant

Activer les métriques Prometheus {#enable-prometheus-metrics}

Prérequis :

• Vous devez activer le serveur de débogage du registre.

Pour activer les métriques Prometheus, ajoutez la configuration suivante dans gitlab.rb :

# Enable Prometheus metrics
registry['debug'] = {
  'prometheus' => {
    'enabled' => true,
    'path' => '/metrics'
  }
}

Pour appliquer la modification, reconfigurez GitLab.

Utilisez curl pour demander des métriques au serveur de débogage :

curl "localhost:5001/metrics"

Métriques de notifications {#notifications-metrics}

Compteurs {#counters}

Jauges {#gauges}

Histogrammes {#histograms}

Métriques de migration en arrière-plan par lots (BBM) {#batched-background-migration-bbm-metrics}

Compteurs {#counters-1}

Jauges {#gauges-1}

Histogrammes {#histograms-1}

Métriques de base de données {#database-metrics}

Compteurs {#counters-2}

Jauges {#gauges-2}

Histogrammes {#histograms-2}

Footnotes :

1. Valeurs des compartiments par défaut de Prometheus : [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] (secondes)

Métriques de collecte des déchets (GC) {#garbage-collection-gc-metrics}

Compteurs {#counters-3}

Histogrammes {#histograms-3}

Footnotes :

1. Valeurs des compartiments par défaut de Prometheus : [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] (secondes)

Métriques de stockage {#storage-metrics}

Compteurs {#counters-4}

Jauges {#gauges-3}

Histogrammes {#histograms-4}

Activer les journaux de débogage du registre {#enable-registry-debug-logs}

Vous pouvez activer les journaux de débogage pour faciliter le dépannage du registre de conteneurs.

[!warning] Les journaux de débogage peuvent contenir des informations sensibles telles que des détails d'authentification, des jetons ou des informations sur le dépôt. Activez les journaux de débogage uniquement si nécessaire, et désactivez-les une fois le dépannage terminé.

{{< tabs >}}

{{< tab title="Linux package (Omnibus)" >}}

1. Modifiez /var/opt/gitlab/registry/config.yml :

   yamlCopy

   level: debug
   

2. Enregistrez le fichier et redémarrez le registre :

   shellCopy

   sudo gitlab-ctl restart registry
   

Cette configuration est temporaire et est supprimée lorsque vous exécutez gitlab-ctl reconfigure.

{{< /tab >}}

{{< tab title="Helm chart (Kubernetes)" >}}

1. Exportez les valeurs Helm :

   shellCopy

   helm get values gitlab > gitlab_values.yaml
   

2. Modifiez gitlab_values.yaml :

   yamlCopy

   registry:
     log:
       level: debug
   

3. Enregistrez le fichier et appliquez les nouvelles valeurs :

   shellCopy

   helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab --namespace <namespace>
   

{{< /tab >}}

{{< /tabs >}}

Activer les métriques Prometheus du registre {#enable-registry-prometheus-metrics}

Si le serveur de débogage est activé, vous pouvez également activer les métriques Prometheus. Cet endpoint expose une télémétrie très détaillée concernant presque toutes les opérations du registre.

registry['debug'] = {
  'prometheus' => {
    'enabled' => true,
    'path' => '/metrics'
  }
}

Utilisez curl pour demander la sortie de débogage depuis Prometheus :

curl "localhost:5001/debug/metrics"

Tags avec un nom vide {#tags-with-an-empty-name}

Si vous utilisez AWS DataSync pour copier les données du registre vers ou entre des buckets S3, un objet de métadonnées vide est créé dans le chemin racine de chaque dépôt de conteneurs dans le bucket de destination. Cela amène le registre à interpréter ces fichiers comme un tag qui apparaît sans nom dans l'interface utilisateur et l'API GitLab. Pour plus d'informations, consultez ce ticket.

Pour corriger ce problème, vous pouvez faire l'une des deux choses suivantes :

• Utilisez la commande rm de l'AWS CLI pour supprimer les objets vides à la racine de chaque dépôt concerné. Portez une attention particulière au / final et assurez-vous de ne pas utiliser l'option --recursive :

  shellCopy

  aws s3 rm s3://<bucket>/docker/registry/v2/repositories/<path to repository>/
  

• Utilisez la commande sync de l'AWS CLI pour copier les données du registre vers un nouveau bucket et configurer le registre pour l'utiliser. Cela laisse les objets vides en place.

Dépannage avancé {#advanced-troubleshooting}

Nous utilisons un exemple concret pour illustrer comment diagnostiquer un problème avec la configuration S3.

Examiner une politique de nettoyage {#investigate-a-cleanup-policy}

Si vous ne savez pas pourquoi votre politique de nettoyage a ou n'a pas supprimé un tag, exécutez la politique ligne par ligne en exécutant le script ci-dessous depuis la console Rails. Cela peut aider à diagnostiquer les problèmes liés à la politique.

repo = ContainerRepository.find(<repository_id>)
policy = repo.project.container_expiration_policy

tags = repo.tags
tags.map(&:name)

tags.reject!(&:latest?)
tags.map(&:name)

regex_delete = ::Gitlab::UntrustedRegexp.new("\\A#{policy.name_regex}\\z")
regex_retain = ::Gitlab::UntrustedRegexp.new("\\A#{policy.name_regex_keep}\\z")

tags.select! { |tag| regex_delete.match?(tag.name) && !regex_retain.match?(tag.name) }

tags.map(&:name)

now = DateTime.current
tags.sort_by! { |tag| tag.created_at || now }.reverse! # Lengthy operation

tags = tags.drop(policy.keep_n)
tags.map(&:name)

older_than_timestamp = ChronicDuration.parse(policy.older_than).seconds.ago

tags.select! { |tag| tag.created_at && tag.created_at < older_than_timestamp }

tags.map(&:name)

• Le script construit la liste des tags à supprimer (tags).
• tags.map(&:name) affiche une liste de tags à supprimer. Il peut s'agir d'une opération longue.
• Après chaque filtre, vérifiez la liste de tags pour voir si elle contient les tags destinés à être supprimés.

Erreur 403 inattendue lors d'un push {#unexpected-403-error-during-push}

Un utilisateur a tenté d'activer un registre basé sur S3. L'étape docker login s'est déroulée correctement. Cependant, lors de l'envoi d'une image, la sortie affichait :

The push refers to a repository [s3-testing.myregistry.com:5050/root/docker-test/docker-image]
dc5e59c14160: Pushing [==================================================>] 14.85 kB
03c20c1a019a: Pushing [==================================================>] 2.048 kB
a08f14ef632e: Pushing [==================================================>] 2.048 kB
228950524c88: Pushing 2.048 kB
6a8ecde4cc03: Pushing [==>                                                ] 9.901 MB/205.7 MB
5f70bf18a086: Pushing 1.024 kB
737f40e80b7f: Waiting
82b57dbc5385: Waiting
19429b698a22: Waiting
9436069b92a3: Waiting
error parsing HTTP 403 response body: unexpected end of JSON input: ""

Cette erreur est ambiguë car il n'est pas clair si le 403 provient de l'application GitLab Rails, du registre Docker ou d'autre chose. Dans ce cas, puisque nous savons que la connexion a réussi, nous devons probablement examiner la communication entre le client et le registre.

L'API REST entre le client Docker et le registre est décrite dans la documentation Docker. Habituellement, on utiliserait simplement Wireshark ou tcpdump pour capturer le trafic et voir où les choses ont mal tourné. Cependant, étant donné que toutes les communications entre les clients et les serveurs Docker se font via HTTPS, il est un peu difficile de déchiffrer rapidement le trafic, même si vous connaissez la clé privée. Que peut-on faire à la place ?

Une façon serait de désactiver HTTPS en configurant un registre non sécurisé. Cela pourrait introduire une faille de sécurité et n'est recommandé que pour les tests locaux. Si vous avez un système en production et que vous ne pouvez pas ou ne voulez pas faire cela, il existe une autre façon : utiliser mitmproxy, qui signifie Man-in-the-Middle Proxy.

mitmproxy {#mitmproxy}

mitmproxy vous permet de placer un proxy entre votre client et votre serveur pour inspecter tout le trafic. Un point délicat est que votre système doit faire confiance aux certificats SSL de mitmproxy pour que cela fonctionne.

Les instructions d'installation suivantes supposent que vous exécutez Ubuntu :

1. Installez mitmproxy.

2. Exécutez mitmproxy --port 9000 pour générer ses certificats. Appuyez sur <kbd>Control</kbd>-<kbd>C</kbd> pour quitter.

3. Installez le certificat depuis ~/.mitmproxy sur votre système :

   shellCopy

   sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
   sudo update-ca-certificates
   

En cas de succès, la sortie doit indiquer qu'un certificat a été ajouté :

Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.

Pour vérifier que les certificats sont correctement installés, exécutez :

mitmproxy --listen-port 9000

Cette commande exécute mitmproxy sur le port 9000. Dans une autre fenêtre, exécutez :

curl --proxy "http://localhost:9000" "https://httpbin.org/status/200"

Si tout est correctement configuré, les informations s'affichent dans la fenêtre mitmproxy et aucune erreur n'est générée par les commandes curl.

Exécution du démon Docker avec un proxy {#running-the-docker-daemon-with-a-proxy}

Pour que Docker se connecte via un proxy, vous devez démarrer le démon Docker avec les variables d'environnement appropriées. Le moyen le plus simple est d'arrêter Docker (par exemple sudo initctl stop docker) puis d'exécuter Docker manuellement. En tant que root, exécutez :

export HTTP_PROXY="http://localhost:9000"
export HTTPS_PROXY="http://localhost:9000"
docker daemon --debug # or dockerd --debug

Cette commande lance le démon Docker et redirige toutes les connexions via mitmproxy.

Exécution du client Docker {#running-the-docker-client}

Maintenant que nous avons mitmproxy et Docker en cours d'exécution, nous pouvons tenter de nous connecter et d'envoyer une image de conteneur. Vous devrez peut-être exécuter en tant que root pour ce faire. Par exemple :

docker login example.s3.amazonaws.com:5050
docker push example.s3.amazonaws.com:5050/root/docker-test/docker-image

Dans l'exemple précédent, nous voyons la trace suivante dans la fenêtre mitmproxy :

PUT https://example.s3.amazonaws.com:4567/v2/root/docker-test/blobs/uploads/(UUID)/(QUERYSTRING)
    ← 201 text/plain [no content] 661ms
HEAD https://example.s3.amazonaws.com:4567/v2/root/docker-test/blobs/sha256:(SHA)
    ← 307 application/octet-stream [no content] 93ms
HEAD https://example.s3.amazonaws.com:4567/v2/root/docker-test/blobs/sha256:(SHA)
    ← 307 application/octet-stream [no content] 101ms
HEAD https://example.s3.amazonaws.com:4567/v2/root/docker-test/blobs/sha256:(SHA)
    ← 307 application/octet-stream [no content] 87ms
HEAD https://amazonaws.example.com/docker/registry/vs/blobs/sha256/dd/(UUID)/data(QUERYSTRING)
    ← 403 application/xml [no content] 80ms
HEAD https://amazonaws.example.com/docker/registry/vs/blobs/sha256/dd/(UUID)/data(QUERYSTRING)
    ← 403 application/xml [no content] 62ms

Cette sortie montre :

• Les requêtes PUT initiales se sont déroulées correctement avec un code de statut 201.
• Le 201 a redirigé le client vers le bucket Amazon S3.
• La requête HEAD vers le bucket AWS a signalé un 403 Unauthorized.

Qu'est-ce que cela signifie ? Cela suggère fortement que l'utilisateur S3 ne dispose pas des autorisations pour effectuer une requête HEAD. La solution : vérifiez à nouveau les autorisations IAM. Une fois les autorisations correctes définies, l'erreur a disparu.

L'absence de gitlab-registry.key empêche la suppression du dépôt de conteneurs {#missing-gitlab-registrykey-prevents-container-repository-deletion}

Si vous désactivez le registre de conteneurs de votre instance GitLab et essayez de supprimer un projet qui contient des dépôts de conteneurs, l'erreur suivante se produit :

Errno::ENOENT: No such file or directory @ rb_sysopen - /var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key

Dans ce cas, suivez ces étapes :

1. Activez temporairement le paramètre à l'échelle de l'instance pour le registre de conteneurs dans votre gitlab.rb :

   rubyCopy

   gitlab_rails['registry_enabled'] = true
   

2. Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.

3. Réessayez la suppression.

Si vous ne parvenez toujours pas à supprimer le dépôt en utilisant les méthodes courantes, vous pouvez utiliser la console Rails GitLab pour supprimer le projet de force :

# Path to the project you'd like to remove
prj = Project.find_by_full_path(<project_path>)

# The following will delete the project's container registry, so be sure to double-check the path beforehand!
if prj.has_container_registry_tags?
  prj.container_repositories.each { |p| p.destroy }
end

Le service de registre écoute sur l'adresse IPv6 au lieu de l'IPv4 {#registry-service-listens-on-ipv6-address-instead-of-ipv4}

Vous pourriez voir l'erreur suivante si le nom d'hôte localhost se résout en adresse de bouclage IPv6 (::1) sur votre serveur GitLab et que GitLab s'attend à ce que le service de registre soit disponible sur l'adresse de bouclage IPv4 (127.0.0.1) :

request: "GET /v2/ HTTP/1.1", upstream: "http://[::1]:5000/v2/", host: "registry.example.com:5005"
[error] 1201#0: *13442797 connect() failed (111: Connection refused) while connecting to upstream, client: x.x.x.x, server: registry.example.com, request: "GET /v2/<path> HTTP/1.1", upstream: "http://[::1]:5000/v2/<path>", host: "registry.example.com:5005"

Pour corriger l'erreur, remplacez registry['registry_http_addr'] par une adresse IPv4 dans /etc/gitlab/gitlab.rb. Par exemple :

registry['registry_http_addr'] = "127.0.0.1:5000"

Consultez le ticket 5449 pour plus de détails.

Échecs de push et utilisation élevée du CPU avec Google Cloud Storage (GCS) {#push-failures-and-high-cpu-usage-with-google-cloud-storage-gcs}

Vous pourriez obtenir une erreur 502 Bad Gateway lors de l'envoi d'images de conteneurs vers un registre qui utilise GCS comme backend. Le registre peut également connaître des pics d'utilisation du CPU lors de l'envoi de grandes images.

Ce problème se produit lorsque le registre communique avec GCS en utilisant le protocole HTTP/2.

La solution de contournement consiste à désactiver HTTP/2 dans votre déploiement de registre en définissant la variable d'environnement GODEBUG à http2client=0.

Pour plus d'informations, consultez le ticket 1425.