シナプスの技術部 システム開発課の蔵坪と申します。
弊社はオンプレミスのGitLabサーバを運用しております。
昨年の12月くらいに、GitLabには正常にアクセスできるが、アップデートが出来ないという状況が発生しました。
アップデートのメッセージを見ると、一部のファイルを更新できないメッセージが表示され途中で止まっていました。該当ファイルを調べても、正常に閲覧できますし、原因がよく分かりませんでした。稀に、ディスクエラーが発生し、サーバ自体がフリーズすることもありましたので、完全に動かなくなる前に、リプレースすることにしました。今回は、そちらの手順を紹介します。
今回の環境
名称 | バージョン |
---|---|
OS | CentOS Linux release 7.8 |
GitLab | GitLab Community Edition 13.3.6 |
GitLabのバックアップと復元
公式に、かなり詳しいドキュメントがありますので、基本的に、ドキュメントの通りに行いました。
バックアップについて
まず、弊社のバックアップ状況です。
- バックアップは、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
たった、これだけでフルバックアップをしてくれます。素晴らしい!
リストア
リストアの手順です。
- CentOS 7.8のインストール
- 同一バージョンの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 Pages
とGrafana
については、管理者エリア>アプリケーション
で、確認できるアプリケーション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 Pages
とGrafana
にログインできるようになりました。
コンテナレジストリに、pushできない件ですが、こちらは、公式のドキュメントに記載がありましたが、/var/opt/gitlab/gitlab-rails/shared/registry/docker
フォルダのパーミッションがおかしいことが原因のようでした。
sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker
これで、コンテナレジストリに、pushできるようになりました。
パッケージレジストリがダウンロードできない件ですが、こちらは、調べてみると、パッケージの保存ディレクトリが空であることが分かりました。公式の情報を探してみましたが、こちらの復旧手順が見つからなかったので、/var/opt/gitlab/gitlab-rails/shared/packages/
フォルダを丸ごと、旧サーバから復元したところ、ダウンロードできるようになりました。
さいごに
今回は、旧サーバが動作していたため、余裕を持って復旧作業が行えましたが、いきなりGitLabサーバ起動しないような状況になっていたら、かなり焦ったと思います。本来構築時に、リストアの手順を作っておくべきでしたが・・・・
今回のリストアを機会にドキュメントを残すことできて、ほっとしました。