• GitLab とシステム情報の収集
• GitLab ライセンス情報の表示
• GitLab 設定の確認
• authorized_keys ファイルの再構築
• Redisキャッシュのクリア
• アセットのプリコンパイル
• リモート・サイトへのTCP接続の確認
• 明確な専用リース(DANGER)
• データベースマイグレーションのステータスの表示
• 不完全なデータベースマイグレーションの実行
• データベースインデックスの再構築
  • 備考
• データベース スキーマのダンプ
• 一般的なメトリクスのインポート
• トラブルシューティング
  • アドバイザリーロック接続情報

メンテナンス・レーキ作業

GitLabは一般的なメンテナンスのためにRakeタスクを提供しています。

GitLab とシステム情報の収集

このコマンドはGitLabのインストールとそのシステムに関する情報を収集します。これらは、ヘルプを求めたりイシューをレポーターしたりするときに役に立つかもしれません。複数ノード環境では、PostgreSQLソケットエラーを避けるためにGitLab Railsが動いているノードでこのコマンドを実行してください。

• Linux パッケージのインストール：

   sudo gitlab-rake gitlab:env:info
  

• セルフコンパイルによるインストール：

   bundle exec rake gitlab:env:info RAILS_ENV=production
  

出力例です：

System information
System:         Ubuntu 20.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.7.6p219
Gem Version:    3.1.6
Bundler Version:2.3.15
Rake Version:   13.0.6
Redis Version:  6.2.7
Sidekiq Version:6.4.2
Go Version:     unknown

GitLab information
Version:        15.5.5-ee
Revision:       5f5109f142d
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     13.8
URL:            https://app.gitaly.gcp.gitlabsandbox.net
HTTP Clone URL: https://app.gitaly.gcp.gitlabsandbox.net/some-group/some-project.git
SSH Clone URL:  git@app.gitaly.gcp.gitlabsandbox.net:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        14.12.0
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
- gitaly:       /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell


Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      15.5.5
- default Git Version:  2.37.1.gl1
- gitaly Address:       tcp://10.128.20.6:2305
- gitaly Version:       15.5.5
- gitaly Git Version:   2.37.1.gl1

GitLab ライセンス情報の表示

• GitLab 12.6 で導入されました。
• 13.9でGitLab Premiumに移行しました。

このコマンドは、GitLabライセンスの情報と使用されているシート数を表示します。このコマンドはGitLab Enterpriseインストールでのみ利用可能です。GitLab Community Editionにライセンスをインストールすることはできません。

これらの情報は、サポートにチケットを発行するときや、プログラムでライセンスパラメータをチェックするときに便利です。

• Linux パッケージのインストール：

   sudo gitlab-rake gitlab:license:info
  

• セルフコンパイルによるインストール：

   bundle exec rake gitlab:license:info RAILS_ENV=production
  

出力例です：

Today's Date: 2020-02-29
Current User Count: 30
Max Historical Count: 30
Max Users in License: 40
License valid from: 2019-11-29 to 2020-11-28
Email associated with license: user@example.com

GitLab 設定の確認

gitlab:check Rakeタスクは以下のRakeタスクを実行します：

• gitlab:gitlab_shell:check
• gitlab:gitaly:check
• gitlab:sidekiq:check
• gitlab:incoming_email:check
• gitlab:ldap:check
• gitlab:app:check

各コンポーネントがインストールガイドに従ってセットアップされているかをチェックし、見つかったイシューの修正を提案します。このコマンドはアプリケーションサーバーから実行する必要があり、Gitaly のようなコンポーネントサーバーでは正しく動作しません。Geo を実行している場合は、Geo Health check Rake タスクも参照してください。

また、以下のトラブルシューティングガイドもご覧ください：

• GitLab.
• Linuxパッケージ・インストール。

さらに、データベースの値が現在のシークレットを使用して復号化できることも確認する必要があります。

gitlab:check を実行します：

• Linux パッケージのインストール：

   sudo gitlab-rake gitlab:check
  

• セルフコンパイルによるインストール：

   bundle exec rake gitlab:check RAILS_ENV=production
  

出力からプロジェクト名を省略したい場合は、gitlab:check にSANITIZE=true を使用してください。

出力例です：

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version? ... OK (1.2.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... yes
post-receive hooks in repos are links: ... yes

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Redis version >= 2.0.0? ... yes

Checking GitLab ... Finished

authorized_keys ファイルの再構築

authorized_keys 例えば、アップグレード後にSSH 経由でプッシュする際にPermission denied (publickey) を受信し、404 Key Not Found のエラーをgitlab-shell.log のファイルで見つけた場合などです。authorized_keysを再構築するには、以下を実行してください：

• Linux パッケージのインストール：

   sudo gitlab-rake gitlab:shell:setup
  

• セルフコンパイルによるインストール：

   cd /home/git/gitlab
   sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
  

出力例です：

This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes

Redisキャッシュのクリア

何らかの理由でダッシュボードに間違った情報が表示される場合は、Redisのキャッシュをクリアするとよいでしょう。これを行うには、以下を実行します：

• Linux パッケージのインストール：

   sudo gitlab-rake cache:clear
  

• セルフコンパイルによるインストール：

   cd /home/git/gitlab
   sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
  

アセットのプリコンパイル

バージョンアップの際に、CSSがおかしくなってしまったり、アイコンがなくなってしまったりすることがあります。そのような場合は、もう一度アセットをプリコンパイルしてみてください。

この Rake タスクはセルフコンパイルしたインストールにのみ適用されます。Linux パッケージを実行する際のこの問題のトラブルシューティングについては、こちらを参照してください。Linuxパッケージのガイダンスは、GitLabのKubernetesやDockerデプロイにも当てはまるかもしれませんが、一般的にコンテナベースのインストールではアセットが見つからないというイシューは発生しません。

• セルフコンパイルによるインストール：

   cd /home/git/gitlab
   sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
  

Linuxパッケージのインストールでは、最適化されていないアセット（JavaScript、CSS）はアップストリームGitLabのリリース時に凍結されます。Linux パッケージのインストールには、これらのアセットの最適化バージョンが含まれます。パッケージをインストールした後に本番マシンで JavaScript / CSS コードを修正しない限り、本番マシンでrake gitlab:assets:compile をやり直す理由はないはずです。アセットの破損が疑われる場合は、Linuxパッケージを再インストールしてください。

リモート・サイトへのTCP接続の確認

GitLabインストールが他のマシンのTCPサービス（例えばPostgreSQLやWebサーバー）に接続できるかどうかをプロキシの問題をトラブルシュートするために知りたいことがあります。このような場合に役立つRakeタスクが含まれています。

• Linux パッケージのインストール：

   sudo gitlab-rake gitlab:tcp_check[example.com,80]
  

• セルフコンパイルによるインストール：

   cd /home/git/gitlab
   sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
  

明確な専用リース(DANGER)

GitLabは共有ロックメカニズムExclusiveLease 、共有リソースでの同時オペレーションを防ぎます。例として、リポジトリに対して定期的にガベージコレクションを実行することが挙げられます。

非常に特殊な状況では、排他リースによってロックされたオペレーションがロックをリリースせずに失敗することがあります。有効期限が切れるのを待てない場合は、このタスクを実行して手動でロックを解除してください。

すべての排他リースを消去するには

sudo gitlab-rake gitlab:exclusive_lease:clear

リースtype またはリースtype + id を指定するには、スコープを指定します：

# to clear all leases for repository garbage collection:
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]

# to clear a lease for repository garbage collection in a specific project: (id=4)
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]

データベースマイグレーションのステータスの表示

GitLabをアップグレードする際にマイグレーションが完了したことを確認する方法については、バックグラウンドマイグレーションのドキュメントを参照してください。

特定のマイグレーションのステータスを確認するには、次の Rake タスクを使います：

sudo gitlab-rake db:migrate:status

Geo セカンダリサイトのトラッキングデータベースを確認するには、以下の Rake タスクを使用できます：

sudo gitlab-rake db:migrate:status:geo

これは、マイグレーション ID ごとにup またはdown のStatus を持つテーブルを出力します。

database: gitlabhq_production

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     migration_id    migration_name

不完全なデータベースマイグレーションの実行

データベースマイグレーションは、sudo gitlab-rake db:migrate:status コマンドの出力にdown ステータスが表示され、不完全な状態で立ち往生することがあります。

1. これらのマイグレーションを完了するには、以下のRakeタスクを使用してください：

   sudo gitlab-rake db:migrate
   

2. コマンドが完了したら、sudo gitlab-rake db:migrate:status を実行して、すべてのマイグレーションが完了したかどうか（up ステータスがあるかどうか）を確認します。

3. ホットリロードpuma およびsidekiq サービス：

   sudo gitlab-ctl hup puma
   sudo gitlab-ctl restart sidekiq
   

データベースインデックスの再構築

データベースインデックスを定期的に再構築することで、スペースを取り戻し、インデックスの肥大化を健全なレベルに維持することができます。インデックスの再構築は、通常のcronジョブとして実行することもできます。健全な」インデックスの肥大化レベルは、特定のインデックスに大きく依存しますが、一般的には30%以下であるべきです。

前提条件：

• この機能にはPostgreSQL 12以降が必要です。
• 式インデックス、分割インデックス、制約除外に使用されるインデックスです。

データベース・インデックスを手動で再構築するには

1. オプション。アノテーションを Grafana (4.6 以降) のエンドポイントに送信するには、これらのカスタム環境変数でアノテーションを有効にします (カスタム環境変数の設定を参照)：

   1. GRAFANA_API_URL:GrafanaのベースURL、例えばhttp://some-host:3000 。
   2. GRAFANA_API_KEY:少なくともEditor role を持つ Grafana API キー。

2. Rake タスクを実行して、肥大化の推定値が最も高い 2 つのインデックスを再構築します：

   sudo gitlab-rake gitlab:db:reindex
   

3. インデックス再構築タスク (gitlab:db:reindex) は、各データベースで最も肥大化した2つのインデックスのみを再構築します。2つ以上のインデックスを再構築するには、必要なインデックスが全て再構築されるまでタスクを再度実行してください。

備考

• データベース・インデックスの再構築はディスクを大量に消費するタスクです。ピーク時にタスクを実行すると、肥大_化が_進み、特定のクエリの実行が遅くなることがあります。

• このタスクには、リストアされるインデックスのための空きディスク領域が必要です。作成されたインデックスには、_ccnew が付加されます。 インデックス再作成タスクが失敗した場合、タスクを再実行することで一時インデックスが削除されます。

• デー タ ベース の イ ンデ ッ ク ス再構築が完了す る ま でに必要な時間は、 タ ーゲ ッ ト デー タ ベース のサ イ ズに よ っ て異な り ます。数時間から数日かかることもあります。

データベース スキーマのダンプ

まれに、データベースのマイグレーションがすべて完了していても、データベースのスキーマがアプリケーションコードが期待するものと異なることがあります。この場合、GitLabで奇妙なエラーが発生する可能性があります。

データベーススキーマをダンプするには

SCHEMA=/tmp/structure.sql gitlab-rake db:schema:dump

Rakeタスクはデータベース・スキーマ・ダンプを含む/tmp/structure.sql ファイルを作成します。

違いがあるかどうかを判断するには

1. gitlab プロジェクトのdb/structure.sql ファイルにアクセスしてください。GitLabのバージョンに合ったブランチを選択してください。例えば、GitLab 16.2のファイル：https://gitlab.com/gitlab-org/gitlab/-/blob/16-2-stable-ee/db/structure.sql。
2. /tmp/structure.sql とdb/structure.sql ファイルを比較してください。

一般的なメトリクスのインポート

Metrics ダッシュボードを動かす一般的なメトリクスを再度インポートする必要がある場合があります。

これは、既存のメトリクスを更新した結果である可能性があります。

メトリクスを再インポートするには、以下を実行します：

sudo gitlab-rake metrics:setup_common_metrics

トラブルシューティング

アドバイザリーロック接続情報

db:migrate Rakeタスクを実行すると、以下のような出力が表示される場合があります：

main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532
main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532

返されるメッセージは情報であり、無視してかまいません。