GitLab Dockerイメージ

GitLab DockerイメージはGitLabのモノリシックなイメージで、必要なサービスを一つのコンテナで実行します。

GitLab公式Dockerイメージは以下から：

Dockerイメージにはメールトランスポートエージェント(MTA) が含まれていません。推奨される解決策は、別のコンテナで動作するMTA（PostfixやSendmailなど）を追加することです。別の方法として、GitLabコンテナに直接MTAをインストールすることもできますが、アップグレードや再起動のたびにMTAを再インストールする必要があるため、メンテナンスのオーバーヘッドが増えます。

以下の例では、最新の RC イメージを使いたい場合はgitlab/gitlab-ee:rc を代わりに使います。

GitLabのDockerイメージをKubernetesにデプロイすることは、単一障害点となるため避けるべきです。KubernetesでGitLabをデプロイしたい場合は、代わりにGitLab Helm ChartまたはGitLab Operatorを使用してください。

caution
Docker for Windowsは公式にはサポートされていません。ボリューム権限に関する既知のイシューがあり、その他の未知の問題がある可能性もあります。Docker for Windowsで実行しようとしている場合、他のユーザーに助けを求めるためのコミュニティリソース（IRCやフォーラムなど）へのリンクについては、geting helpのページを参照してください。

前提条件

Dockerが必要です。公式のインストールドキュメントを参照してください。

ボリュームの場所の設定

他のすべてを設定する前に、設定、ログ、およびデータファイルが存在するディレクトリを指す新しい環境変数$GITLAB_HOME を設定します。そのディレクトリが存在し、適切な権限が付与されていることを確認してください。

Linuxユーザーの場合は、パスを/srv/gitlab に設定します：

export GITLAB_HOME=/srv/gitlab

MacOSユーザーの場合は、ユーザーの$HOME/gitlab ディレクトリを使用します：

export GITLAB_HOME=$HOME/gitlab

GITLAB_HOME 環境変数をシェルのプロファイルに追加して、今後すべてのターミナル・セッションで適用されるようにしてください：

  • Bash：~/.bash_profile
  • ZSH：~/.zshrc

GitLabコンテナは、永続的なデータを保存するためにホストにマウントされたボリュームを使用します：

ローカルロケーションコンテナロケーション使用方法
$GITLAB_HOME/data/var/opt/gitlabアプリケーションデータの保存
$GITLAB_HOME/logs/var/log/gitlabログの保存
$GITLAB_HOME/config/etc/gitlabGitLab設定ファイルの保存。

インストール

GitLab Dockerイメージは複数の方法で実行できます：

Dockerエンジンを使ったGitLabのインストール

これらのディレクトリは、あなたの要件に合わせて微調整できます。GITLAB_HOME 変数を設定したら、イメージを実行します：

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

GitLabコンテナをダウンロードして起動し、SSH、HTTP、HTTPSへのアクセスに必要なポートを公開します。すべてのGitLabデータは、$GITLAB_HOME のサブディレクトリとして保存されます。コンテナは、システムの再起動後に自動的にrestart 。

SELinuxを使っている場合は、代わりにこれを実行してください：

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab:Z \
  --volume $GITLAB_HOME/logs:/var/log/gitlab:Z \
  --volume $GITLAB_HOME/data:/var/opt/gitlab:Z \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

これはDockerプロセスがマウントされたボリュームに設定ファイルを作成するのに十分な権限を持っていることを確認します。

Kerberosインテグレーションを使用している場合は、Kerberosポートも公開する必要があります。 (PREMIUM ONLY)を使用している場合は、Kerberosポートも公開する必要があります（例えば、--publish 8443:8443）。これを怠ると、Kerberosを使ったGitオペレーションができなくなります。

初期化には長い時間がかかります。このプロセスは

sudo docker logs -f gitlab

コンテナを起動した後、gitlab.example.com （MacOSでboot2dockerを使用した場合はhttp://192.168.59.103 ）にアクセスできます。Dockerコンテナがクエリに応答し始めるまでに時間がかかる場合があります。

GitLabのURLにアクセスし、ユーザー名root 、パスワードは以下のコマンドでサインインします：

sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password
note
パスワードファイルは、24時間後の最初の再設定実行時に自動的に削除されます。

Docker Composerを使ったGitLabのインストール

Docker Composerを使えば、DockerベースのGitLabの設定、インストール、アップグレードを簡単に行うことができます：

  1. Docker Composerをインストールします。

  2. docker-compose.yml ：

    version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.example.com'
        # Add any other gitlab.rb configuration here, each on its own line
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

  3. docker-compose.yml と同じディレクトリにいることを確認し、GitLabを起動します：

    docker compose up -d
note
Dockerコンテナの事前設定」セクションを読んで、GITLAB_OMNIBUS_CONFIG 変数の動作を確認してください。

以下は、GitLabをカスタムHTTPポートとSSHポートで動作させたdocker-compose.yml 。GITLAB_OMNIBUS_CONFIG の変数がports のセクションと一致していることに注目してください：

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com:8929'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    ports:
      - '8929:8929'
      - '2224:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

これは--publish 8929:8929 --publish 2224:22 を使った場合と同じです。

GitLab を Docker swarm モードでインストールします。

Docker swarmモードを使えば、DockerベースのGitLabインストールを簡単に設定し、swarmクラスターにデプロイすることができます。

swarmモードでは、Dockerシークレットと Docker設定を活用して、効率的かつセキュアにGitLabインスタンスをデプロイすることができます。シークレットは、環境変数として公開することなく、初期rootパスワードを安全に渡すために使用できます。設定はGitLabイメージを可能な限り汎用的なものに保つのに役立ちます。

以下は、シークレットと設定を使って4つのランナーをスタックとしてGitLabをデプロイする例です：

  1. Docker swarmをセットアップします。

  2. docker-compose.yml ：

    version: "3.6"
services:
  gitlab:
    image: gitlab/gitlab-ee:latest
    ports:
      - "22:22"
      - "80:80"
      - "443:443"
    volumes:
      - $GITLAB_HOME/data:/var/opt/gitlab
      - $GITLAB_HOME/logs:/var/log/gitlab
      - $GITLAB_HOME/config:/etc/gitlab
    shm_size: '256m'
    environment:
      GITLAB_OMNIBUS_CONFIG: "from_file('/omnibus_config.rb')"
    configs:
      - source: gitlab
        target: /omnibus_config.rb
    secrets:
      - gitlab_root_password
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    deploy:
      mode: replicated
      replicas: 4
configs:
  gitlab:
    file: ./gitlab.rb
secrets:
  gitlab_root_password:
    file: ./root_password.txt

    簡単のため、network の設定は省略しました。詳しくはComposer ファイルの公式リファレンスを参照してください。

  3. gitlab.rb ：

    external_url 'https://my.domain.com/'
gitlab_rails['initial_root_password'] = File.read('/run/secrets/gitlab_root_password').gsub("\n", "")

  4. root_password.txt ：

    MySuperSecretAndSecurePassw0rd!

  5. docker-compose.yml と同じディレクトリにいることを確認し、実行してください：

    docker stack deploy --compose-file docker-compose.yml mystack

設定

このコンテナは公式 Linux パッケージを使用しているため、すべての設定は独自の設定ファイル/etc/gitlab/gitlab.rb で行います。

GitLab 設定ファイルにアクセスするには、実行中のコンテナのコンテキストで Shell セッションを開始します。これで、すべてのディレクトリをブラウズしたりお気に入りのテキストエディタを使ったりできるようになります：

sudo docker exec -it gitlab /bin/bash

/etc/gitlab/gitlab.rbを編集することもできます：

sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb

/etc/gitlab/gitlab.rb を開いたら、external_url が有効な URL を指すように設定してください。

GitLab DockerイメージにはSMTPサーバーがインストールされていないため、GitLabからのメールを受信するにはSMTPの設定を行う必要があります。HTTPSを有効にすることにも興味があるかもしれません。

必要な変更をすべて行ったら、コンテナを再起動して GitLab を再設定する必要があります：

sudo docker restart gitlab

GitLab はコンテナが起動するたびに自分自身を再設定します。GitLab の設定に関するオプションについては、設定ドキュメントを確認してください。

Dockerコンテナの事前設定

GITLAB_OMNIBUS_CONFIG Docker runコマンドに GITLAB_OMNIBUS_CONFIG環境変数を追加することで、GitLab Dockerイメージを事前に設定することができます。GITLAB_OMNIBUS_CONFIG この変数には任意の設定を含めることがgitlab.rb でき、コンテナの gitlab.rbファイルをgitlab.rb ロードする前に評価さ gitlab.rbれます。この動作により、外部のGitLab URLを設定したり、データベースの設定やその他のオプションをLinuxパッケージテンプレートから作成することができます。この変数に含まれる設定は GITLAB_OMNIBUS_CONFIG gitlab.rb 設定ファイルには書き込まれず、ロード時に評価されます。

コンテナの起動時に外部 URL を設定し、LFS を有効にする例を示します：

sudo docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://my.domain.com/'; gitlab_rails['lfs_enabled'] = true;" \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

docker run コマンドを実行するたびに、GITLAB_OMNIBUS_CONFIG オプションを GITLAB_OMNIBUS_CONFIG指定する必要があります。コマンドを実行するたびに、オプションを指定する必要がありますGITLAB_OMNIBUS_CONFIG 。 GITLAB_OMNIBUS_CONFIG

GitLab のタグ付きバージョンを使う

GitLab Docker イメージのタグ付きバージョンも提供されています。全てのタグを見るには

特定のタグ付きバージョンを使うには、gitlab/gitlab-ee:latest を実行したい GitLab バージョンに置き換えてください。例えば、gitlab/gitlab-ee:12.1.3-ce.0.

公開IPアドレスでGitLabを実行するには

--publish フラグを変更することで、Docker に自分の IP アドレスを使わせて GitLab コンテナに全てのトラフィックを転送させることができます。

IPでGitLabを公開するには198.51.100.1 ：

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 198.51.100.1:443:443 \
  --publish 198.51.100.1:80:80 \
  --publish 198.51.100.1:22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

GitLabインスタンスには、http://198.51.100.1/ とhttps://198.51.100.1/ からアクセスできます。

異なるポートで GitLab を公開

GitLabはコンテナ内でいくつかのポートを占有します。

80 (HTTP) や443 (HTTPS)とは別のホスト・ポートを使いたい場合は、docker run コマンドに--publish ディレクティブを追加する必要があります。

例えば、ウェブインターフェースをホストのポート8929 で公開し、SSHサービスをポート2289 で公開する場合です：

  1. 次のdocker run コマンドを使用します：

    sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 8929:8929 --publish 2289:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest
    note
    ポートを公開するフォーマットはhostPort:containerPort です。Dockerのドキュメントで、受信ポートの公開について詳しくお読みください。

  2. 実行中のコンテナに入ります：

    sudo docker exec -it gitlab /bin/bash

  3. エディタで/etc/gitlab/gitlab.rb を開き、external_url ：

    # For HTTP
external_url "http://gitlab.example.com:8929"
   
or
   
# For HTTPS (notice the https)
external_url "https://gitlab.example.com:8929"

    このURLで指定されたポートは、Dockerによってホストに公開されたポートと一致する必要があります。さらに、NGINXのリッスンポートがnginx['listen_port'] で明示的に設定されていない場合は、external_url から取得されます。 詳細については、NGINXのドキュメントを参照してください。

  4. gitlab_shell_ssh_port を設定します：

    gitlab_rails['gitlab_shell_ssh_port'] = 2289

  5. 最後に GitLab を再設定します：

    gitlab-ctl reconfigure

上記の例に従うと、GitLab にウェブブラウザから<hostIP>:8929 でアクセスし、SSH を使って2289 というポートでプッシュできるようになります。

異なるポートを使うdocker-compose.yml の例はDocker Composerセクションにあります。

複数のデータベース接続の設定

GitLab 16.0では、GitLabはデフォルトで同じPostgreSQLデータベースを指す2つのデータベース接続を使用します。

何らかの理由で1つのデータベース接続に戻したい場合は、以下のようにします：

  1. コンテナ内部で/etc/gitlab/gitlab.rb を編集します：

    sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb

  2. 以下の行を追加します：

    gitlab_rails['databases']['ci']['enable'] = false

  3. コンテナを再起動します：

sudo docker restart gitlab

インストールが完了したら、認証オプションやサインアップの制限など、推奨される次のステップに進むことを検討してください。

アップグレード

ほとんどの場合、GitLabのアップグレードは最新のDockerイメージタグをダウンロードするのと同じくらい簡単です。

Docker Engineを使ったGitLabのアップグレード

Docker Engineを使ってインストールしたGitLabをアップグレードします：

  1. バックアップを取ってください。最低限、データベースとGitLabのシークレットファイルをバックアップしてください。

  2. 実行中のコンテナを停止します：

    sudo docker stop gitlab

  3. 既存のコンテナを削除します：

    sudo docker rm gitlab

  4. 新しいイメージを取り出します。例えば、最新のGitLabイメージ：

    sudo docker pull gitlab/gitlab-ee:latest

  5. GITLAB_HOME 環境変数が定義されていることを確認します：

    echo $GITLAB_HOME

  6. 前回指定したオプションを使用してコンテナをもう一度作成します：

    sudo docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume $GITLAB_HOME/config:/etc/gitlab \
--volume $GITLAB_HOME/logs:/var/log/gitlab \
--volume $GITLAB_HOME/data:/var/opt/gitlab \
--shm-size 256m \
gitlab/gitlab-ee:latest

最初の実行で、GitLab は自分自身を再設定してアップグレードします。

バージョン間のアップグレードはGitLabUpgrade recommendationsを参照してください。

Docker composerを使ったGitLabのアップグレード

Docker Composerを使ってインストールしたGitLabをアップグレードします：

  1. バックアップを取ってください。最低限、データベースとGitLabのシークレットファイルをバックアップしてください。

  2. 最新リリースをダウンロードし、GitLabインスタンスをアップグレードしましょう：

    docker compose pull
docker compose up -d

    タグを代わりに使っている場合は、まずdocker-compose.yml を編集する必要があります。

コミュニティ版からエンタープライズ版への変換

既存のDockerベースのGitLab Community Edition(CE) コンテナをGitLabEnterprise Edition (EE) コンテナに変換するには、バージョンのアップグレードと同じ方法を使用します。

同じバージョンのCEからEEに変換することをお勧めします（例えば、CE 14.1からEE 14.1）。これは明示的に必要なことではなく、標準的なアップグレード（たとえば、CE 14.0 から EE 14.1）であれば問題ありません。以下の手順は、同じバージョンをアップグレードすることを前提としています。

  1. バックアップを取ってください。最低限、データベースとGitLabのシークレットファイルをバックアップしてください。

  2. 現在のCEコンテナを停止し、削除するか名前を変更します。

  3. GitLab EE で新しいコンテナを作成するには、docker run コマンドまたはdocker-compose.yml ファイルのce をee に置き換えます。ただし、CE コンテナ名、ポートとファイルのマッピング、バージョンは再利用します。

GitLabのダウングレード

アップグレード後にGitLabをダウングレードするには：

  1. アップグレード手順に従いますが、latest の代わりに元のバージョンのGitLabのタグを指定します。

  2. アップグレードの一環として作成したデータベースのバックアップを復元します。

    • リストアは、アップグレードの一環として行われたデータベース データとスキーマの変更（マイグレーション）をバックアップするために必要です。
    • GitLabバックアップは全く同じバージョンとエディションにリストアする必要があります。
    • PumaとSidekiqの停止を含め、Dockerイメージのリストア手順に従ってください。データベースのみをリストアする必要があるため、gitlab-backup restore のコマンドライン引数にSKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state を追加してください。

GitLabのバックアップ

GitLabのバックアップは、次のようにして作成できます：

docker exec -t <container name> gitlab-backup create

GitLabのバックアップとリストア方法についてはこちらをご覧ください。

note
Dockerコンテナの事前設定」の手順で）環境変数GITLAB_OMNIBUS_CONFIG を使って設定を行う場合、つまりファイルに直接設定を行わないgitlab.rb 場合は、 gitlab.rbファイルをバックアップする必要はありません。
caution
GitLabのシークレットファイルをバックアップすることは、GitLabをバックアップからリカバリーする際に複雑な手順を避けるために必要です。シークレットファイルはコンテナ内部の/etc/gitlab/gitlab-secrets.json 、またはコンテナホストの$GITLAB_HOME/config/gitlab-secrets.json 。

データベースのバックアップを作成

イシューが発生した場合、GitLabアップグレードをロールバックするにはデータベースのバックアップが必要です。

docker exec -t <container name> gitlab-backup create SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state

バックアップは/var/opt/gitlab/backups 、Dockerによってマウントされたボリュームに書き込まれます。

GitLab Community Editionのインストール

GitLab CE Dockerイメージ

Community Editionをインストールするには、このページのコマンドのee をce に置き換えてください。

トラブルシューティング

LinuxパッケージとDockerを使用したインストールで問題が発生した場合、以下の情報が役立ちます。

潜在的な問題の診断

コンテナのログを読む

sudo docker logs gitlab

実行中のコンテナに入ります：

sudo docker exec -it gitlab /bin/bash

コンテナ内からは、Linux パッケージのインストールを管理するのと同じように GitLab コンテナを管理することができます。

500 内部エラー

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

sudo docker restart gitlab

権限の問題

古いGitLab Dockerイメージからアップデートする際、権限の問題に遭遇することがあります。これは以前のイメージのユーザーが正しく保存されていない場合に起こります。全てのファイルの権限を修正するスクリプトがあります。

コンテナを修正するには、update-permissions を実行し、その後コンテナを再起動してください：

sudo docker exec gitlab update-permissions
sudo docker restart gitlab

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

このエラーは、WindowsまたはMac上のVirtualBoxでDocker Toolboxを使用し、Dockerボリュームを使用すると発生します。/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のヘルスとパフォーマンスに関する様々な統計情報を公開するためのPrometheusメトリクスエンドポイントが/-/metrics 。このために必要なファイルは一時ファイルシステム（/run や/dev/shm など）に書き込まれます。

デフォルトでは、Dockerは共有メモリディレクトリ（/dev/shmにマウント）に64MBを割り当てます。これでは生成される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メトリクスを無効にする以外に、この問題を解決するために推奨される方法は、共有メモリのサイズを256MB以上に増やすことです。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

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

ThreadError can’t create Thread オペレーションが許可されていません。 

can't create Thread: Operation not permitted

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

この問題は、Docker 20.10.10のような新しいコンテナランタイムツールでは修正されています。

このイシューを解決するには、Dockerをバージョン20.10.10以降にアップデートしてください。