正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Dockerコンテナで実行されているGitLabのトラブルシューティング

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

GitLabをDockerコンテナにインストールする際、以下の問題が発生する可能性があります。

潜在的な問題の診断

Dockerコンテナ内のGitLabインスタンスのトラブルシューティング時に、以下のコマンドが役立ちます:

コンテナログの読み取り:

sudo docker logs gitlab

実行中のコンテナに入る:

sudo docker exec -it gitlab /bin/bash

Linux package installationを管理するのと同じように、コンテナ内からGitLabコンテナを管理できます。

500内部エラー

Dockerイメージを更新する際、すべてのパスが500ページを表示する問題に遭遇する場合があります。この問題が発生した場合は、コンテナを再起動してください:

sudo docker restart gitlab

パーミッションの問題

古いGitLab Dockerイメージから更新する際、パーミッションの問題に遭遇する可能性があります。これは、以前のイメージでユーザー権限が正しく保持されなかった場合に発生します。すべてのファイルのパーミッションを修正するスクリプトがあります。

コンテナを修正するには、update-permissionsを実行してからコンテナを再起動してください:

sudo docker exec gitlab update-permissions
sudo docker restart gitlab

リソースruby_blockでアクション実行中にエラー

このエラーは、WindowsまたはMacでOracle VirtualBoxとDocker Toolboxを使用し、Dockerボリュームを利用している場合に発生します:

Error executing action run on resource ruby_block[directory resource: /data/GitLab]

/c/UsersボリュームはVirtualBox共有フォルダーとしてマウントされており、すべてのPOSIXファイルシステム機能をサポートしていません。ディレクトリの所有権とパーミッションは再マウントせずに変更できず、GitLabは失敗します。

Docker Toolboxを使用する代わりに、お使いのプラットフォームのネイティブなDockerインストールを使用してください。

ネイティブのDockerインストールを使用できない場合(Windows 10 Home Edition、またはWindows 7/8)、代替策として、Docker Toolbox Boot2docker用にVirtualBox共有の代わりにNFSマウントを設定する方法があります。

Linux ACLの問題

DockerホストでファイルACLを使用している場合、GitLabが機能するためには、dockerグループがボリュームへのフルアクセスを必要とします:

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

これらの値が正しくない場合は、以下で設定してください:

sudo setfacl -mR default:group:docker:rwx $GITLAB_HOME

デフォルトグループの名前はdockerです。グループ名を変更した場合は、コマンドを調整する必要があります。

/dev/shmマウントがDockerコンテナ内で十分なスペースを持っていない

GitLabには、GitLabの健全性とパフォーマンスに関する統計を公開するために、/-/metricsにPrometheusメトリクスエンドポイントが付属しています。これに必要なファイルは、一時ファイルシステム(/run/dev/shmなど)に書き込まれます。

デフォルトでは、Dockerは共有メモリディレクトリ(/dev/shmにマウント)に64 MBを割り当てます。これは、生成されるすべてのPrometheusメトリクス関連ファイルを保持するには不十分であり、以下のようなエラーログが生成されます:

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

管理者エリアでPrometheusメトリクスをオフにすることはできますが、この問題を修正するための推奨される解決策は、共有メモリを少なくとも256 MBに設定してinstallすることです。docker runを使用する場合、--shm-size 256mフラグを渡すことができます。docker-compose.ymlファイルを使用する場合、shm_sizeキーを設定できます。

Dockerコンテナがjson-fileによりスペースを使い果たす

Dockerはjson-fileデフォルトロギングドライバーを使用します。これはデフォルトではログのローテーションを行いません。このローテーション不足の結果、json-fileドライバーによって保存されたログファイルは、多くの出力を生成するコンテナにとって、かなりのディスクスペースを消費する可能性があります。これはディスクスペースの枯渇につながる可能性があります。これに対処するには、利用可能な場合はjournaldをロギングドライバーとして使用するか、ネイティブのローテーションをサポートする別のサポートされているドライバーを使用してください。

Docker起動時のバッファオーバーフローエラー

このバッファオーバーフローエラーが発生した場合は、/var/log/gitlab内の古いログファイルをパージする必要があります:

buffer overflow detected : terminated
xargs: tail: terminated by signal 6

古いログファイルを削除するとエラーの修正に役立ち、インスタンスのクリーンな起動が保証されます。

以前のインストールからのデータを再利用する際のエラー

別のインスタンスからデータを再利用する際に、以下の問題が発生する可能性があります。

起動時のstat: missing operandエラー

このエラーは、Linuxパッケージインストールから移行する際に、git-data/repositoriesディレクトリがホストボリューム内にないか、壊れたシンボリックリンクである場合に発生します:

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

ホスト上で、不足しているディレクトリを作成し、コンテナを再起動します:

sudo mkdir -p $GITLAB_HOME/data/git-data/repositories
sudo docker restart <container_name>

完全な移行ガイドについては、LinuxパッケージGitLabインスタンスをDockerに移行するを参照してください。

コンテナがすぐに終了し、再起動ループによってdocker execがブロックされる

コンテナが起動に失敗し、再起動を繰り返す場合、調査のためにdocker execを使用することはできません。代わりに、イメージ内で直接Shellを起動してください:

docker run --rm -it --entrypoint /bin/bash gitlab/gitlab-ee:<version>

このShellを使用して、予期されるディレクトリ構造を検査し、ホストにマウントされているボリュームと比較してください。

ThreadError can’t create Thread Operation not permitted

can't create Thread: Operation not permitted

このエラーは、新しいglibcバージョンでビルドされたコンテナをclone3関数をサポートしないホストで実行している場合に発生します。GitLab 16.0以降では、コンテナイメージにはUbuntu 22.04 Linuxパッケージが含まれており、これは新しいglibcバージョンでビルドされています。

この問題は、Docker 20.10.10のような新しいコンテナランタイムツールでは発生しません。

この問題を解決するには、Dockerをバージョン20.10.10以降に更新してください。