CircleCI Server v3.x のバックアップと復元
このページの内容
- 概要
- セットアップ
- 前提条件
- AWS を使う場合の前提条件
- GCP を使う場合の前提条件
- S3 互換ストレージを使う場合の前提条件
- AWS での CircleCI Server 3.x のバックアップ
- 手順 1 - AWS S3 バケットの作成
- 手順 2 - Velero の権限の設定
- 手順 3 - Velero のインストールと起動
- GCP での CircleCI Server 3.x のバックアップ
- 手順 1 - GCP バケットの作成
- 手順 2 - Velero の権限の設定
- オプション 1: JSON キー ファイル
- オプション 2: Workload Identity
- 手順 3 - Velero のインストールと起動
- JSON キー ファイルを使用する場合
- Workload Identity を使用する場合
- S3 互換ストレージでの CircleCI Server 3.x のバックアップ
- 手順 1 - mc クライアントの設定
- 手順 2 - バケットの作成
- 手順 3 - ユーザーとポリシーの作成
- 手順 4 - Velero のインストールと起動
- バックアップの作成
- オプション 1 - KOTS CLI を使用したバックアップ作成
- オプション 2 - KOTS 管理者コンソールを使用したバックアップ作成
- バックアップの復元
- オプション 1 - スナップショットからのバックアップ復元
- オプション 2 - KOTS CLI を使用したバックアップ作成
- オプション 3 - KOTS 管理者コンソール UI を使用したバックアップ復元
- オプション - KOTS 使用したバックアップのスケジュール設定
- バックアップと復元のトラブルシューティング
- [Snapshots (スナップショット)] オプションが KOTS 管理者コンソールに表示されない
- バックアッププロセスまたは復元プロセスでエラーが発生した
概要
バックアップと復元は、CircleCI Server v3.1.0 以上で利用できます。
CircleCI Server の運用と管理においては、別のクラスタへの移行や深刻な事象からの復元が必要な事態を想定して、バックアップを維持し、システムを復元する方法を検討する必要があります。
このドキュメントでは、CircleCI Server のインスタンスデータと状態のバックアップと復元方法についての推奨事項を説明します。
CircleCI Server は、 KOTS を使用して管理します。KOTS では、バックアップと復元に Velero を使用しています。 この方法のメリットは、アプリケーションのデータだけでなく、バックアップ時点の Kubernetes クラスタの状態とリソースも復元することです。 つまり、管理者コンソールの設定や、クラスタに加えたカスタマイズ内容も復元できるのです。
CircleCI サービスのバックアップと復元は、Velero に依存しています。 クラスタが失われた場合、そのクラスタ内の Velero が正常に起動するまで、CircleCI を復元することはできません。 Velero が正常に起動すれば、CircleCI サービスを復元できます。 |
セットアップ
CircleCI Server のバックアップは、 KOTS を介して作成できます。 ただし、バックアップサポートを有効にするには、クラスタに Velero をインストールして設定する必要があります。
以下のセクションでは、クラスタへの Velero のインストール手順を説明します。
前提条件
-
お使いの環境に合った Velero CLI をダウンロードしてインストールします。
AWS を使う場合の前提条件
-
AWS CLI をインストール済みであること。
GCP を使う場合の前提条件
-
gcloud
とgsutil
をインストール済みであること。 これらは両方とも Google Cloud SDK に含まれており、SDK をインストールすることでセットアップできます( こちらのドキュメントを参照してください)。
詳細については、Velero の サポート対象プロバイダーに関するページ を参照してください。
以下で、AWS と GCP のそれぞれで CircleCI Server 3.x のバックアップを作成する手順について説明します。
S3 互換ストレージを使う場合の前提条件
-
お使いのストレージプロバイダーに合った minio CLI をインストールし設定済みであること。
AWS での CircleCI Server 3.x のバックアップ
以下の手順では、プロバイダーが AWS であり、上記の 前提条件 を満たしていることを前提としています。
これらの手順は、 Velero ドキュメント を元にしています。
手順 1 - AWS S3 バケットの作成
BUCKET=<YOUR_BUCKET>
REGION=<YOUR_REGION>
aws s3api create-bucket \
--bucket $BUCKET \
--region $REGION \
--create-bucket-configuration LocationConstraint=$REGION
手順 2 - Velero の権限の設定
-
IAM ユーザーを作成します。
aws iam create-user --user-name velero
-
必要な権限を付与するポリシーをユーザー
velero
にアタッチします。
cat > velero-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:CreateSnapshot",
"ec2:DeleteSnapshot"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": [
"arn:aws:s3:::${BUCKET}/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::${BUCKET}"
]
}
]
}
EOF
aws iam put-user-policy \
--user-name velero \
--policy-name velero \
--policy-document file://velero-policy.json
-
ユーザー
velero
用のアクセスキーを作成します。
aws iam create-access-key --user-name velero
このコマンドの結果は以下のようになります。
{
"AccessKey": {
"UserName": "velero",
"Status": "Active",
"CreateDate": "2017-07-31T22:24:41.576Z",
"SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
"AccessKeyId": <AWS_ACCESS_KEY_ID>
}
}
-
以下の内容を記載した、Velero 固有の認証情報ファイルをローカルディレクトリに作成します (例:
./credentials-velero
)。
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
ここで、AWS_ACCESS_KEY_ID
プレースホルダーと AWS_SECRET_ACCESS_KEY
プレースホルダーには、前の手順の create-access-key
リクエストで返された値を指定します。
手順 3 - Velero のインストールと起動
-
以下の
velero install
コマンドを実行します。 これにより、velero
という名前空間が作成され、Velero を実行するのに必要なリソースがすべてインストールされます。 必ず 手順 2 で作成した、AWS 認証情報が含まれる正しいファイル名を指定してください。
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.2.0 \
--bucket $BUCKET \
--backup-location-config region=$REGION \
--snapshot-location-config region=$REGION \
--secret-file ./credentials-velero \
--use-restic \
--wait
-
Velero がクラスタにインストールされたら、新しい
velero
名前空間を確認します。 以下のように、Velero デプロイと restic デーモンセットがあれば成功です。
$ kubectl get pods --namespace velero
NAME READY STATUS RESTARTS AGE
restic-5vlww 1/1 Running 0 2m
restic-94ptv 1/1 Running 0 2m
restic-ch6m9 1/1 Running 0 2m
restic-mknws 1/1 Running 0 2m
velero-68788b675c-dm2s7 1/1 Running 0 2m
restic はデーモンセットなので、Kubernetes クラスタ内のノード 1 つにつき 1 つの Pod が存在します。
GCP での CircleCI Server 3.x のバックアップ
以下の手順は、Google Cloud Platform を対象としており、 前提条件を満たしていることを前提としています。
これらの手順は、 こちら の Velero GCP プラグインのドキュメントを元にしています。
手順 1 - GCP バケットの作成
タイプミスのリスクを減らすために、一部のパラメーターをシェル変数として設定します。 すべての手順を 1 つのセッションで完了できず、再開する場合は、必要に応じて変数を再設定するようにしてください。 たとえば、以下の手順では、バケット名に対応する変数を定義します。 <YOUR_BUCKET>
プレースホルダーを、バックアップ用に作成するバケット名に置き換えてください。
BUCKET=<YOUR_BUCKET>
手順 2 - Velero の権限の設定
CircleCI Server を GKE クラスタ内で実行している場合、RBAC オブジェクトを作成する必要があるため、使用する IAM ユーザーをクラスタの管理者に設定してください。 詳細については、 GKE のドキュメント を参照してください。
-
最初に、プロジェクト ID に対応するシェル変数を設定します。 それにはまず、次のコマンドを実行して現在の設定を調査し、
gcloud
CLI が正しいプロジェクトを参照していることを確認します。gcloud config list
-
プロジェクトが適切に参照されていれば、以下のように変数を設定します。
PROJECT_ID=$(gcloud config get-value project)
-
以下のコマンドを実行して、サービス アカウントを作成します。
gcloud iam service-accounts create velero \ --display-name "Velero service account"
Velero がインストールされたクラスタを複数実行している場合は、サービスアカウントに対して、上記の例で示している velero
ではなく、具体的な名前を付けることをお勧めします。 -
以下のコマンドを実行して、サービスアカウントが正常に作成されたことを確認します。
gcloud iam service-accounts list
-
次に、サービスアカウントの電子メール アドレスを変数に格納します。
SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \ --filter="displayName:Velero service account" \ --format 'value(email)')
サービスアカウントに付けた表示名に合わせて、必要に応じてコマンドを変更してください。
-
必要な権限をサービスアカウントに付与します。
ROLE_PERMISSIONS=( compute.disks.get compute.disks.create compute.disks.createSnapshot compute.snapshots.get compute.snapshots.create compute.snapshots.useReadOnly compute.snapshots.delete compute.zones.get ) gcloud iam roles create velero.server \ --project $PROJECT_ID \ --title "Velero Server" \ --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")" gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \ --role projects/$PROJECT_ID/roles/velero.server gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
次に、Velero でこのサービスアカウントを使用できるようにする必要があります。
オプション 1: JSON キー ファイル
サービスアカウントとしてアクションを実行できるように Velero を認証するには、JSON 認証情報ファイルを Velero に渡します。 それにはまず、以下のコマンドを実行してキーを作成します。
gcloud iam service-accounts keys create credentials-velero \
--iam-account $SERVICE_ACCOUNT_EMAIL
このコマンドを実行すると、credentials-velero
という名前のファイルがローカル作業ディレクトリに作成されます。
オプション 2: Workload Identity
クラスタで既に Workload Identity を使用している場合は、先ほど作成した GCP サービスアカウントを Velero の Kubernetes サービスアカウントにバインドします。 この場合、GCP サービスアカウントには、上記で指定済みの権限に加え、iam.serviceAccounts.signBlob
ロールも必要です。
手順 3 - Velero のインストールと起動
-
サービスアカウントの認証方法に応じて、以下の
velero
install
コマンドのいずれかを実行します。 これにより、velero
という名前空間が作成され、Velero を実行するのに必要なリソースがすべてインストールされます。
JSON キー ファイルを使用する場合
velero install \
--provider gcp \
--plugins velero/velero-plugin-for-gcp:v1.2.0 \
--bucket $BUCKET \
--secret-file ./credentials-velero \
--use-restic \
--wait
Workload Identity を使用する場合
velero install \
--provider gcp \
--plugins velero/velero-plugin-for-gcp:v1.2.0 \
--bucket $BUCKET \
--no-secret \
--sa-annotations iam.gke.io/gcp-service-account=$SERVICE_ACCOUNT_EMAIL \
--backup-location-config serviceAccount=$SERVICE_ACCOUNT_EMAIL \
--use-restic \
--wait
システムをカスタマイズする他のオプションについては、 Velero のドキュメント を参照してください。
-
Velero がクラスタにインストールされたら、新しい
velero
名前空間を確認します。 以下のように、Velero デプロイと restic デーモンセットがあれば成功です。
$ kubectl get pods --namespace velero
NAME READY STATUS RESTARTS AGE
restic-5vlww 1/1 Running 0 2m
restic-94ptv 1/1 Running 0 2m
restic-ch6m9 1/1 Running 0 2m
restic-mknws 1/1 Running 0 2m
velero-68788b675c-dm2s7 1/1 Running 0 2m
restic はデーモンセットなので、Kubernetes クラスタ内のノード 1 つにつき 1 つの Pod が存在します。
S3 互換ストレージでの CircleCI Server 3.x のバックアップ
以下の手順では、S3 互換オブジェクトストレージ (AWS S3 に限らない) をバックアップに使用していることが前提です。 また、 前提条件 を満たしていることも前提としています。
これらの手順は、 Velero ドキュメント を元にしています。
手順 1 - mc
クライアントの設定
最初に、ストレージ プロバイダーに接続できるよう mc
を設定します。
# エイリアスは任意の名前でかまいませんが、以降のコマンドでも同じ値を使用してください。
export ALIAS=my-provider
mc alias set $ALIAS <YOUR_MINIO_ENDPOINT> <YOUR_MINIO_ACCESS_KEY_ID> <YOUR_MINIO_SECRET_ACCESS_KEY>
クライアントが適切に設定されたかどうかは、mc ls my-provider
を実行して確認できます。
手順 2 - バケットの作成
バックアップ用のバケットを作成します。 Velero では、他のコンテンツが含まれた既存のバケットを使用できないので、新しいバケットを使用する必要があります。
mc mb ${ALIAS}/<YOUR_BUCKET>
手順 3 - ユーザーとポリシーの作成
次に、Velero がバケットにアクセスするためのユーザーとポリシーを作成します。
次のスニペットに含まれる <YOUR_MINIO_ACCESS_KEY_ID> と <YOUR_MINIO_SECRET_ACCESS_KEY> には、Velero が MinIO にアクセスするために使用する認証情報を指定します。 |
# Create user
mc admin user add $ALIAS <YOUR_MINIO_ACCESS_KEY_ID> <YOUR_MINIO_SECRET_ACCESS_KEY>
# Create policy
cat > velero-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::<YOUR_BUCKET>",
"arn:aws:s3:::<YOUR_BUCKET>/*"
]
}
]
}
EOF
mc admin policy add $ALIAS velero-policy velero-policy.json
# Bind user to policy
mc admin policy set $ALIAS velero-policy user=<YOUR_VELERO_ACCESS_KEY_ID>
最後に、新しいユーザーの認証情報を以下の形式で記述したファイルを作成します (この例では ./credentials-velero
)。
[default]
aws_access_key_id=<YOUR_VELERO_ACCESS_KEY_ID>
aws_secret_access_key=<YOUR_VELERO_SECRET_ACCESS_KEY>
手順 4 - Velero のインストールと起動
以下の velero install
コマンドを実行します。 これにより、velero
という名前空間が作成され、Velero を実行するのに必要なリソースがすべてインストールされます。
velero install --provider aws \
--plugins velero/velero-plugin-for-aws:v1.2.0 \
--bucket <YOUR_BUCKET> \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--use-restic \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=<YOUR_ENDPOINT> \
--wait
Velero がクラスタにインストールされたら、新しい velero
名前空間を確認します。 以下のように、Velero デプロイと restic デーモンセットがあれば成功です。
$ kubectl get pods --namespace velero
NAME READY STATUS RESTARTS AGE
restic-5vlww 1/1 Running 0 2m
restic-94ptv 1/1 Running 0 2m
restic-ch6m9 1/1 Running 0 2m
restic-mknws 1/1 Running 0 2m
velero-68788b675c-dm2s7 1/1 Running 0 2m
restic はデーモンセットなので、Kubernetes クラスタ内のノード 1 つにつき 1 つの Pod が存在します。
バックアップの作成
クラスタへの Velero のインストールが完了すると、管理コンソールのナビゲーションバーに Snapshots オプションが表示されるようになります。

このオプションが表示されれば、バックアップの作成を始める準備は完了です。 このオプションが表示されない場合は、 トラブルシューティング を参照してください。
オプション 1 - KOTS CLI を使用したバックアップ作成
バックアップを作成するには、以下を実行します。
kubectl kots backup --namespace <your namespace>
オプション 2 - KOTS 管理者コンソールを使用したバックアップ作成
ナビゲーションバーの Snapshots を選択します。 デフォルトでは Full Snapshots が選択されています。 これが推奨オプションです。

Start a snapshot ボタンをクリックします。

バックアップの復元
オプション 1 - スナップショットからのバックアップ復元
S3 互換ストレージに保存済みのバックアップから復元するには、Kubernetes クラスタに Velero がインストールされており、バックアップが格納されているストレージバケットに Velero がアクセスできる必要があります。 EKS を使用する場合に CircleCI Server を復元するには、CircleCI Server のインスタンスが事前にインストールされている必要があります。 GKE や他のプラットフォームを使用する場合は、クラスタに Velero さえインストールされていれば機能します。
新しいクラスタの場合または Velero の再インストールが必要な場合は、上記で生成したのと同じ認証情報を使用してインストールを行う必要があります。 |
オプション 2 - KOTS CLI を使用したバックアップ作成
KOTS CLI を使用してバックアップを復元するには、以下のコマンドを実行してバックアップのリストを取得します。
kubectl kots get backups
復元プロセスを開始するには、前述のコマンドで取得したバックアップ名を使用して、以下のコマンドを実行します。
kubectl kots restore --from-backup <backup-instance-id>
オプション 3 - KOTS 管理者コンソール UI を使用したバックアップ復元
バックアップ時と同様に、KOTS 管理者コンソールの Snapshots に移動します。 今回は、復元アイコン付きのバックアップがすべて表示されます。 使用するバックアップを選択し、復元を選択します。

復元すると、CircleCI サービス用に新しいロードバランサーが作成されます。 その結果、 KOTS 管理者コンソールで DNS レコードまたはホスト名と IP の設定を更新する必要があります。 また、Nomad クライアントに指定する nomad server endpoint も更新することをお勧めします。 |
既存の Nomad クライアントを使用している場合、Nomad サーバークラスタに接続する前にクライアントを再起動する必要があります。 |
CircleCI Server が復元され、運用可能な状態になるまで、約 10 ~ 15 分かかります。
オプション - KOTS 使用したバックアップのスケジュール設定
定期的なバックアップスケジュールを設定するには、KOTS 管理者コンソールで Snapshots、Settings & Schedule の順に選択します。

ここでは、スケジュール設定をはじめ、スナップショットに関する設定を行えます。

バックアップと復元のトラブルシューティング
[Snapshots (スナップショット)] オプションが KOTS 管理者コンソールに表示されない
KOTS 管理者コンソールに [Snapshots (スナップショット)] オプションが表示されない場合、以下を試してください。
-
使用している KOTS バージョンがスナップショットをサポートしていることを確認します。 現時点では、v1.40.0 以上が推奨されます。
$ kubectl kots version
Replicated KOTS 1.40.0
-
Velero がデプロイされ、適切に動作していることを確認します。 Velero のログは、以下のコマンドで確認できます。
$ kubectl logs deployment/velero --namespace velero
Velero の再インストールが必要な場合があります。
-
お使いのライセンスでスナップショットを利用できることを確認します。 確認するには、カスタマーサポートチームにご連絡ください。
バックアッププロセスまたは復元プロセスでエラーが発生した
バックアップまたは復元プロセスでエラーが発生した場合は、まず Velero ログを確認してください。 上記のコマンドの結果 4XX エラーが見つかった場合、ストレージバケットへのアクセスの問題が原因の可能性があります。
-
バケットが存在していることと、想定するリージョンにあることを確認します。
-
Velero に指定した認証情報でバケットにアクセスできることを確認します。
-
問題が解決しない場合は、新しいバケット情報を指定して Velero のインストールコマンドを再び実行する必要があります。
また、velero
名前空間にある Pod のステータスを確認します。
$ kubectl get pods --namespace velero
NAME READY STATUS RESTARTS AGE
restic-5vlww 1/1 Pending 0 10m
restic-94ptv 1/1 Running 0 10m
restic-ch6m9 1/1 Pending 0 10m
restic-mknws 1/1 Running 0 10m
velero-68788b675c-dm2s7 1/1 Running 0 10m
上記の例では、いくつかの restic Pod が保留状態です。これは利用可能な CPU リソースまたはメモリリソースがノードに割り当てられるまで待機していることを意味します。 この場合、restic に合わせたノードのスケーリングが必要な場合があります。
ドキュメントの改善にご協力ください
このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。
- このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
- ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
- CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。 フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。
サポートが必要ですか
CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。
または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.