シナプス技術者ブログ

シナプスの技術者公式ブログ。インターネットで、鹿児島の毎日を笑顔にします。

GitLabサーバをリストアしてみた

シナプスの技術部 システム開発課の蔵坪と申します。

弊社はオンプレミスのGitLabサーバを運用しております。

昨年の12月くらいに、GitLabには正常にアクセスできるが、アップデートが出来ないという状況が発生しました。

アップデートのメッセージを見ると、一部のファイルを更新できないメッセージが表示され途中で止まっていました。該当ファイルを調べても、正常に閲覧できますし、原因がよく分かりませんでした。稀に、ディスクエラーが発生し、サーバ自体がフリーズすることもありましたので、完全に動かなくなる前に、リプレースすることにしました。今回は、そちらの手順を紹介します。

今回の環境

名称 バージョン
OS CentOS Linux release 7.8
GitLab GitLab Community Edition 13.3.6

GitLabのバックアップと復元

公式に、かなり詳しいドキュメントがありますので、基本的に、ドキュメントの通りに行いました。

docs.gitlab.com

バックアップについて

まず、弊社のバックアップ状況です。

  • バックアップは、4世代(4日間)
  • バックアップは、一日一回Cronで、毎日2時に実行
  • Cronで、バックアップファイルを、バックアップサーバにコピー
  • Cronで、/etc/gitlab/の内容を、バックアップサーバにコピー

/etc/cron.d/gitlab

0 2 * * * root /opt/gitlab/bin/gitlab-backup create CRON=1

/etc/gitlab/gitlab.rb

gitlab_rails['backup_keep_time'] = 345600

たった、これだけでフルバックアップをしてくれます。素晴らしい!

リストア

リストアの手順です。

  1. CentOS 7.8のインストール
  2. 同一バージョンのGitLabのインストール

ここまでは、構築した手順と一緒です。

インストール後に、GitLabを開始します。

sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

最新のバックアップファイルを、バックアップディレクトリ/var/opt/gitlab/backups/にコピーし、ファイルの所有者をgit:gitに変更します。

sudo cp $バックアップファイルの最新.tar /var/opt/gitlab/backups/
sudo chown git.git /var/opt/gitlab/backups/$バックアップファイルの最新.tar

データベースに接続しているプロセスを停止します。

sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

ファイルのタイムスタンプを指定して、リストアします。

sudo gitlab-backup restore BACKUP=$復元したいバックアップファイルのタイムスタンプ

/etc/gitlab/gitlab.rb/etc/gitlab/gitlab-secrets.jsonファイルをバックアップ元からコピーし、GitLabを再構成、再起動します。

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

動作確認を行います。ここでで復元完了です。


ここから先は、公式のドキュメントに記載がない情報もあるため、参考程度にしてください。

復元してから、下記のサービスの利用に正常に利用できないことに気づきました。

  • GitLab Pages
    • ログインできない
  • Grafana
    • ログインできない
  • コンテナレジストリ
    • pushできない
  • パッケージレジストリ
    • 過去にアップしたパッケージがダウンロードできない

ログインできないGitLab PagesGrafanaについては、管理者エリア>アプリケーションで、確認できるアプリケーションIDと、/etc/gitlab/gitlab-secrets.jsonに保存されているアプリケーションIDが違うことに気づきました。GitLabのイシューを確認していたところ、このアプリケーションIDは、gitlab-secrets.jsonの該当の箇所を削除すると、再作成される記事を見つけたので、gitlab-secrets.jsonの該当部分を削除し、再構成しました。

"grafana": {
   "secret_key": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
   "gitlab_secret": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
   "gitlab_application_id": "19b59f3f32907ca55ee4fa72ff64582062c4cca6aa79cb78cadeb1aaf9f19d38",
   "admin_password": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
   "metrics_basic_auth_password": null
},
"gitlab_pages": {
   "gitlab_secret": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
   "gitlab_id": "02c9accf5a30d73519d974a40b239e0e593adadb900c8992bba6c1a846c773a0",
   "auth_secret": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
   "api_secret_key": "XXXXXXXXXXXXXXXXXXXXXXXXXX"
},

再構成します。

sudo gitlab-ctl reconfigure

これで、GitLab PagesGrafanaにログインできるようになりました。

コンテナレジストリに、pushできない件ですが、こちらは、公式のドキュメントに記載がありましたが、/var/opt/gitlab/gitlab-rails/shared/registry/dockerフォルダのパーミッションがおかしいことが原因のようでした。

docs.gitlab.com

sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker

これで、コンテナレジストリに、pushできるようになりました。

パッケージレジストリがダウンロードできない件ですが、こちらは、調べてみると、パッケージの保存ディレクトリが空であることが分かりました。公式の情報を探してみましたが、こちらの復旧手順が見つからなかったので、/var/opt/gitlab/gitlab-rails/shared/packages/フォルダを丸ごと、旧サーバから復元したところ、ダウンロードできるようになりました。

さいごに

今回は、旧サーバが動作していたため、余裕を持って復旧作業が行えましたが、いきなりGitLabサーバ起動しないような状況になっていたら、かなり焦ったと思います。本来構築時に、リストアの手順を作っておくべきでしたが・・・・

今回のリストアを機会にドキュメントを残すことできて、ほっとしました。