CircleCI Server v3.x インストール ステップ 3
CircleCI サーバー v3.x ビルドサービスのインストールステップを開始する前に、 ステップ 1: 前提条件 と ステップ 2: コアサービスのインストールが実行済みであることを確認してください。

以下のセクションでは、< > の中に表示される認証情報の項目にご自身の情報を入力してください。 |
ステップ 3: 実行環境のインストール
出力プロセッサ
出力プロセッサは、 Normad クライアントからの出力処理を行います。 システムの速度が低下している場合にスケーリングするための重要なサービスです。 要求に応じてサービスをスケールアップできるよう、出力プロセッサのレプリカセットを増やすことをお勧めします。
名前空間を変更して kubectl kots admin-console -n <YOUR_CIRCLECI_NAMESPACE>
を実行し、KOTS 管理者コンソールにアクセスします。
設定で次の項目を探して入力します。
. [Output Processor Load Balancer (出力プロセッサ ロードバランサー) のホストネーム]: 次のコマンドにより、サービスの IP アドレスを取得します
+
kubectl get service output-processor --namespace=<YOUR_CIRCLECI_NAMESPACE>
-
[Save your configuration (設定を保存)]: Nomad クライアントの設定の完了後、設定のデプロイと確認を行います。
Nomad クライアント
概要で述べたように、Nomad は CircleCI が CircleCI ジョブのスケジュール設定 (Nomad サーバー経由) と実行 (Nomad クライアント経由) に使用するワークロードオーケストレーションツールです。
Nomad クライアントは Kubernetes クラスタの外部にインストールされ、コントロールプレーン(Nomad サーバー)はクラスタ内にインストールされます。 Nomad クライアントと Nomad コントロールプレーン間の通信は、 mTLS によって保護されます。 Nomad クライアントのインストールが完了すると、 mTLS 証明書、プライベートキー、および認証局が出力されます。
完了すると、 CircleCI Server の設定を更新して、 Nomad コントロールプレーンが Nomad クライアントと通信できるようになります。
Terraform によるクラスタの作成
CircleCI では、任意のクラウドプロバイダーに Nomad クライアントをインストールできるように Terraform モジュールをキュレーションしています。 モジュールは、 AWS と GCP の両方の Terraform 設定ファイル(main.tf
)例を含む、 パブリックリポジトリ で参照できます。 main.tf
を完了するには、クラスタとサーバーのインストールに関する情報が必要です。 以下でその情報を入手する方法を説明します。
Nomad Autoscaler もここでセットアップする場合は、この Terraform の設定にいくつかの要件を含められるため、本ガイドの Nomad Autoscaler のセクションを参照してください。 |
AWS
クラスタおよびサーバのインストールに関する情報を Terraform 設定ファイル (main.tf
) のフィールドに入力します。 変数の完全な例と完全なリストについては、 こちら を参照してください。
-
Server_endpoint: Nomad サーバーエンドポイント(Nomad サーバー外部ロードバランサーの外部 IP アドレス)が必要です。 以下のコマンドで情報を入手します。
kubectl get service nomad-server-external --namespace=<YOUR_CIRCLECI_NAMESPACE>
-
クラスタの Subnet ID (subnet) 、 VPC ID (vpcId) 、 DNS server (dns_server): 以下のコマンドを実行して、クラスタの VPC ID ((vpcId)、CIDR (serviceIpv4Cidr)、およびサブネット (サブネットの ID)を入手します。
aws eks describe-cluster --name=<YOUR_CLUSTER_NAME>
すると、以下のようなコマンドが返されます。
{... "resourcesVpcConfig": { "subnetIds": [ "subnet-033a9fb4be69", "subnet-04e89f9eef89", "subnet-02907d9f35dd", "subnet-0fbc63006c5f", "subnet-0d683b6f6ba8", "subnet-079d0ca04301" ], "clusterSecurityGroupId": "sg-022c1b544e574", "vpcId": "vpc-02fdfff4c", "endpointPublicAccess": true, "endpointPrivateAccess": false ... "kubernetesNetworkConfig": { "serviceIpv4Cidr": "10.100.0.0/16" }, ... }
次に、見つけた VPCID を使用して次のコマンドを実行し、クラスタの CIDR ブロックを取得します。 AWS の場合、 DNS サーバーは CIDR ブロック (
CidrBlock
) の3番目の IP です。たとえば、CIDR ブロックが10.100.0.0/16
の場合、 3 番目の IP は10.100.0.2
になります。aws ec2 describe-vpcs --filters Name=vpc-id,Values=<YOUR_VPCID>
すると、以下のようなコマンドが返されます。
{... "CidrBlock": "192.168.0.0/16", "DhcpOptionsId": "dopt-9cff", "State": "available", "VpcId": "vpc-02fdfff4c" ...}
適切な情報を入力したら main.tf
ファイルのディレクトリから次のコマンドを実行することにより、Nomad クライアントをデプロイすることができます。
terraform init
terraform plan
terraform apply
Terraform は、Nomad クライアントのスピンアップが完了すると、CircleCI Server で Nomad コントロールプレーンを設定するために必要な証明書とキーを出力します。 それらを安全な場所にコピーします。 この適用プロセスには通常 1 分しかかかりません。
GCP
CircleCI Server のデプロイ時に作成した Nomad コントロールプレーン(Nomad サーバー)の IP アドレスが必要になります。 以下のコマンドを実行することで IP アドレスを取得できます。
kubectl get service nomad-server-external --namespace=<YOUR_CIRCLECI_NAMESPACE>
以下の情報も必要です。
-
Nomad クライアントを実行する GCP プロジェクト
-
Nomad クライアントを実行する GCP ゾーン
-
Nomad クライアントを実行する GCP リージョン
-
Nomad クライアントを実行する GCP ネットワーク
-
Nomad クライアントを実行する GCP サブネットワーク
以下の例をローカル環境にコピーして、特定の設定に必要な情報を入力します。
variable "project" {
type = string
default = "<your-project>"
}
variable "region" {
type = string
default = "<your-region>"
}
variable "zone" {
type = string
default = "<your-zone>"
}
variable "network" {
type = string
default = "<your-network-name>"
# if you are using a shared vpc, provide the network endpoint rather than the name. eg:
# default = "https://www.googleapis.com/compute/v1/projects/<host-project>/global/networks/<your-network-name>"
}
variable "subnetwork" {
type = string
default = "<your-subnetwork-name>"
# if you are using a shared vpc, provide the network endpoint rather than the name. eg:
# default = "https://www.googleapis.com/compute/v1/projects/<service-project>/regions/<your-region>/subnetworks/<your-subnetwork-name>"
}
variable "server_endpoint" {
type = string
default = "<nomad-server-loadbalancer>:4647"
}
variable "nomad_auto_scaler" {
type = bool
default = false
description = "If true, terraform will create a service account to be used by nomad autoscaler."
}
variable "enable_workload_identity" {
type = bool
default = false
description = "If true, Workload Identity will be used rather than static credentials'"
}
variable "k8s_namespace" {
type = string
default = "circleci-server"
description = "If enable_workload_identity is true, provide application k8s namespace"
}
provider "google-beta" {
project = var.project
region = var.region
zone = var.zone
}
module "nomad" {
source = "git::https://github.com/CircleCI-Public/server-terraform.git//nomad-gcp?ref=3.4.0"
zone = var.zone
region = var.region
network = var.network
subnetwork = var.subnetwork
server_endpoint = var.server_endpoint
machine_type = "n2-standard-8"
nomad_auto_scaler = var.nomad_auto_scaler
enable_workload_identity = var.enable_workload_identity
k8s_namespace = var.k8s_namespace
unsafe_disable_mtls = false
assign_public_ip = true
preemptible = true
target_cpu_utilization = 0.50
}
output "module" {
value = module.nomad
}
適切な情報を入力したら、以下を実行することにより Normad クライアントをデプロイできます。
terraform init
terraform plan
terraform apply
Terraform は、Nomad クライアントのスピンアップが完了すると、CircleCI Server で Nomad コントロールプレーンを設定するために必要な証明書とキーを出力します。 それらを安全な場所にコピーします。
Nomad Autoscaler
Nomad は、クライアントがクラウドプロバイダの自動スケーリングリソースによって管理されている場合、 Nomad クライアントを自動的にスケールアップまたはスケールダウンするユーティリティを提供します。 Nomad Autoscaler を使うと、自動スケーリングリソースを管理し、その場所を指定する権限をユーティリティに与えるだけで済みます。 このリソースは KOTS 経由で有効化することができ、Nomad サーバーと Nomad Autoscaler サービスをデプロイします。 下記ではご自身のプロバイダーに Nomad Autoscaler を設定する方法を概説します。
自動スケーリンググループや管理対象のインスタンスグループを作成すると、最大および最小の Nomad クライアント数によって、対応する値セットが上書きされます。 これらの値と Terraform で使った値の競合を避けるため、同じ値を使用することを推奨します。 |
このサービスが不要な場合は、 Save config ボタンをクリックし、インストール環境を更新し、サーバーを再デプロイしてください。
AWS
. IAM ユーザーまたは Nomad Autoscaler のロールとポリシーを作成します。 以下のいづれか方法で実行します。: nomad_auto_scaler = true
を設定すると、 * Nomad モジュール が IAM ユーザーを作成し、キーを出力します。 詳細については、リンクの例を参照してください。 既にクライアントを作成済みの場合は、変数をアップデートして terraform apply
を実行します。 作成されたユーザーアクセスキーは Terraform の出力で使用できます。 * 以下の IAM ポリシーを使用して、手動で Nomad Autoscaler IAM ユーザーを作成することも可能です。 その場合、ユーザーにアクセスキーとシークレットキーを生成する必要があります。 Nomad Autoscaler 用の サービスアカウントのロール を作成し、次の IAM ポリシーを添付します。
+
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"autoscaling:CreateOrUpdateTags",
"autoscaling:UpdateAutoScalingGroup",
"autoscaling:TerminateInstanceInAutoScalingGroup"
],
"Resource": "<<Your Autoscaling Group ARN>>"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"autoscaling:DescribeScalingActivities",
"autoscaling:DescribeAutoScalingGroups"
],
"Resource": "*"
}
]
}
.
KOTS 管理者コンソールで Nomad Autoscaler を `enabled` に設定します。
*最大の Node 数を設定します* : ASG の最大値として現在設定されている値を上書きします。
この値と Terraform で設定された値を変えないことをお勧めします。
. *最小の Node 数を設定します* : ASG の最小値として現在設定されている値を上書きします。 この値と Terraform で設定された値を変えないことをお勧めします。
. クラウドプロバイダーを選択します。: `AWS EC2`.
. 自動スケーリンググループのリージョンを追加します。
. 以下のいずれかを選択します。 Nomad Autoscaler ユーザーのアクセスキーとシークレットキーを追加します。
.. または、Nomad Autoscaler のロールの ARN を追加します。
. Nomad クライアントが作成された自動スケーリンググループの名前を追加します。
GCP
Nomad Autoscaler のサービスアカウントを作成します。 変数`nomad_auto_scaler = true` と `enable_workload_identity = false` を設定すると、* link:https://github.com/CircleCI-Public/server-terraform/tree/main/nomad-gcp[Nomad モジュール] がサービスアカウントを作成し、ファイルとキーを出力します。 詳細については、リンクの例を参照してください。 既にクライアントを作成済みの場合は、変数をアップデートして `terraform apply` を実行します。 作成されたユーザーのキーは、`nomad-as-key.json` という名前のファイルにあります。 GKE link:https://circleci.com/docs/server-3-install-prerequisites#enabling-workload-identity-in-gke[Workload Identities] を使用している場合は、変数を `nomad_auto_scaler = true` と `enable_workload_identity = true` に設定します。 * Nomad GCP サービスアカウントを手動で作成することも可能です。 サービスアカウントには `compute.admin` のロールが必要です。 link:https://circleci.com/docs/server-3-install-prerequisites#enabling-workload-identity-in-gke[Workload Identity] を使用している場合は、`iam.workloadIdentityUser` ロールも必要です。 Nomad Autoscaler を `enabled` に設定します。 最大 Node 数* を設定します。 最小 Node 数* を設定します。 クラウドプロバイダーを選択します ( `Google Cloud Platform`)。 プロジェクト ID を追加します。 管理対象のインスタンスグループ名を追加します。 インスタンスグループのタイプは、link:https://cloud.google.com/compute/docs/instance-groups/#types_of_managed_instance_groups[ゾーンまたはリージョン].です。 . 以下のいずれかを選択します。 Nomad Autoscaler の GCP サービスアカウントの JSON を指定します。 link:https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[Workload Identity]を使用している場合は、Nomad Autoscaler サービスアカウントのメールアドレスを使用します。 GCP クラスタで Workload Identity を有効化する手順は、link:https://circleci.com/docs/ja/server-3-install-prerequisites#enabling-workload-identity-in-gke[こちら]を参照してください。 .. `nomad-autoscaler` (kubernetes) サービスアカウントの Workload Identity を有効にします。
gcloud iam service-accounts add-iam-policy-binding <YOUR_SERVICE_ACCOUNT_EMAIL> \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:<GCP_PROJECT_ID>.svc.id.goog[circleci-server/nomad-autoscaler]"
静的 JSON 認証情報から Workload Identity に切り替える場合は、GCP および CircleCI KOTS 管理者コンソールからキーを削除する必要があります。 |
設定とデプロイ
Nomad クライアントの導入が完了したら、 CircleCI Server と Nomad コントロールプレーンを設定できます。 名前空間を変更して `kubectl kots admin-console -n <YOUR_CIRCLECI_NAMESPACE>`を実行し、KOTS 管理者コンソールにアクセスします。
設定で次の項目を入力します。
-
Nomad Load Balancer (Normad ロードバランサー)(必須)
kubectl get service nomad-server-external --namespace=<YOUR_CIRCLECI_NAMESPACE>
-
[Nomad Server Certificate (Nomad サーバーの証明書)](必須):
terraform apply
からの出力で提供されます。 -
[Nomad Server Private Key (Nomad サーバーのプライベートキー)](必須):
terraform apply
からの出力で提供されます。 -
Nomad Server Certificate Authority (Nomad サーバーの証明書認証局)](必須):
terraform apply
からの出力で提供されます。 -
Build Agent Image (ビルドエージェントイメージ) : カスタム Docker レジストリを使用して CircleCI ビルドエージェントを提供する場合は、カスタマサポートにお問い合わせください。
[Save config (構成の保存)] ボタンをクリックし、CircleCI Server を更新して再デプロイします。
Normad クライアントの確認
CircleCI Server のインストールをテストできる realitycheck というプロジェクトを作成しました。 CircleCI はこのプロジェクトをフォローし、システムが期待どおりに動作しているかを確認します。 引き続き次のステップを実行すると、 realitycheck のセクションが赤から緑に変わります。
realitycheck を実行するには、リポジトリのクローンを実行する必要があります。 Github の設定に応じて、以下のいずれかを実行します。
Github Cloud
git clone -b server-3.0 https://github.com/circleci/realitycheck.git
GitHub Enterprise
git clone -b server-3.0 https://github.com/circleci/realitycheck.git
git remote set-url origin <YOUR_GH_REPO_URL>
git push
レポジトリのクローンに成功したら、CircleCI Server 内からフォローすることができます。 以下の変数を設定する必要があります。 詳細は、 リポジトリ READMEを参照してください。
名前 | 値 |
---|---|
CIRCLE_HOSTNAME | <YOUR_CIRCLECI_INSTALLATION_URL> |
CIRCLE_TOKEN | <YOUR_CIRCLECI_API_TOKEN> |
名前 | 環境変数キー | 環境変数値 |
---|---|---|
org-global | CONTEXT_END_TO_END_TEST_VAR | 空欄のまま |
individual-local | MULTI_CONTEXT_END_TO_END_VAR | 空欄のまま |
環境変数とコンテキストを設定したら、 realitycheck テストを再実行します。 機能とリソースジョブが正常に完了したことが表示されます。 テスト結果は次のようになります。

VM サービス
VM サービスは、VM とリモート Docker ジョブを設定します。 スケーリング ルールなど、さまざまなオプションを構成することができます。 VM サービスは、 EKS および GKE のインストールに固有のものです。これは、これらのクラウドプロバイダーの機能に特に依存しているためです。
AWS
-
セキュリティグループの作成に必要な情報を入手します。
以下のコマンドにより、VPC ID (
vpcId
), CIDR Block (serviceIpv4Cidr
), Cluster Security Group ID (clusterSecurityGroupId
) および Cluster ARN (arn
) 値が返されます。これらの情報はこのセクションを通して必要です。aws eks describe-cluster --name=<your-cluster-name>
-
セキュリティーグループを作成します。
以下のコマンドを実行して、VM サービス用のセキュリティーグループを作成します。
aws ec2 create-security-group --vpc-id "<YOUR_VPCID>" --description "CircleCI VM Service security group" --group-name "circleci-vm-service-sg"
これにより次の手順で使用するグループ ID が出力されます。
{ "GroupId": "sg-0cd93e7b30608b4fc" }
-
セキュリティーグループ Nomad を適用します。
作成したセキュリティーグループと CIDR ブロック値を使ってセキュリティーグループを以下に適用します。
aws ec2 authorize-security-group-ingress --group-id "<YOUR_GroupId>" --protocol tcp --port 22 --cidr "<YOUR_serviceIpv4Cidr>"
aws ec2 authorize-security-group-ingress --group-id "<YOUR_GroupId>" --protocol tcp --port 2376 --cidr "<YOUR_serviceIpv4Cidr>"
CircleCI Server とは異なるサブネットに Nomad クライアントを作成した場合は、サブネット CIDR ごとに上記の 2 つのコマンドを再実行する必要があります。 -
セキュリティーグループに SSH接続を適用します。
次のコマンドを実行してセキュリティグループルールを適用し、ユーザーがジョブに SSH 接続できるようにします。
aws ec2 authorize-security-group-ingress --group-id "<YOUR_GroupId>" --protocol tcp --port 54782
-
ユーザーを作成します。
プログラムでのアクセス権を持つ新規ユーザーを作成します。
aws iam create-user --user-name circleci-vm-service
vm-service では、オプションで AWS キーの代わりに サービスアカウントのロールの使用もサポートしています。 ロールを使用する場合は、以下のステップ 6 のポリシーを使って以下の 手順を実行します。 サービスアカウントの作成時、名前が
vm-service
と設定されていることを確認してください。完了したら、ステップ 9 に進みます。手順 9 では、KOTS で VM サービスを有効化します。
-
ポリシーを作成します。
以下の内容の
policy.json
ファイルを作成します。 ステップ 2 で作成した VM サービスセキュリティグループの ID (VMServiceSecurityGroupId
) と VPC ID (vpcID
) を入力します。{ "Version": "2012-10-17", "Statement": [ { "Action": "ec2:RunInstances", "Effect": "Allow", "Resource": [ "arn:aws:ec2:*::image/*", "arn:aws:ec2:*::snapshot/*", "arn:aws:ec2:*:*:key-pair/*", "arn:aws:ec2:*:*:launch-template/*", "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:placement-group/*", "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/<YOUR_VMServiceSecurityGroupID>" ] }, { "Action": "ec2:RunInstances", "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": { "aws:RequestTag/ManagedBy": "circleci-vm-service" } } }, { "Action": [ "ec2:CreateVolume" ], "Effect": "Allow", "Resource": [ "arn:aws:ec2:*:*:volume/*" ], "Condition": { "StringEquals": { "aws:RequestTag/ManagedBy": "circleci-vm-service" } } }, { "Action": [ "ec2:Describe*" ], "Effect": "Allow", "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:*/*", "Condition": { "StringEquals": { "ec2:CreateAction" : "CreateVolume" } } }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:*/*", "Condition": { "StringEquals": { "ec2:CreateAction" : "RunInstances" } } }, { "Action": [ "ec2:CreateTags", "ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances", "ec2:AttachVolume", "ec2:DetachVolume", "ec2:DeleteVolume" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:*/*", "Condition": { "StringEquals": { "ec2:ResourceTag/ManagedBy": "circleci-vm-service" } } }, { "Action": [ "ec2:RunInstances", "ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:subnet/*", "Condition": { "StringEquals": { "ec2:Vpc": "<YOUR_vpcID>" } } } ] }
-
ポリシーをユーザーにアタッチします。
policy.json ファイルを作成したら、IAM ポリティーと作成したユーザーにアタッチします。
aws iam put-user-policy --user-name circleci-vm-service --policy-name circleci-vm-service --policy-document file://policy.json
-
ユーザー用のアクセスキーとシークレットを作成します。
作成していない場合は、
circleci-vm-service
ユーザー用のアクセスキーとシークレットが必要です。 以下のコマンドを実行して作成することができます。aws iam create-access-key --user-name circleci-vm-service
-
サーバーを設定します。
VM サービスを KOTS 管理者コンソールから設定します。 利用可能な設定オプションの詳細については、 VM サービスガイドを参照してください。
フィールドの設定が完了したら、設定を保存し、更新したアプリケーションをデプロイします。
GCP
以下のセクションを完了するにはクラスタに関する追加情報が必要です。 次のコマンドを実行します。
gcloud container clusters describe
このコマンドは、次のような情報を返します。この情報には、ネットワーク、リージョン、および次のセクションを完了するために必要なその他の詳細情報が含まれます。
addonsConfig:
gcePersistentDiskCsiDriverConfig:
enabled: true
kubernetesDashboard:
disabled: true
networkPolicyConfig:
disabled: true
clusterIpv4Cidr: 10.100.0.0/14
createTime: '2021-08-20T21:46:18+00:00'
currentMasterVersion: 1.20.8-gke.900
currentNodeCount: 3
currentNodeVersion: 1.20.8-gke.900
databaseEncryption:
…
-
ファイアウォール ルールを作成します。
以下のコマンドを実行して、GKE の VM サービス用のファイヤーウォール ルールを作成します。
gcloud compute firewall-rules create "circleci-vm-service-internal-nomad-fw" --network "<network>" --action allow --source-ranges "0.0.0.0/0" --rules "TCP:22,TCP:2376"
gcloud compute firewall-rules create "circleci-vm-service-internal-k8s-fw" --network "<network>" --action allow --source-ranges "<clusterIpv4Cidr>" --rules "TCP:22,TCP:2376"
gcloud compute firewall-rules create "circleci-vm-service-external-fw" --network "<network>" --action allow --rules "TCP:54782"
-
ユーザーを作成します。
VM サービス専用の一意のサービス アカウントを作成することをお勧めします。 コンピューティング インスタンス管理者 (ベータ版) ロールは、VM サービスを運用するための広範な権限を持っています。 アクセス許可をより詳細に設定したい場合は、 コンピューティング インスタンス管理者 (ベータ版) ロールのドキュメントを参照してください。
gcloud iam service-accounts create circleci-server-vm --display-name "circleci-server-vm service account"
CircleCI Server を共有 VCP にデプロイする場合は、 VM ジョブを実行するプロジェクトにこのユーザーを作成します。 -
サービスアカウントのメールアドレスを取得します。
gcloud iam service-accounts list --filter="displayName:circleci-server-vm service account" --format 'value(email)'
-
ロールをサービスアカウントに適用します。
コンピューティングインスタンス管理者 (ベータ版) ロールをサービスアカウントに適用します。
gcloud projects add-iam-policy-binding <YOUR_PROJECT_ID> --member serviceAccount:<YOUR_SERVICE_ACCOUNT_EMAIL> --role roles/compute.instanceAdmin --condition=None
さらに
gcloud projects add-iam-policy-binding <YOUR_PROJECT_ID> --member serviceAccount:<YOUR_SERVICE_ACCOUNT_EMAIL> --role roles/iam.serviceAccountUser --condition=None
-
JSON キーファイルを取得します。
GKE で Workload Identity を使用している場合、この手順は不要です。
以下のコマンドを実行すると、
circleci-server-vm-keyfile
という名前のファイルがローカル作業ディレクトリに作成されます。 サーバーインストールを設定する際に必要になります。gcloud iam service-accounts keys create circleci-server-vm-keyfile --iam-account <YOUR_SERVICE_ACCOUNT_EMAIL>
-
サービスアカウントで Workload Identity を有効にします。
この手順は、GKE で Workload Identity を使用している場合のみ実行する必要があります。 Workload Identity を有効化する手順は、 こちらを参照してください。
gcloud iam service-accounts add-iam-policy-binding <YOUR_SERVICE_ACCOUNT_EMAIL> \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:<GCP_PROJECT_ID>.svc.id.goog[circleci-server/vm-service]"
静的 JSON 認証情報から Workload Identity に切り替える場合は、GCP および CircleCI KOTS 管理者コンソールからキーを削除する必要があります。 |
-
サーバーを設定します。
VM サービスを KOTS 管理者コンソールから設定します。 利用可能な設定オプションの詳細については、 VM サービスガイドを参照してください。
フィールドの設定が完了したら、設定を保存し、更新したアプリケーションをデプロイします。
VM サービスの検証
CircleCI Server の設定とデプロイが完了したら、VM サービスが適切に動作しているか確認する必要がありあます。 CircleCI Server 内で、 realitycheck プロジェクトを再実行できます。 VM サービスジョブは完了しているはずです。 この時点で、すべてのテストが合格しているはずです。
ランナー
概要
CircleCI のランナーには、追加のサーバー設定は不要です。 CircleCI Server はランナーと連携する準備ができています。 ただし、ランナーを作成し、CircleCI Server のインストールを認識するようにランナーエージェントを設定する必要があります。 ランナー設定の詳細については、 ランナーのドキュメント を参照してください。
ランナーには組織ごとに1つ名前空間が必要です。 CircleCI Server には複数の組織が存在する場合があります。 CircleCI Server 内に複数の組織が存在する場合、各組織につき1つランナーの名前空間を設定する必要があります。 |
ドキュメントの改善にご協力ください
このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。
- このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
- ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
- CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。 フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。
サポートが必要ですか
CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。
または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.