• オムニバス設備
  • オムニバスGitLab再起動
  • Omnibus GitLab の再構成
• ソースからのインストール
• Helmチャートのインストール

GitLabを再起動する方法

GitLabのインストール方法によって、サービスを再起動する方法が異なります。

TL;DRバージョンをお望みなら、こちらへジャンプしてください：

• オムニバスGitLab再起動
• Omnibus GitLab の再構成
• ソースインストール再起動
• Helmチャートインストール再起動

オムニバス設備

Omnibus パッケージを使ってGitLab をインストールしたのであれば、PATHにgitlab-ctl がすでにあるはずです。

gitlab-ctl はOmnibusパッケージと相互作用し、GitLab Railsアプリケーション(Puma)だけでなく、他のコンポーネントも再起動させることができます：

• GitLabの主力製品
• Sidekiq
• PostgreSQL (バンドルされているものを使用している場合)
• Nginx (バンドルされているものを使用している場合)
• Redis (バンドルされているものを使用している場合)
• メールルーム
• ログロテート

オムニバスGitLab再起動

ドキュメントの中で、GitLabの_再起動を_求められることがあるかもしれません。 その場合は、以下のコマンドを実行してください：

sudo gitlab-ctl restart

出力はこのようになるはずです：

ok: run: gitlab-workhorse: (pid 11291) 1s
ok: run: logrotate: (pid 11299) 0s
ok: run: mailroom: (pid 11306) 0s
ok: run: nginx: (pid 11309) 0s
ok: run: postgresql: (pid 11316) 1s
ok: run: redis: (pid 11325) 0s
ok: run: sidekiq: (pid 11331) 1s
ok: run: puma: (pid 11338) 0s

コンポーネントを個別に再起動するには、restart コマンドにそのサービス名を追加します。 たとえば、Nginxのみを再起動するには、次のように実行します：

sudo gitlab-ctl restart nginx

GitLab サービスのステータスを確認するには、以下を実行します：

sudo gitlab-ctl status

すべてのサービスがok: runと表示されていることに注意してください。

再起動中にコンポーネントがタイムアウトしたり（ログでtimeout を探す）、動かなくなったりすることがあります。そのような場合は、gitlab-ctl kill <service> を使ってSIGKILLシグナルをサービスに送ります（例：sidekiq）。 その後、再起動は問題なく実行されるはずです。

最後の手段として、GitLabを再設定することもできます。

Omnibus GitLab の再構成

ドキュメントの中で GitLab の_再設定を_求められることがあるかもしれません。 この方法は Omnibus パッケージにのみ適用されることを覚えておいてください。

でOmnibus GitLabを再設定します：

sudo gitlab-ctl reconfigure

GitLabの再設定は、GitLabの設定(/etc/gitlab/gitlab.rb)が変更されたイベントに発生するはずです。

このコマンドを実行すると、Omnibus GitLabを動かす根本的な設定管理アプリケーションであるChefが、ディレクトリや権限、サービスなどのすべてのものが、最初に出荷されたときと同じ状態にあることを確認します。

また、GitLabコンポーネントの設定ファイルが変更された場合、必要に応じて再起動します。

/var/opt/gitlab 、Chefによって管理されているファイルを手動で編集した場合、reconfigureを実行すると変更が戻され、それらのファイルに依存しているサービスが再起動されます。

ソースからのインストール

公式のインストールガイドに従ってソースからGitLabをインストールした場合は、以下のコマンドを実行してGitLabを再起動してください：

sudo service gitlab restart

出力はこのようになるはずです：

Shutting down GitLab Puma
Shutting down GitLab Sidekiq
Shutting down GitLab Workhorse
Shutting down GitLab MailRoom
...
GitLab is not running.
Starting GitLab Puma
Starting GitLab Sidekiq
Starting GitLab Workhorse
Starting GitLab MailRoom
...
The GitLab Puma web server with pid 28059 is running.
The GitLab Sidekiq job dispatcher with pid 28176 is running.
The GitLab Workhorse with pid 28122 is running.
The GitLab MailRoom email processor with pid 28114 is running.
GitLab and all its components are up and running.

これで、Puma、Sidekiq、GitLab Workhorse、Mailroom（有効になっている場合）が再起動されます。すべてのマジックを実行する init サービスファイルは、サーバーの/etc/init.d/gitlabにあります。

systemdのような他のinitシステムを使っている場合は、GitLab Recipesリポジトリで非公式のサービスをチェックできます。 これらは公式にはサポートされていないので、自己責任で使ってください。

Helmチャートのインストール

クラウドネイティブのHelm Chart経由でインストールしたGitLabアプリケーション全体を再起動する単一のコマンドはありません。 通常は、特定のコンポーネント（例えば、gitaly、puma、workhorse、gitlab-shell）を個別に再起動するには、そのコンポーネントに関連するすべてのポッドを削除すれば十分です：

kubectl delete pods -l release=<helm release name>,app=<component name>

リリース名はhelm list コマンドの出力から取得できます。