2022年11月26日土曜日

OpenSSLでオレオレ証明書に作成時に"ERROR:There is already a certificate"のエラーが出た際の対処手順

以前、LinuxのOpenSSLを使ってオレオレ認証局を作り、ESXiの自己署名証明書をインポートする手順を記載した。

自宅ESXiを先日6.7から7.0にバージョンアップを行ったので、その際に証明書も新しくインポートしなおすことにしたが、"ERROR:There is already a certificate"というエラーが発生して証明書の発行(CSRに対する署名)に失敗した。
Signed certificate is in newcert.pemと最終行に表示されており、一見すると証明書が正常に発行されたように見えるが、実際は証明書は発行されていないので注意。

# cd /etc/pki/tls/misc
# ./CA -sign

~(中略)~

ERROR:There is already a certificate for /C=US/ST=California/L=Palo Alto/O=VMware, Inc/OU=VMware ESX Server Default Certificate/CN=192.168.33.12/emailAddress=ssl-certificates@vmware.com

~(以下略)~

DAmmd8agxO4NsMcfl6OzWs4whWX3xv7kS1drkrT8FkqfJ0F+7X174gjOXjhuvKGX
TjIsaV61YUPx83lQrwz0
-----END CERTIFICATE-----
Signed certificate is in newcert.pem

本記事では、OpenSSLで"ERROR:There is already a certificate"のエラーが発生した際の対処手順を記載する。

環境

今回の手順を試した環境は以下の通り。

  • OS : CentOS Stream release 8
  • OpenSSL : OpenSSL 1.1.1k FIPS 25 Mar 2021

事前に以下URLの手順にて、オレオレ認証局の構築やCAスクリプトは配置済みであることを前提とする。

エラーに対する対処手順

本エラーの原因は、発行済み証明書のリストである/etc/pki/CA/index.txtに、**今回発行しようとしている証明書の情報が重複している(まだ証明書が失効していない)**ためとなる。

以下、index.txtの抜粋となるが、今回発行対象のESXiと同じCN=192.168.33.12が存在していることがわかる。

# cat /etc/pki/CA/index.txt

~(中略)~

V       310501221913Z           0B41B73EACA2CA1C2BEC1B39B2318B4AE3352509        unknown /C=US/ST=California/L=Palo Alto/O=VMware, Inc/OU=VMware ESX Server Default Certificate/CN=192.168.33.12/emailAddress=ssl-certificates@vmware.com

本来は証明書の失効の処理を行い、その後証明書を再発行することが正しい手順となるが、手っ取り早くエラーを解消するためにはindex.txtで重複する証明書情報を削除してしまえばよい。

index.txtから該当行を削除後、再度証明書を発行すると問題なく成功した。

# ./CA -sign
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:

~(中略)~

T2JCerMlEQhoH0qXvJBcahulVqYkmX1Vcr4yt2HYJzJ3jVm/Hoe9McAnskjTySJ9
hk9/NnmdGpi6Gmb8jIAW
-----END CERTIFICATE-----
Signed certificate is in newcert.pem

以上で、OpenSSLで"ERROR:There is already a certificate"のエラーが発生した際の対処手順は完了となる。

2022年11月19日土曜日

GitLab Runnerインストール&バージョンアップ手順

GitLabには、リポジトリのコードの更新をトリガーとしてジョブを実行する機能として、「GitLab Runner」と呼ばれるツールが提供されている。GitLab Runnerを用いることで、CI/CDパイプラインをGitLab上で実現することができる。

GitLab RunnerはRPMのパッケージが提供されており、簡単に導入ができる。本記事では、GitLab Runnerのインストール手順とバージョンアップ手順を記載する。

GitLab Runnerインストール

今回の動作検証はAlmaLinux 8に対して実施した。ただし、Red Hat系のディストリビューションであるCentOSやRocky Linuxなどでも同様の手順で実施できるだろう。

  • OS : AlmaLinux 8.5
  • GitLab : 15.4.4
  • GitLab Runner : 15.4.1

また、GitLabのインストールは、以下記事の手順にてインストールを実施済みであることを前提とする。

GitLab Runnerインストール手順

1. GitLab Runnerパッケージのバージョン確認

GitLab Runnerのパッケージは、AWS S3上に作られているリポジトリから入手する。最新版であれば以下URLからダウンロードできる。

バージョン指定する場合は、まず以下サイトからGitLab Runnerのリリース情報を確認する。

例えば、2022/11月時点のタイミングでは、15.3.2、15.4.1、15.5.0などのバージョンがリリースされていることがわかる。

図15

今回は15.4.1をインストールするため、ダウンロードURLは以下の通りとなる。

2. パッケージダウンロード

curlコマンドでパッケージダウンロードを行う。あまりダウンロード速度は出ないので気長に待つこと。

# curl -LJO "[ダウンロードURL]"

コマンドの実行結果は以下の通り。今回は、パッケージの容量は414MBで3分程度でダウンロード完了した。

# curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/v15.4.1/rpm/gitlab-runner_amd64.rpm"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  414M  100  414M    0     0  2328k      0  0:03:02  0:03:02 --:--:-- 4487k

3. パッケージインストール

パッケージはそのままrpmコマンドでインストールすればよいが、gitのみ必要となるため、インストールしていない場合はインストールしておこう。

# dnf install git -y

gitインストール後、rpmコマンドでインストールすればよい。

# rpm -ivh gitlab-runner_amd64.rpm
警告: gitlab-runner_amd64.rpm: ヘッダー V4 RSA/SHA512 Signature、鍵 ID 35dfa027: NOKEY
Verifying...                          ################################# [100%]
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:gitlab-runner-15.4.1-1           ################################# [100%]
GitLab Runner: creating gitlab-runner...
Home directory skeleton not used
Runtime platform                                    arch=amd64 os=linux pid=5982 revision=526d939d version=15.4.1
gitlab-runner: the service is not installed
Runtime platform                                    arch=amd64 os=linux pid=5990 revision=526d939d version=15.4.1
gitlab-ci-multi-runner: the service is not installed
Runtime platform                                    arch=amd64 os=linux pid=6013 revision=526d939d version=15.4.1
Runtime platform                                    arch=amd64 os=linux pid=6061 revision=526d939d version=15.4.1
INFO: Docker installation not found, skipping clear-docker-cache

4. GitLab RunnerをGitLabに登録

GitLab Runnerインストール後は、GitLabで利用できるように登録作業を行う。

まず、GitLab上のAdmin画面で、[Overview]->[Runners]を開く。ここで、登録のために必要となる[Registration token]をコピーしておく。

次に、GitLab Runnerをインストールしたサーバにて、gitlab-runner registerコマンドにて登録を行う。登録作業は対話形式で行う。

# gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=6409 revision=526d939d version=15.4.1
Running in system-mode.

Enter the GitLab instance URL (for example, https://gitlab.com/):
http://gitlab.com/ ←★GitLabのURLを記載
Enter the registration token:
M-4oTXXXXeTxkhXXXXkX ←★先ほど確認したGitLabのRegistration tokenを記載
Enter a description for the runner:
[localhost]: ←★GitLab上の登録名。特に指定がなければそのままEnter
Enter tags for the runner (comma-separated):
 ←★そのままEnter
Enter optional maintenance note for the runner:
 ←★そのままEnter
Registering runner... succeeded                     runner=M-4oTtcR
Enter an executor: parallels, docker+machine, docker-ssh+machine, custom, docker, docker-ssh, shell, ssh, virtualbox, kubernetes:
shell ←★今回はshellを指定
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

5. GitLab上で登録状況を確認

再度、GitLabにて[Overview]->[Runners]を開くと、先ほど登録したGitLab RunnerがOnline状態で表示されるはずだ。

以上で、GitLab Runnerのインストール手順は完了となる。

GitLab Runnerバージョンアップ手順

GitLabはかなりの高頻度でバージョンアップがされている。GitLab Runnerも同様にバージョンアップ頻度が高いため、インストール手順と併せてバージョンアップ手順も記載する。

1. GitLab Runnerパッケージのバージョン確認&ダウンロード

こちらはインストール手順と流れは変わらないため、割愛する。

2 GitLab Runnerバージョンアップ

インストール時との違いはrpmコマンドのオプションだけとなる。-Uオプションに変更することで、パッケージのバージョンアップが実施される。

# rpm -Uvh gitlab-runner_amd64.rpm
警告: gitlab-runner_amd64.rpm: ヘッダー V4 RSA/SHA512 Signature、鍵 ID 35dfa027: NOKEY
Verifying...                          ################################# [100%]
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:gitlab-runner-15.4.1-1           ################################# [ 50%]
GitLab Runner: detected user gitlab-runner
Runtime platform                                    arch=amd64 os=linux pid=924254 revision=526d939d version=15.4.1
gitlab-runner: Service is running
Runtime platform                                    arch=amd64 os=linux pid=924296 revision=526d939d version=15.4.1
gitlab-ci-multi-runner: the service is not installed
Runtime platform                                    arch=amd64 os=linux pid=924315 revision=526d939d version=15.4.1
Runtime platform                                    arch=amd64 os=linux pid=924361 revision=526d939d version=15.4.1
INFO: Docker installation not found, skipping clear-docker-cache
整理中 / 削除中...
   2:gitlab-runner-15.4.0-1           ################################# [100%]

バージョンアップ後は特に手動でのサービス再起動等は不要で、GitLabを確認すると即座に新しいバージョンで認識しているはずだ。

以上で、GitLab Runnerのバージョンアップ手順は完了となる。

参考

2022年11月12日土曜日

GitLabバージョンアップ手順

GitLabはかなりの頻度でバージョンアップが繰り返しており、月1回新しいマイナーバージョンのリリースがされている状況となる。

例えば、直近(2022/11月時点)のバージョンリリースのタイミングは以下となる。毎月20日前後で新しいバージョンがリリースされていることがわかる。

バージョン リリース日
15.5 2022/10/21
15.4 2022/9/21
15.3 2022/8/19
15.2 2022/7/21
15.1 2022/6/21

以下サイトによると、GitLabのサポート期限はリリースから1年となっているようなので、定期的なバージョンアップ計画が必要となりそうだ。

上記をふまえ、本記事ではGitLabをバージョンアップする手順を記載する。

環境

今回の動作検証はAlmaLinux 8に対して実施した。ただし、Red Hat系のディストリビューションであるCentOSやRocky Linuxなどでも同様の手順で実施できるだろう。

  • OS : AlmaLinux 8.5
  • 旧バージョン : gitlab-ee-15.3.4-ee.0.el8.x86_64
  • 新バージョン : gitlab-ee-15.4.4-ee.0.el8.x86_64

また、GitLabのインストールは、以下記事の手順にてインストールを実施済みであることを前提とする。

GitLabバージョンアップ手順

1. バージョン選定

バージョンアップするにあたり、バージョンアップ対象バージョンの選定を行う。

パッチのリリース情報は、以下URLから確認することができる。

また、バージョンアップ時のアップグレードパスは、以下マニュアルに記載されている。

マニュアルでは以下の通りアップグレードパスが記載されており、例えば、15.0から最新版にバージョンアップする場合は、一度15.4.0を経由させてバージョンアップする必要がある。

8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7
-> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14
-> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15
-> 14.0.12 -> 14.3.6 -> 14.9.5 -> 14.10.Z
-> 15.0.Z -> 15.4.0 -> latest 15.Y.Z

今回は、15.3.4から15.4.4へのバージョンアップとなるため、直接バージョンアップが可能となる。

2. リポジトリ上に存在するGitLabのバージョン確認

dnfでそのままバージョンアップすると、最新版にバージョンアップされてしまう。特に確認せず最新版にバージョンアップする場合は本手順は不要だが、今回は特定のバージョンにバージョンアップするため、事前にGitLabのリポジトリに存在するGitLabのバージョン確認を行う。

バージョン確認は、dnf search時に--showduplicatesのオプションを付与して実行する。並び順がバージョン順とならない場合があるため、sortコマンドを使って表示をさせている。

実行結果は以下の通り。ターゲットバージョンであるgitlab-ee-15.4.4-ee.0.el8.x86_64が存在することが確認できた。

# dnf search --showduplicates gitlab-ee | sort
=========================== 名前 完全一致: gitlab-ee ===========================
gitlab-ee-12.10.0-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-12.10.1-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-12.10.10-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)

~(中略)~

gitlab-ee-15.3.0-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.1-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.2-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.3-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.4-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.4-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.3.5-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.4.0-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.4.1-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.4.2-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.4.3-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.4.4-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.5.0-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.5.1-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)
gitlab-ee-15.5.2-ee.0.el8.x86_64 : GitLab Enterprise Edition (including NGINX, Postgres, Redis)

3. バージョンを指定してバージョンアップ

GitLabのバージョンを指定する場合は、dnfのパッケージ名の指定時に、バージョンまで含めた名称で指定すればよい。GitLab 15.xは1.2GBほどの容量があるため、そこそこダウンロードとインストールに時間を要するので気長に待とう。

# dnf update gitlab-ee-15.4.4-ee.0.el8.x86_64
メタデータの期限切れの最終確認: 0:02:03 時間前の 2022年11月03日 14時48分39秒 に実施しました。
依存関係が解決しました。
====================================================================================================================================
 パッケージ                  アーキテクチャー         バージョン                           リポジトリー                       サイズ
====================================================================================================================================
アップグレード:
 gitlab-ee                   x86_64                   15.4.4-ee.0.el8                      gitlab_gitlab-ee                   1.2 G

トランザクションの概要
====================================================================================================================================
アップグレード  1 パッケージ

ダウンロードサイズの合計: 1.2 G

~(中略)~

ok: run: redis: (pid 1602) 456972s
ok: run: redis-exporter: (pid 832200) 0s
ok: run: sidekiq: (pid 832207) 1s

     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \____/_/\__/_____/\__,_/_.___/


Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
If you need to roll back to the previous version you can use the database
backup made during the upgrade (scroll up for the filename).


  検証             : gitlab-ee-15.4.4-ee.0.el8.x86_64                                                                           1/2
  検証             : gitlab-ee-15.3.4-ee.0.el8.x86_64                                                                           2/2

アップグレード済み:
  gitlab-ee-15.4.4-ee.0.el8.x86_64

完了しました!

なお、バージョンアップ対象のGitLabのバージョンによっては、本体以外にも関連するパッケージのアップグレードや追加インストールが発生する。以下は、15.1.2 -> 15.3.4へバージョンアップした際のdnfの実行結果となり、本体以外にさまざまなパッケージが追加インストールされていることがわかる。

# dnf update gitlab-ee-15.3.4-ee.0.el8.x86_64
gitlab_gitlab-ee                                648  B/s | 862  B     00:01
gitlab_gitlab-ee-source                         316  B/s | 862  B     00:02
依存関係が解決しました。
================================================================================
 パッケージ                   Arch   バージョン          リポジトリー     サイズ
================================================================================
アップグレード:
 gitlab-ee                    x86_64 15.3.4-ee.0.el8     gitlab_gitlab-ee 1.1 G
 glibc                        x86_64 2.28-189.5.el8_6    baseos           2.2 M
 glibc-all-langpacks          x86_64 2.28-189.5.el8_6    baseos            25 M
 glibc-common                 x86_64 2.28-189.5.el8_6    baseos           1.3 M
依存関係のインストール:
 dwz                          x86_64 0.12-10.el8         appstream        108 k
 efi-srpm-macros              noarch 3-3.el8             appstream         21 k
 ghc-srpm-macros              noarch 1.4.2-7.el8         appstream        9.2 k
 glibc-gconv-extra            x86_64 2.28-189.5.el8_6    baseos           1.5 M

~(中略)~

 unzip                        x86_64 6.0-46.el8          baseos           195 k
 zip                          x86_64 3.0-23.el8          baseos           270 k
弱い依存関係のインストール:
 perl-Encode-Locale           noarch 1.05-10.module_el8.5.0+2812+ed912d05
                                                         appstream         20 k

トランザクションの概要
================================================================================
インストール    117 パッケージ
アップグレード    4 パッケージ

ダウンロードサイズの合計: 1.2 G

~(以下略)~

4. バージョンアップ後の確認

バージョンアップ後にGitLabにログインして、Adminの画面からバージョン確認をしてみよう。問題なくバージョンアップされていれば作業は完了となる。

以上で、GitLabをバージョンアップする手順は完了となる。

2022年11月5日土曜日

GitLabバックアップ・リストア手順

自宅環境のGitLabでは、自分が作成したAnsibleのPlaybookやPythonスクリプトだけだなく、各種技術情報などをWikiで管理するようにしており、GitLabで保存されているデータの重要性が高くなってきた。

そのため、万が一自宅環境のディスク障害などに備え、バックアップを取得することにした。幸い、GitLabではバックアップ・リストアをするためのコマンドが標準で用意されている。

今回は、GitLabの機能を用いてバックアップ・リストアを行う手順を記載する。

環境

GitLabのOSはAlmaLinuxを用いる。ただし、Red Hat系のディストリビューションであるCentOSやRocky Linuxなどでも同様の手順で対応できると想定する。

  • OS : AlmaLinux 8.5
  • GitLab : 15.3.4

また、本記事では同一サーバに対してリストアすることを想定するが、バックアップファイルを用いて別のサーバに対してリストアすることもできるようだ。その手順については、別途検証した際に公開することにしたい。

バックアップ

1. `バックアップ取得

GitLabのバックアップは、gitlab-rake gitlab:backup:createコマンドを実行するだけで完了する。本コマンドは特にGitLabのサービス停止などは不要となる。

Backup [バックアップ名] is done.と表示されれば問題なくバックアップは完了となる。

# gitlab-rake gitlab:backup:create
2022-07-29 21:24:15 +0900 -- Dumping database ...
Dumping PostgreSQL database gitlabhq_production ... [DONE]
2022-07-29 21:24:19 +0900 -- Dumping database ... done
2022-07-29 21:24:19 +0900 -- Dumping repositories ...
{"command":"create","gl_project_path":"gitlab-instance-870ba0ef.wiki","level":"info","msg":"started create","relative_path":"@groups/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.wiki.git","storage_name":"default","time":"2022-07-29T12:24:19.686Z"}

~(中略)~

2022-07-29 21:24:20 +0900 -- Deleting tar staging files ... done
2022-07-29 21:24:20 +0900 -- Deleting backups/tmp ...
2022-07-29 21:24:20 +0900 -- Deleting backups/tmp ... done
2022-07-29 21:24:20 +0900 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.
2022-07-29 21:24:20 +0900 -- Backup 1659097455_2022_07_29_15.1.2-ee is done.

2. バックアップファイルの確認

バックアップファイルが/var/opt/gitlab/backupsに生成されていることを確認する。バックアップファイルは[時間]_[月]_[日]_[バージョン]_gitlab_backup.tarという名前で生成される。

# ls -l /var/opt/gitlab/backups
-rw------- 1 git git 25518080 10月 29 01:30 1666974616_2022_10_29_15.3.4-ee_gitlab_backup.tar

3. 設定ファイルのバックアップ

バックアップファイルにはGitLabの設定ファイルは含まれないため、以下ファイルを任意の場所にバックアップしておく。

  • /etc/gitlab/gitlab.rb
  • /etc/gitlab/gitlab-secrets.json

容量はそこまで大きくないことから、tarで固めてディレクトリ全体をバックアップしても問題ない。

# tar zcvf gitlab_config_20221029.tgz /etc/gitlab
tar: メンバ名から先頭の `/' を取り除きます
/etc/gitlab/
/etc/gitlab/gitlab-secrets.json
/etc/gitlab/trusted-certs/
/etc/gitlab/trusted-certs/public.crt
/etc/gitlab/trusted-certs/6b8ba5bf.0
/etc/gitlab/gitlab.rb

以上でGitLabのバックアップは完了となる。

GitLabリストア手順

1. 前提条件確認

前提として、バックアップファイルは/var/opt/gitlab/backupsに配置する。また、バックアップファイルとリストア先のGitLabのバージョンは一致させることが必要となる。

今回は以下の通り、バックアップファイルとリストア先のGitLabのバージョンは15.3.4で一致していることを確認した。

# ls -l /var/opt/gitlab/backups
-rw------- 1 git git 25518080 10月 29 01:30 1666974616_2022_10_29_15.3.4-ee_gitlab_backup.tar

# rpm -qa | grep gitlab
gitlab-ee-15.3.4-ee.0.el8.x86_64

また、今回はリストアされたことを確認できるよう、tuser001/linux_configというプロジェクトを事前に削除し、リストアすることで復旧することを確認する。

2. サービス停止

GitLabを構成するサービスのうち、pumasidekiqを停止する。

# gitlab-ctl status
run: alertmanager: (pid 3127640) 1418103s; run: log: (pid 1528) 3140631s
run: gitaly: (pid 3127689) 1418101s; run: log: (pid 1504) 3140631s
run: gitlab-exporter: (pid 3127638) 1418103s; run: log: (pid 1526) 3140631s

~(中略)~

run: sidekiq: (pid 3127807) 1418099s; run: log: (pid 1496) 3140631s
# gitlab-ctl stop puma
ok: down: puma: 0s, normally up
# gitlab-ctl stop sidekiq
ok: down: sidekiq: 0s, normally up
# gitlab-ctl status
run: alertmanager: (pid 3127640) 1418465s; run: log: (pid 1528) 3140993s
run: gitaly: (pid 3127689) 1418463s; run: log: (pid 1504) 3140993s
run: gitlab-exporter: (pid 3127638) 1418465s; run: log: (pid 1526) 3140993s

~(中略)~

down: puma: 17s, normally up; run: log: (pid 1495) 3140993s
~(中略)~
down: sidekiq: 8s, normally up; run: log: (pid 1496) 3140993s

3. リストア

リストアは、gitlab-rake gitlab:backup:restoreを利用する。この際にバックアップファイル名を引数として指定するが、ファイル名の拡張子(.tar)は不要となるので注意する。途中2回ほど継続しても問題ないか確認を求められるので、yesを選択して先に進めよう。

Restore task is done.と表示されれば問題なくリストアは完了となる。

# gitlab-rake gitlab:backup:restore BACKUP=1666974616_2022_10_29_15.3.4-ee
2022-08-05 22:53:54 +0900 -- Unpacking backup ... 
2022-08-05 22:53:54 +0900 -- Unpacking backup ... done
2022-08-05 22:53:54 +0900 -- Restoring database ... 
2022-08-05 22:53:54 +0900 -- Be sure to stop Puma, Sidekiq, and any other process that
connects to the database before proceeding. For Omnibus
installs, see the following link for more information:
https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations

Before restoring the database, we will remove all existing
tables to avoid future upgrade problems. Be aware that if you have
custom tables in the GitLab database these tables and all data will be
removed.

Do you want to continue (yes/no)? yes ★yesを入力
Removing all tables. Press `Ctrl-C` within 5 seconds to abort
2022-08-05 13:54:12 UTC -- Cleaning the database ... 
2022-08-05 13:54:14 UTC -- done
Restoring PostgreSQL database gitlabhq_production ... ERROR:  must be owner of extension pg_trgm
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension pg_trgm

~(中略)~

2022-08-05 22:54:23 +0900 -- Restoring terraform states ... done
2022-08-05 22:54:23 +0900 -- Restoring packages ...
2022-08-05 22:54:23 +0900 -- Restoring packages ... done
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes ★yesを入力

2022-08-05 22:54:49 +0900 -- Deleting tar staging files ...
2022-08-05 22:54:49 +0900 -- Cleaning up /var/opt/gitlab/backups/backup_information.yml

~(中略)~

2022-08-05 22:54:49 +0900 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need to restore these files manually.
2022-08-05 22:54:49 +0900 -- Restore task is done.

4. 設定ファイルを再配置

事前にバックアップしていた以下ファイルを/etc/gitlabに再配置する。

  • /etc/gitlab/gitlab.rb
  • /etc/gitlab/gitlab-secrets.json

5. リストア後の再設定とサービス起動

以下コマンドを実行し、GitLabの再設定、サービス再起動を行う。

# gitlab-ctl reconfigure
# gitlab-ctl restart

再起動後にサービスがすべて起動していることを確認しよう。すべてのサービスがrunと表示されれば問題ない。

# gitlab-ctl status
run: alertmanager: (pid 1556185) 70s; run: log: (pid 1528) 3141350s
run: gitaly: (pid 3127689) 1418820s, got TERM; run: log: (pid 1504) 3141350s
run: gitlab-exporter: (pid 1556211) 38s; run: log: (pid 1526) 3141350s

~(中略)~

run: sidekiq: (pid 1556320) 33s; run: log: (pid 1496) 3141350s

6. リストア後のGitLabの健全性チェック

最後にリストア後のGitLabの健全性チェックをgitlab-rake gitlab:checkコマンドで実施する。

各種チェックが実行されるが、すべてOKとなっていれば問題ない。

# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 14.10.0 ? ... OK (14.10.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

~(中略)~

Checking GitLab App ... Finished

Checking GitLab subtasks ... Finished

7. 削除したデータ復旧の確認

リストア後、事前に削除したtuser001/linux_configのプロジェクトが復旧できていることが確認できた。

以上でGitLabのリストアは完了となる。

参考

人気の投稿