doc-locale/fr-fr/install/docker/troubleshooting.md
{{< details >}}
{{< /details >}}
Lors de l'installation de GitLab dans un conteneur Docker, vous pouvez rencontrer les problèmes suivants.
Les commandes suivantes sont utiles lors de la résolution des problèmes de votre instance GitLab dans un conteneur Docker :
Lire les journaux du conteneur :
sudo docker logs gitlab
Entrer dans le conteneur en cours d'exécution :
sudo docker exec -it gitlab /bin/bash
Vous pouvez administrer le conteneur GitLab depuis l'intérieur du conteneur comme vous administreriez une installation du package Linux.
Lors de la mise à jour de l'image Docker, vous pouvez rencontrer un problème où tous les chemins affichent une page 500. Si cela se produit, redémarrez le conteneur :
sudo docker restart gitlab
Lors de la mise à jour depuis des images Docker GitLab plus anciennes, vous pourriez rencontrer des problèmes de permissions. Cela se produit lorsque les permissions utilisateur dans les images précédentes n'ont pas été préservées correctement. Il existe un script qui corrige les permissions pour tous les fichiers.
Pour corriger votre conteneur, exécutez update-permissions puis redémarrez le conteneur :
sudo docker exec gitlab update-permissions
sudo docker restart gitlab
ruby_block {#error-executing-action-run-on-resource-ruby_block}Cette erreur se produit lors de l'utilisation de Docker Toolbox avec Oracle VirtualBox sur Windows ou Mac, et lors de l'utilisation de volumes Docker :
Error executing action run on resource ruby_block[directory resource: /data/GitLab]
Le volume /c/Users est monté en tant que dossier partagé VirtualBox et ne prend pas en charge toutes les fonctionnalités du système de fichiers POSIX. La propriété et les permissions du répertoire ne peuvent pas être modifiées sans remonter le volume, ce qui provoque l'échec de GitLab.
Passez à l'utilisation de l'installation Docker native pour votre plateforme, au lieu d'utiliser Docker Toolbox.
Si vous ne pouvez pas utiliser l'installation Docker native (Windows 10 Home Edition ou Windows 7/8), une solution alternative consiste à configurer des montages NFS à la place des partages VirtualBox pour Docker Toolbox Boot2docker.
Si vous utilisez des ACL de fichiers sur l'hôte Docker, le groupe docker nécessite un accès complet aux volumes pour que GitLab fonctionne :
getfacl $GITLAB_HOME
# file: $GITLAB_HOME
# owner: XXXX
# group: XXXX
user::rwx
group::rwx
group:docker:rwx
mask::rwx
default:user::rwx
default:group::rwx
default:group:docker:rwx
default:mask::rwx
default:other::r-x
Si ces valeurs ne sont pas correctes, définissez-les avec :
sudo setfacl -mR default:group:docker:rwx $GITLAB_HOME
Le groupe par défaut est nommé docker. Si vous avez modifié le nom du groupe, vous devez ajuster la commande.
/dev/shm ne dispose pas d'assez d'espace dans le conteneur Docker {#devshm-mount-not-having-enough-space-in-docker-container}GitLab est fourni avec un endpoint de métriques Prometheus à l'adresse /-/metrics pour exposer des statistiques sur l'état et les performances de GitLab. Les fichiers nécessaires à cette fonctionnalité sont écrits dans un système de fichiers temporaire (comme /run ou /dev/shm).
Par défaut, Docker alloue 64 Mo au répertoire de mémoire partagée (monté à l'emplacement /dev/shm). Cette capacité est insuffisante pour contenir tous les fichiers de métriques Prometheus générés, et produira des journaux d'erreurs tels que les suivants :
writing value to /dev/shm/gitlab/sidekiq/gauge_all_sidekiq_0-1.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/gauge_all_sidekiq_0-1.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/gauge_all_sidekiq_0-1.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with unmapped file
writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with unmapped file
Bien que vous puissiez désactiver les métriques Prometheus dans la zone Admin, la solution recommandée pour résoudre ce problème est d'installer le conteneur avec la mémoire partagée définie à au moins 256 Mo. Si vous utilisez docker run, vous pouvez passer l'option --shm-size 256m. Si vous utilisez un fichier docker-compose.yml, vous pouvez définir la clé shm_size.
json-file {#docker-containers-exhausts-space-due-to-the-json-file}Docker utilise le pilote de journalisation par défaut json-file, qui n'effectue aucune rotation des journaux par défaut. En raison de cette absence de rotation, les fichiers journaux stockés par le pilote json-file peuvent consommer une quantité significative d'espace disque pour les conteneurs qui génèrent beaucoup de données en sortie. Cela peut entraîner un épuisement de l'espace disque. Pour remédier à ce problème, utilisez journald comme pilote de journalisation lorsqu'il est disponible, ou un autre pilote pris en charge avec prise en charge native de la rotation.
Si vous recevez cette erreur de dépassement de tampon, vous devez purger les anciens fichiers journaux dans /var/log/gitlab :
buffer overflow detected : terminated
xargs: tail: terminated by signal 6
La suppression des anciens fichiers journaux permet de corriger l'erreur et garantit un démarrage propre de l'instance.
Lors de la réutilisation de données d'une autre instance, vous pourriez rencontrer les problèmes suivants.
stat: missing operand au démarrage {#stat-missing-operand-error-on-startup}Cette erreur se produit lors de la migration depuis une installation de package Linux et que le répertoire git-data/repositories est manquant ou est un lien symbolique cassé dans le volume hôte :
stat: missing operand
Expected process to exit with [0], but received '1'
Ran stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data/repositories) returned 1
Sur l'hôte, créez le répertoire manquant, puis redémarrez le conteneur :
sudo mkdir -p $GITLAB_HOME/data/git-data/repositories
sudo docker restart <container_name>
Pour un guide de migration complet, consultez Migrer une instance GitLab avec package Linux vers Docker.
docker exec {#container-exits-immediately-and-restart-loop-blocks-docker-exec}Si un conteneur ne parvient pas à démarrer et continue de redémarrer, vous ne pouvez pas utiliser docker exec pour investiguer. Démarrez directement un shell dans l'image à la place :
docker run --rm -it --entrypoint /bin/bash gitlab/gitlab-ee:<version>
Utilisez ce shell pour inspecter la structure de répertoires attendue et comparez-la avec les volumes montés sur l'hôte.
can't create Thread: Operation not permitted
Cette erreur se produit lors de l'exécution d'un conteneur construit avec des versions plus récentes de glibc sur un hôte ne prenant pas en charge la fonction clone3. Dans GitLab 16.0 et versions ultérieures, l'image du conteneur inclut le package Linux Ubuntu 22.04, qui est construit avec des versions plus récentes de glibc.
Ce problème ne se produit pas avec les outils d'exécution de conteneurs plus récents comme Docker 20.10.10.
Pour résoudre ce problème, mettez Docker à jour vers la version 20.10.10 ou ultérieure.