メンテナンスコマンド

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

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

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

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

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設定ファイルを参照して、適用された最新の設定を確認できます。上記の例では、gitlab-railsの設定を/var/opt/gitlab/gitlab-rails/etc/gitlab.ymlで確認できます。

末尾のプロセスログ

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の場合、gitlab-ctl hup pumaは、SIGINTおよびSIGTERM（プロセスが再起動しない場合）シグナルのシーケンスを送信します。Pumaは、SIGINTを受信するとすぐに、新しい接続の受け入れを停止します。実行中のすべてのリクエストを完了します。次に、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コマンドと同じ引数を取ります。高可用性については、必要な引数の詳細について、Checking Configuration（設定の確認）を参照してください。

# 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. Railsノードから他のすべてのGitLabノードに新しい/etc/gitlab/gitlab-secrets.jsonファイルをコピーします。

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

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

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

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

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

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

非推奨

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

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

• --version <Version>: 設定をチェックする対象のターゲットGitLabバージョン。
• --no-fail: 非推奨/削除が見つかった場合でも、失敗コードで終了しないようにします。

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