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

メンテナンスコマンド

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

インストール後に以下のコマンドを実行できます。

サービスステータスの取得

sudo gitlab-ctl statusを実行して、各GitLabコンポーネントの現在の状態とアップタイムを確認します。

出力は次のようになります:

run: nginx: (pid 972) 7s; run: log: (pid 971) 7s
run: postgresql: (pid 962) 7s; run: log: (pid 959) 7s
run: redis: (pid 964) 7s; run: log: (pid 963) 7s
run: sidekiq: (pid 967) 7s; run: log: (pid 966) 7s
run: puma: (pid 961) 7s; run: log: (pid 960) 7s

例として、前の例の最初の行は次のように解釈できます:

  • Nginxはプロセス名です。
  • 972はプロセスの識別子です。
  • NGINXは7秒間実行されています (7s)。
  • logは、先行プロセスにアタッチされたsvlogdロギングプロセスを示します。
  • 971はロギングプロセスの識別子です。
  • ロギングプロセスは7秒間実行されています (7s)。

設定の表示

sudo gitlab-ctl show-configを実行して、gitlab-ctl reconfigureによって生成される設定を表示します。出力はJSON形式で、次のようになります:

{
  "gitlab": {
    "gitlab_sshd": {

    },
    "gitlab_shell": {
      "secret_token": "<SECRET_TOKEN>",
      "auth_file": "/var/opt/gitlab/.ssh/authorized_keys"
    },
    "gitlab_rails": {
      "smtp_address": "smtp.example.com",
      "smtp_port": 587,
      "smtp_user_name": "user@example.com",
      "smtp_password": "<SMTP_PASSWORD>",
      "smtp_domain": "smtp.example.com",
      "smtp_authentication": "login",
      "monitoring_whitelist": [
        "127.0.0.0/8",
        "::1/128",
      ],
   ...
    }
  }
}

GitLabが再設定された後、/var/opt/gitlabディレクトリの下にある自動生成されたYAML設定ファイルを参照して、適用された最新の設定を確認できます。上記の例では、/var/opt/gitlab/gitlab-rails/etc/gitlab.ymlの下のgitlab-railsの設定を確認できます。

プロセスログの末尾表示

Linuxパッケージインストールに関するログを参照してください。

開始と停止

Linuxパッケージがインストールおよび設定されると、サーバーには/etc/inittabまたは/etc/init/gitlab-runsvdir.conf Upstartリソースを介して起動時に開始されるrunitサービスディレクトリ (runsvdir) プロセスが実行されます。runsvdirプロセスを直接処理する必要はありません。代わりにgitlab-ctlフロントエンドを使用できます。

以下のコマンドで、GitLabとそのすべてのコンポーネントを開始、停止、または再起動できます。

# Start all GitLab components
sudo gitlab-ctl start

# Stop all GitLab components
sudo gitlab-ctl stop

# Restart all GitLab components
sudo gitlab-ctl restart

# Restart all GitLab components except given services ... (e.g. gitaly, redis)
sudo gitlab-ctl restart-except gitaly redis

シングルコアサーバーでは、PumaとSidekiqの再起動に最大1分かかる場合があります。Pumaが再び稼働するまで、GitLabインスタンスは502エラーを発生します。

個々のコンポーネントを開始、停止、または再起動することも可能です。

sudo gitlab-ctl restart sidekiq

Pumaはほぼゼロダウンタイムのリロードをサポートしています。これらは次のようにトリガーできます:

sudo gitlab-ctl hup puma

hupコマンドが完了するまで待つ必要があります。これには時間がかかる場合があります。プールからノードを外し、これが完了するまで、これが実行されるノード上のサービスを再起動しないでください。また、Pumaのリロードを使用してRubyランタイムを更新することはできません。

Pumaはアプリケーションの動作を制御するために以下のシグナルを持っています:

シグナルPuma
HUP定義されたログファイルを再度開くか、強制再起動のためにプロセスを停止します。
INTリクエスト処理を正常に停止します。
USR1ワーカーを段階的に再起動し、設定のリロードなしでローリング再起動を行います。
USR2ワーカーを再起動し、設定をリロードします。
QUITメインプロセスを終了します。

Pumaの場合、gitlab-ctl hup pumaはSIGINTとSIGTERM (プロセスが再起動しない場合) のシグナルシーケンスを送信します。SIGINTを受信するとすぐに、Pumaは新しい接続の受け入れを停止します。すべての実行中のリクエストを完了します。その後、runitがサービスを再起動します。

Rakeタスクの実行

GitLab Rakeタスクを実行するには、gitlab-rakeを使用します。例:

sudo gitlab-rake gitlab:check

gitユーザーの場合は、sudoを省略してください。

従来のGitLabインストールとは異なり、ユーザーやRAILS_ENV環境変数を変更する必要はありません。gitlab-rakeラッパースクリプトがこれを処理します。

Railsコンソールセッションを開始する

詳細については、Railsコンソールを参照してください。

PostgreSQLスーパーユーザーpsqlセッションの開始

バンドルされたPostgreSQLサービスへのスーパーユーザーアクセスが必要な場合は、gitlab-psqlコマンドを使用できます。通常のpsqlコマンドと同じ引数を受け取ります。

# Superuser psql access to GitLab's database
sudo gitlab-psql -d gitlabhq_production

これは、gitlab-ctl reconfigureを少なくとも1回実行した後にのみ機能します。gitlab-psqlコマンドは、リモートPostgreSQLサーバーへの接続、またはローカルの非LinuxパッケージPostgreSQLサーバーへの接続には使用できません。

GeoトラッキングデータベースでのPostgreSQLスーパーユーザーpsqlセッションの開始

前のコマンドと同様に、バンドルされたGeoトラッキングデータベース (geo-postgresql) へのスーパーユーザーアクセスが必要な場合は、gitlab-geo-psqlを使用できます。通常のpsqlコマンドと同じ引数を受け取ります。HAについては、設定の確認で必要な引数の詳細を参照してください。

# Superuser psql access to GitLab's Geo tracking database
sudo gitlab-geo-psql -d gitlabhq_geo_production

コンテナレジストリのガベージコレクション

コンテナレジストリはかなりのディスク容量を使用する可能性があります。未使用のレイヤーをクリアするために、レジストリにはガベージコレクションコマンドが含まれています。

GitLabへのユーザーログインを制限する

GitLabへのユーザーログインを一時的に制限する必要がある場合は、sudo gitlab-ctl deploy-page upを使用できます。ユーザーがGitLab URLにアクセスすると、任意のDeploy in progressページが表示されます。

ページを削除するには、sudo gitlab-ctl deploy-page downを実行するだけです。また、sudo gitlab-ctl deploy-page statusを使用してデプロイページのステータスを確認することもできます。

補足として、GitLabへのログインを制限し、プロジェクトへの変更を制限したい場合は、プロジェクトを読み取り専用に設定し、その後にDeploy in progressページを公開できます。

シークレットファイルのローテーション

セキュリティ上の理由で必要な場合は、/etc/gitlab/gitlab-secrets.jsonシークレットファイルをローテーションできます。このファイルでは:

  • gitlab_railsシークレットはデータベース暗号化キーを含むため、ローテーションしないでください。このシークレットがローテーションされた場合、シークレットファイルが失われたときと同じ動作になります。
  • その他のすべてのシークレットをローテーションできます。

GitLab環境に複数のノードがある場合は、初期手順を実行するRailsノードの1つを選択してください。

シークレットをローテーションするには:

  1. データベース値が復号化できることを確認し、表示された復号化エラーをメモするか、続行する前にそれらを解決してください。

  2. 推奨。gitlab_railsの現在のシークレットを抽出します。後で必要になるため、出力を保存してください:

    sudo grep "secret_key_base\|db_key_base\|otp_key_base\|encrypted_settings_key_base\|openid_connect_signing_key\|active_record_encryption_primary_key\|active_record_encryption_deterministic_key\|active_record_encryption_key_derivation_salt" /etc/gitlab/gitlab-secrets.json

  3. 現在のシークレットファイルを別の場所に移動します:

    sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old

  4. GitLabを再設定します。GitLabは、新しいシークレット値を持つ新しい/etc/gitlab/gitlab-secrets.jsonファイルを生成します。

  5. gitlab_railsの以前のシークレットを抽出した場合は、新しい/etc/gitlab/gitlab-secrets.jsonファイルを編集し、gitlab_railsの下のキー/バリューペアを、以前に取得したシークレット出力に置き換えます。

  6. GitLabを再設定して、シークレットファイルに加えられた変更を適用します。

  7. GitLabを再起動して、すべてのサービスが新しいシークレットを使用していることを確認します。

  8. GitLab環境に複数のノードがある場合は、シークレットを他のすべてのノードにコピーする必要があります:

    1. 他のすべてのノードで、現在のシークレットファイルを別の場所に移動します:

      sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old

    2. 新しい/etc/gitlab/gitlab-secrets.jsonファイルをRailsノードから他のすべてのGitLabノードにコピーします。

    3. 他のすべてのノードで、各ノードでGitLabを再設定します。

    4. 他のすべてのノードで、各ノードでGitLabを再起動して、すべてのサービスが新しいシークレットを使用していることを確認します。

    5. すべてのノードで、/etc/gitlab/gitlab-secrets.jsonファイルに対してチェックサム照合を実行し、シークレットが一致することを確認します:

      sudo md5sum /etc/gitlab/gitlab-secrets.json

  9. データベース値が復号化できることを確認します。出力は以前の実行と一致するはずです。

  10. GitLabが期待どおりに動作していることを確認します。そうであれば、古いシークレットを削除しても安全です。

gitlab-ctlのbash補完を有効にする

Linuxパッケージには、gitlab-ctlコマンド用のbash補完スクリプトが含まれています。これを有効にするには、Shell設定ファイルで補完スクリプトをソースします。

補完スクリプトは/opt/gitlab/embedded/share/bash-completion/completions/gitlab-ctl-bash-completionにあります。

bash補完を有効にするには:

  1. 以下の行をShell設定ファイル (.bashrc、.bash_profile、または同等のもの) に追加します:

    source /opt/gitlab/embedded/share/bash-completion/completions/gitlab-ctl-bash-completion

  2. Shell設定をリロードします:

    source ~/.bashrc

有効にした後、gitlab-ctlコマンドでタブ補完を使用できます:

gitlab-ctl <TAB>

補完スクリプトには、bash-completionパッケージがシステムにインストールされている必要があります。インストールされていない場合は、システムのパッケージマネージャーを使用してインストールできます:

  • Debian/Ubuntu: sudo apt-get install bash-completion
  • RHEL/CentOS: sudo yum install bash-completion

非推奨

sudo gitlab-ctl check-configを実行して、将来のGitLabバージョンで削除されるフラグがないかOmnibus設定を確認します。

このコマンドは以下の引数をサポートしています:

  • --version <Version>: 設定を確認したいターゲットGitLabバージョン。
  • --no-fail: 非推奨事項/削除事項が見つかった場合でも、失敗codeで終了しないようにします。

GitLabをアップグレードすると、この設定チェックは自動的に実行されます。アップグレード中にこのチェックをスキップしたい場合は、/etc/gitlab/skip-fail-config-checkにファイルを作成します。