メンテナンスコマンド

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

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

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)。

テールプロセスのログ

settings/logs.mdを参照してください。

起動と停止

Omnibus GitLab がインストールされ設定されると、サーバーでは runit サービスディレクトリ (runsvdir) プロセスが実行され、/etc/inittab または/etc/init/gitlab-runsvdir.conf Upstart リソースによって起動時に開始されます。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

シングルコアのサーバーでは、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 （プロセスが再起動しない場合）の一連のシグナルを送信します。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 サーバへの接続や、ローカルの Omnibus 以外の 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 ページを設置します。