CircleCI Server v3.x インストール ステップ 4
このページの内容
- ステップ 4: ポストインストール
- バックアップとリストアの設定
- 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 管理者コンソールを使用したバックアップ作成
- Orb
- メール通知
- 次に読む
CircleCI Server v3.x のポストインストールステップを開始する前に、 ステップ 1 - 前提条件、 ステップ 2 - コアサービスのインストール、 ステップ 3 - ビルドサービスのインストールが実行済みであることを確認してください。

以下のセクションでは、< > の中に表示される認証情報の項目にご自身の情報を入力してください。 |
ステップ 4: ポストインストール
バックアップとリストアの設定
AWS での CircleCI Server 3.x のバックアップ
これらの手順は、 こちら の 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: Velero の権限の設定]で作成した、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
ロールも必要です。
静的 JSON 認証情報から Workload Identity に切り替える場合は、GCP および CircleCI KOTS 管理者コンソールからキーを削除する必要があります。 |
手順 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 ボタンをクリックします。

Orb
CircleCI Server システムには、固有のローカル Orb レジストリが含まれています。 このレジストリは、CircleCI Server からのみアクセスできます。 設定ファイルで参照している Orb はすべて、この CircleCI Server Orb レジストリに含まれる Orb を参照します。 プロジェクト設定ファイルで参照された Orb はすべて、 server orb レジストリに含まれる Orb を参照します。 Orb のメンテナンスはご自身で行う必要があります。 それには以下が含まれます。
-
パブリック レジストリからの Orb のコピー
-
以前コピーした Orb の更新
-
会社のプライベート Orb の登録 (存在する場合)
詳細およびこれらのタスクを完了するための手順については、 サーバーでの Orb ガイドを参照してください。
メール通知
ビルドの通知はメールで送信されます。 ここではメールによるビルド通知設定方法の詳細について説明します。
KOTS の管理コンソールにアクセスします。 名前空間を変更して下記を実行し、KOTS 管理者コンソールを表示します。
kubectl kots admin-console -n <YOUR_CIRCLECI_NAMESPACE>
Settings の Email Notifications セクションに行き、下記の詳細を入力してインストール環境のメール通知を設定します。
Settings の Email Notifications セクションに行き、下記の詳細を入力してインストール環境のメール通知を設定します。
-
Email Submission server hostname (メール送信サーバーのホスト名) (必須) : 送信サーバーのホスト名を指定します (例えば SendGrid の場合は smtp.sendgrid.net を使用)。
-
Username (ユーザー名)](必須): 送信サーバーの認証に使用するユーザー名を指定します。 一般的には、ユーザーのメールアドレスと同一になります。
-
Password (パスワード)](必須) : 送信サーバーの認証に使用するパスワードを指定します。
-
[Port (ポート)](オプション): 送信サーバーのポートを指定します。 通常は 25 か 587 です。 メール送信にはポート 465 もよく使われますが、このポートは StartTLS ではなく暗黙的 TLS に使用することがほとんどです。 CircleCI Server では、送信の暗号化には StartTLS のみをサポートしています。
ポート 25 のアウトバウンド接続は、ほとんどのクラウド プロバイダーでブロックされます。 このポートを選択する場合は、通知の送信に失敗する可能性があることに留意してください。 -
[Enable StartTLS (StartTLS の有効化)]: 有効化すると、メール送信が暗号化されます。
デフォルトでは StartTLS がメールの暗号化に使用されますが、これを無効にするのは、他にトラフィックの機密性を保証できる場合のみにしてください。 -
Email from address (メールの送信元アドレス)] (必須): メールの送信元アドレスを指定します。
[Save config (構成の保存)] ボタンをクリックし、CircleCI Server を更新して再デプロイします。
ドキュメントの改善にご協力ください
このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。
- このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
- ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
- CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。 フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。
サポートが必要ですか
CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。
または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.