RancherでGitLabを定期的に自動バックアップする

目的

Rancherのクーロンスケジュールを使って、Rancher上で稼働しているGitLabのバックアップが定期的に自動作成されるようにします。

前提と背景

GitLabがRancher上で既に稼働している前提の手順です。 RancherやGitLabのインストール手順は次の記事からリンクした個別の記事で説明しています。

RancherとGitLabでCI/CD環境と運用環境を構築した

バックアップと復元について、GitLabの公式ドキュメントもお読みください。
https://docs.gitlab.com/ce/raketasks/backup_restore.html

名前空間について

Rancherの名前空間については、maintenance（任意）などの名前を付けて、以降の作業で同じ名前空間を使用してください。

永続ボリュームの作成

今回は、NFSを永続ボリュームとして使用しますが、要件に応じて別のボリュームを作成しても構いません。

以下は、NFSサーバーのホストが nas.home として名前解決でき、データの保存先を /Server/rancher/maintenance とする場合の設定内容です。環境に合わせて読み替えてください。

永続ボリュームを作成するには、Rancherのメニューからクラスターを選択し、「ストレージ」 > 「永続ボリューム」をクリック、「ボリュームを追加」ボタンをクリックします。

項目	入力例	備考
名前	maintenance	任意の名前
ボリュームプラグイン	NFS共有
パス	/Server/rancher/maintenance	任意のパス
サーバー	nas.home	任意のホスト

ボリュームにマウントするファイルを作成

Kubeconfigファイルの作成

Rancher(Kubernetes)で稼働するコンテナにアクセスするための設定ファイルを作成します。作成先は、後述するバックアップワークロードのmaintenanceボリュームのkubeディレクトリのマウント先です。

設定ファイルの内容はRancherから取得します。 Rancherのメニューからクラスターを選択して、「Kubeconfigファイル」ボタンをクリックしてください。ファイルの内容が表示されるので、コピーもしくはダウンロードして所定の場所に配置します。

本記事の環境であれば、NFSサーバーの /Server/rancher/maintenance/kube/config にファイルを作成します。

バックアップシェルの作成

バックアップを実行するシェルを作成します。作成先は、後述するバックアップワークロードのmaintenanceボリュームのshellsディレクトリのマウント先です。

GitLabワークロードの作成で行ったように、GitLabのワークロードにラベルとして backup=gitlab を追加しておいてください。バックアップシェルではこのラベルを手掛かりにバックアップ対象のGitLab Podを特定します。

次の内容でシェルを作成します（後述の注意を参照）。

gitlab-backup.sh

#!/bin/bash

readonly POD_NAME=$(kubectl get pods -n gitlab -l backup=gitlab -o jsonpath='{.items[*].metadata.name}')
if [ -z "${POD_NAME}" ]; then
  echo 'ERROR: pod not found'
  exit 1
fi
kubectl exec -n gitlab ${POD_NAME} gitlab-rake gitlab:backup:create SKIP=artifacts,registry

本記事の環境であれば、NFSサーバーの /Server/rancher/maintenance/shells/gitlab-backup.sh にファイルを作成します。

2ヶ所ある -n gitlab は、-n の後にGitLabのワークロードが所属する名前空間を指定します。他の名前空間を使用している場合は適宜変更してください。

実際のバックアップは、GitLab のコマンド gitlab-rake gitlab:backup:create（後述の注意を参照）で行っています。オプションなどは要件に合わせて変更してください。
ちなみに、上記の SKIP の指定は artifacts（CIジョブの成果物）と registry（Container Registryに登録したイメージ）をバックアップ対象から除外しています。理由は共に、私の用途では、ファイルサイズが大きくなることと、ソースから再生成できるのでバックアップは不要と判断しました。

シェルを作成したら、バックアップワークロードから実行できるように実行権限を付けます。

注意 GitLab 12.2以降では、新しいバックアップコマンドが導入されたようです。公式ドキュメントを参照してください。

ワークロードの作成

Rancherメニューからプロジェクトを選択して、「ワークロード」の「デプロイ」をクリックしてワークロードを作成します。

バックアップワークロードの作成

スケジュールした時刻に起動してバックアップシェルを実行するワークロードを作成します。

項目	入力例	備考
名前	backup	任意の名前
ワークロードタイプ	「クーロンスケジュールとして動作」
スケジュール	`00 20 * * *` (毎日20時(UTC)の場合)	crontabの形式（"分時日月曜日"）でスケージュールを指定
イメージ	dtzar/helm-kubectl:2.13.1	https://hub.docker.com/r/dtzar/helm-kubectlを参照
コマンド	`/srv/shells/gitlab-backup.sh`	バックアップシェルを実行

注意点として、スケジュールがどのタイムゾーンの時刻として実行されるか確認が必要です。環境によるかもしれませんが、私の場合はUTCとして実行されました。例えば5:00(JST)に実行したい場合、クーロンのタイムゾーンがUTCであればオフセットを考慮して20:00(UTC)を指定する必要があります。

ボリューム

まずは、「ボリュームを追加」ボタンから「新しい永続ボリューム(要求)を作成」を選択して、作成済みの永続ボリュームに対する要求を作成します。ここでは maintenance という名前で作成した前提で進めます。その後、次の内容でボリュームを作成します。

項目	入力例	備考
ボリューム名	maintenance	任意の名前
ボリュームタイプ	永続ボリューム要求
永続ボリューム要求	maintenance	前記の手順で作成

マウントポイント	ボリューム内サブパス	備考
/root/.kube	kube	Rancher(Kubernetes)のコンテナにアクセスするための設定を置くディレクトリ
/srv/shells	shells	バックアップシェルを置くディレクトリ

以上で、設定がうまくいっていれば、指定の時刻にバックアップシェルが起動します。

バックアップからの復元

GitLabコンテナのシェルに入ります。Rancherから入る場合は次の手順です。

Rancherメニューからクラスタ > プロジェクトを選択
GitLab のワークロードのメニューから「シェルを実行」をクリック

バックアップディレクトリに移動します。オプション gitlab_rails['backup_path'] で場所を変更している場合は、そこに移動します。次はデフォルトのパスです。

cd /var/opt/gitlab/backups

作成済みのバックアップを確認します。

ls -l

バックアップが作成済みであれば、ファイル名の末尾が _gitlab_backup.tar のファイルが表示されます。ファイル名の前半部分がバックアップを行った日付やGitLabのバージョンになっているので、復元対象のバックアップを選びます。

バックアップファイルを別の場所から持ってきた場合など、復元に必要な権限がバックアップファイルに付いていないことがあります。その場合は権限を付けます。

chown git.git XXX_gitlab_backup.tar
chmod 600 XXX_gitlab_backup.tar

復元コマンドを実行します（後述の注意を参照）。変数部分は置き換えて実行してください。既存のデータがバックアップの内容で上書きされることに注意してください。

gitlab-rake gitlab:backup:restore BACKUP=$BACKUP

$BACKUP : バックアップファイル名の _gitlab_backup.tar より前の部分

注意 GitLab 12.2以降では、新しい復元コマンドが導入されたようです。公式ドキュメントを参照してください。

目的