ステップ 3 - 実行環境

1. Nomad クライアント

Nomad は、CircleCI が CircleCI ジョブのスケジュール設定 (Nomad サーバー経由) と実行 (Nomad クライアント経由) に使用するワークロードオーケストレーションツールです。

Nomad クライアントは、Kubernetes クラスタの外部にインストールされ、コントロールプレーン（Nomad サーバー）はクラスタ内にインストールされます。 Nomad クライアントと Nomad コントロールプレーン間の通信は、 mTLS によって保護されます。 Nomad クライアントのインストールが完了すると、 mTLS 証明書、プライベートキー、および認証局が出力されます。

a. Terraform でクラスタを作成します

CircleCI では、任意のクラウドプロバイダーに Nomad クライアントをインストールできるように Terraform モジュールをキュレーションしています。このモジュールについては、パブリックリポジトリを参照してください。AWS と GCP の両方の Terraform 設定ファイル例も含まれています。

AWS クラスタ

Terraform モジュールに必要な変数を入力するにはクラスタおよびサーバのインストール環境に関する情報が必要です。変数の完全な例と完全なリストについては、 AWS Terraform の設定例を参照してください。

Server_endpoint: ポート番号 4647 を付加した CircleCI アプリケーションのドメイン名です。
クラスタの サブネット ID (subnet) 、 VPC ID (vpc_id) 、 DNS サーバー (dns_server): 次のコマンドを実行して、クラスタの VPC ID (vpcId) とサブネット (subnetIds) を入手します。
```
# Fetch VPC ID
aws eks describe-cluster --name=<cluster-name> --query "cluster.resourcesVpcConfig.vpcId" --region=<region> --output text | xargs

# Fetch Subnet IDs
aws eks describe-cluster --name=<cluster-name> --query "cluster.resourcesVpcConfig.subnetIds" --region=<region> --output text | xargs
```
すると、以下のようなコマンドが返されます。
```
# VPC Id
vpc-02fdfff4ca

# Subnet Ids
subnet-08922063f12541f93 subnet-03b94b6fb1e5c2a1d subnet-0540dd7b2b2ddb57e subnet-01833e1fa70aa4488
```
次に、見つけた VPCID を使用して次のコマンドを実行し、クラスタの CIDR ブロックを取得します。 AWS の場合、 DNS サーバーは CIDR ブロック (CidrBlock) の３番目の IP です。たとえば、CIDR ブロックが 10.100.0.0/16 の場合、 3 番目の IP は 10.100.0.2 になります。
```
aws ec2 describe-vpcs --filters Name=vpc-id,Values=<vpc-id> --query "Vpcs[].CidrBlock" --region=<region> --output text | xargs
```
すると、以下のようなコマンドが返されます。
```
192.168.0.0/16
```

適切な情報を入力したら、以下を実行することにより Normad クライアントをデプロイできます。

terraform init

terraform plan

terraform apply

Terraform は、Nomad クライアントのスピンアップが完了すると、CircleCI Server で Nomad コントロールプレーンを設定するために必要な証明書とキーを出力します。それらを安全な場所にコピーします。この適用プロセスの所要時間は、通常 1 分程度です。

GCP クラスタ

以下の情報が必要です。

CircleCI アプリケーションのドメイン名
Nomad クライアントを実行する GCP プロジェクト
Nomad クライアントを実行する GCP ゾーン
Nomad クライアントを実行する GCP リージョン
Nomad クライアントを実行する GCP ネットワーク
Nomad クライアントを実行する GCP サブネットワーク

変数の完全な例と完全なリストについては、 GCP Terraform の設定例を参照してください。

適切な情報を入力したら、以下を実行することにより Normad クライアントをデプロイできます。

terraform init

terraform plan

terraform apply

Terraform は、Nomad クライアントのスピンアップが完了すると、CircleCI Server で Nomad コントロールプレーンを設定するために必要な証明書とキーを出力します。それらを安全な場所にコピーします。

b. Nomad Autoscaler を設定します

Nomad は、クライアントがクラウドプロバイダの自動スケーリングリソースによって管理されている場合、 Nomad クライアントを自動的にスケールアップまたはスケールダウンすることができます。 Nomad Autoscaler を使う場合、自動スケーリングリソースを管理し、その場所を指定する権限をユーティリティに与える必要があります。 CircleCI の Nomad Terraform モジュールは権限リソースをプロビジョニングすることも、手動で実行することもできます。

AWS Autoscaler IAM/ロール

IAM ユーザーまたは Nomad Autoscaler のロールとポリシーを作成します。次の いずれか の方法で作成します。

変数 nomad_auto_scaler = true を設定すると、 Nomad モジュールが IAM ユーザーを作成し、キーを出力します。詳細については、リンクの例を参照してください。既にクライアントを作成済みの場合は、変数を更新して terraform apply を実行します。作成されたユーザーアクセスキーとシークレットキーは Terraform の出力で使用できます。
下記の IAM ポリシーを使って Nomad Autoscaler IAM ユーザーを手動で作成します。次に、このユーザー用のアクセスキーとシークレットキーを生成します。
Nomad Autoscaler 用のサービスアカウントのロールを作成し、下記の IAM ポリシーを添付します。

アクセスキーとシークレットキーを使用する場合、2 つの設定オプションがあります。

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": "*"
        }
    ]
}

GCP オートスケーラーのサービスアカウント

Nomad Autoscaler のサービスアカウントを作成します。次の いずれか の方法で作成します。

2. Nomad サーバー

Nomad クライアントを正常にデプロイし、権限リソースを取得したので、Nomad サーバーを設定できるようになりました。

a. Nomad ゴシップ暗号化キー

Nomad では通信を暗号化するためのキーが必要です。このキーは 32 バイトの長さである必要があります。値を紛失した場合、CircleCI が復元することはできません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

b. Nomad mTLS

CACertificate、certificate、privateKey は Terraform モジュールの出力でご確認ください。 base64 エンコードされています。

nomad:
  server:
    ...
    rpc:
      mTLS:
        enabled: true
        certificate: "<base64-encoded-certificate>"
        privateKey: "<base64-encoded-private-key>"
        CACertificate: "<base64-encoded-ca-certificate>"

c. Nomad Autoscaler

Nomad Autoscaler を有効にした場合は、 nomad の下に以下のセクションも含めます。

AWS

これらの値は Nomad Autoscaler の設定で作成済みです。

nomad:
  ...
  auto_scaler:
    enabled: true
    scaling:
      max: <max-node-limit>
      min: <min-node-limit>

    aws:
      enabled: true
      region: "<region>"
      autoScalingGroup: "<asg-name>"

      accessKey: "<access-key>"
      secretKey: "<secret-key>"
      # or
      irsaRole: "<role-arn>"

GCP

これらの値は Nomad Autoscaler の設定で作成済みです。

nomad:
  ...
  auto_scaler:
    enabled: true
    scaling:
      max: <max-node-limit>
      min: <min-node-limit>

    gcp:
      enabled: true
      project_id: "<project-id>"
      mig_name: "<instance-group-name>"

      region: "<region>"
      # or
      zone: "<zone>"

      workloadIdentity: "<service-account-email>"
      # or
      service_account: "<service-account-json>"

d. Helm のアップグレード

values.yaml ファイルへの変更を適用します。

namespace=<your-namespace>
helm upgrade circleci-server oci://cciserver.azurecr.io/circleci-server -n $namespace --version 4.0.0 -f <path-to-values.yaml>

3. Normad クライアントの確認

CircleCI では、CircleCI Server のインストールをテストできる realitycheck というプロジェクトを作成しました。今後このプロジェクトを監視し、システムが期待どおりに動作しているかを確認します。引き続き次のステップを実行すると、 realitycheck のセクションが赤から緑に変わります。

realitycheck を実行する前に、次のコマンドを実行して Nomad サーバーが Nomad クライアントと通信できるか確認して下さい。

kubectl -n <namespace> exec -it $(kubectl -n <namespace> get pods -l app=nomad-server -o name | tail -1) -- nomad node status

出力は以下のようになります。

ID        DC       Name              Class        Drain  Eligibility  Status
132ed55b  default  ip-192-168-44-29  linux-64bit  false  eligible     ready

realitycheck を実行するには、リポジトリのクローンを実行する必要があります。 Github の設定に応じて、以下のいずれかを実行します。

Github Cloud

git clone https://github.com/circleci/realitycheck.git

GitHub Enterprise

git clone https://github.com/circleci/realitycheck.git
git remote set-url origin <YOUR_GH_REPO_URL>
git push

レポジトリのクローンに成功したら、CircleCI Server 内からフォローすることができます。以下の変数を設定する必要があります。詳細は、リポジトリ README を参照してください。

Table 1. 環境変数
名前	値
CIRCLE_HOSTNAME	<YOUR_CIRCLECI_INSTALLATION_URL>
CIRCLE_TOKEN	<YOUR_CIRCLECI_API_TOKEN>
CIRCLE_CLOUD_PROVIDER	< `aws`, `gcp`, or `other` >

Table 2. コンテキスト
名前	環境変数キー	環境変数値
org-global	CONTEXT_END_TO_END_TEST_VAR	空欄のまま
individual-local	MULTI_CONTEXT_END_TO_END_VAR	空欄のまま

環境変数とコンテキストを設定したら、 realitycheck テストを再実行します。機能とリソースジョブが正常に完了したことが表示されます。テスト結果は次のようになります。

Screenshot showing the realitycheck project building in the CircleCI app

3. VM サービス

VM サービスにより、Linux VM、Windows、Arm の各実行環境で実行されるジョブやリモート Docker を使用するように設定されたジョブの仮想マシンを設定できます。スケーリングルールなど、さまざまなオプションの設定が可能です。 VM サービスは、 AWS および GCP インストール環境に固有のものです。これは、VMサービスがこれらのクラウドプロバイダーの特定の機能に依存しているためです。

サーバーのインストールプロセスが完了したら、VM サービスの詳細設定が行えます。これには、開発者が Windows 実行環境にアクセスできるように Windows イメージをビルドおよび指定したり、代替の Linux マシンイメージを指定したり、スピンアップ状態を常に維持するための事前割り当てインスタンスの数の指定などが含まれます。詳細については、 VM サービスを使った仮想マシンの管理を参照してください。

AWS

セキュリティーグループを作成します

セキュリティグループの作成に必要な情報を入手します。

次のコマンドにより、このセクションで必要な VPC ID (vpcId) と CIDR Block (serviceIpv4Cidr) が返されます。

# Fetch VPC Id
aws eks describe-cluster --name=<cluster-name> --query "cluster.resourcesVpcConfig.vpcId" --region=<region> --output text | xargs

# Fetch CIDR Block
aws eks describe-cluster --name=<cluster-name> --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --region=<region> --output text | xargs

セキュリティーグループを作成します。

以下のコマンドを実行して、VM サービス用のセキュリティーグループを作成します。
```
aws ec2 create-security-group --vpc-id "<VPC_ID>" --description "CircleCI VM Service security group" --group-name "circleci-vm-service-sg"
```
これにより次の手順で使用するグループ ID が出力されます。
```
{
    "GroupId": "<VM_SECURITY_GROUP_ID>"
}
```

セキュリティーグループ Nomad を適用します。

作成したセキュリティーグループと CIDR ブロック値を使ってセキュリティーグループを適用します。これにより VM サービスは作成された EC2 インスタンスとポート 22 で通信できるようになります。

aws ec2 authorize-security-group-ingress --group-id "<VM_SECURITY_GROUP_ID>" --protocol tcp --port 22 --cidr "<SERVICE_IPV4_CIDR>"

Nomad クライアントが使用する各サブネットのサブネット cidr ブロックを見つけ、次のコマンドを使って 2 つのルールを追加します。

# find CIDR block
aws ec2 describe-subnets --subnet-ids=<nomad-subnet-id> --query "Subnets[*].[SubnetId, CidrBlock]" --region=<region> | xargs

# add a security group allowing docker access from nomad clients, to VM instances
aws ec2 authorize-security-group-ingress --group-id "<VM_SECURITY_GROUP_ID>" --protocol tcp --port 2376 --cidr "<SUBNET_IPV4_CIDR>"

# add a security group allowing SSH access from nomad clients, to VM instances
aws ec2 authorize-security-group-ingress --group-id "<VM_SECURITY_GROUP_ID>" --protocol tcp --port 22 --cidr "<SUBNET_IPV4_CIDR>"

セキュリティーグループに SSH接続を適用します (マシン用のパブリック IP を使用している場合)。

VM サービスインスタンスでパブリック IP を使用している場合は、次のコマンドを実行してユーザーがジョブに SSH 接続できるようセキュリティグループのルールを適用します。
```
aws ec2 authorize-security-group-ingress --group-id "<VM_SECURITY_GROUP_ID>" --protocol tcp --port 54782 --cidr "0.0.0.0/0"
```

認証を設定します

クラウドプロバイダーで CircleCI を認証するには、サービスアカウントの IAM ロール (IRSA) または IAM アクセスキーを使用する 2 つの方法があります。 IRSA の使用を推奨します。

以下は IRSA についての AWS のドキュメントの概要です。CircleCI での VM サービスの設定には十分です。

ID プロバイダーを作成します。

EKS クラスタの IAM OIDC ID プロバイダーを作成します。
```
eksctl utils associate-iam-oidc-provider --cluster <CLUSTER_NAME> --approve
```

ARN を取得します。

次のコマンドにより、OIDC プロバイダーの ARN を取得します。今後の手順で必要になります。

aws iam list-open-id-connect-providers | grep $(aws eks describe-cluster --name <CLUSTER_NAME> --query "cluster.identity.oidc.issuer" --output text | awk -F'/' '{print $NF}')

URL を取得します。

OIDC プロバイダーの URL を取得します。今後の手順で必要になります。

aws eks describe-cluster --name <CLUSTER_NAME> --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///"

ロールを作成します。

以下のコマンドと信頼ポリシーのテンプレートを使ってロールを作成します。今後の手順でロール ARN とロール名が必要になります。

aws iam create-role --role-name circleci-vm --assume-role-policy-document file://<TRUST_POLICY_FILE>

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "<OIDC_PROVIDER_ARN>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_PROVIDER_URL>:sub": "system:serviceaccount:<K8S_NAMESPACE>:vm-service"
        }
      }
    }

  ]
}

ポリシーを作成します。

以下のコマンドとテンプレートを使ってポリシーを作成します。セキュリティグループ ID と VPC ID を入力します。

aws iam create-policy --policy-name circleci-vm --policy-document file://<POLICY_FILE>

{
  "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/<SECURITY_GROUP_ID>"
      ]
    },
    {
      "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": "<VPC_ID>"
        }
      }
    }
  ]
}

ポリシーをアタッチします。

ポリシーをロールにアタッチします。
```
aws iam attach-role-policy --role-name <VM_ROLE_NAME> --policy-arn=<VM_POLICY_ARN>
```

VM サービスを設定します。

以下を values.yaml に追加して、VM サービスを設定します。

vm_service:
  providers:
    ec2:
      enabled: true
      region: "<REGION>"
      assignPublicIP: true
      irsaRole: "<IRSA_ROLE_ARN>"
      subnets:
      - "<SUBNET_ID>"
      securityGroupId: "<SECURITY_GROUP_ID>"

ユーザーを作成します。

プログラムでのアクセス権を持つ新規ユーザーを作成します。
```
aws iam create-user --user-name circleci-vm-service
```
vm-service では、オプションで AWS キーの代わりにサービスアカウントのロールの使用もサポートしています。ロールを使用する場合は、以下のステップ 6 のポリシーを使って以下の手順を実行します。完了したら、手順 9 に進みます。手順 9 では、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": "<vpc-id>"
        }
      }
    }
  ]
}

ポリシーをユーザーにアタッチします。

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
```
サーバーを設定します ( 2 つのオプションがあります)。
- オプション 1: キーを values.yaml に追加する VM サービスの設定を values.yaml に追加します。
```
vm_service:
  providers:
    ec2:
      enabled: true
      region: "<REGION>"
      assignPublicIP: true
      accessKey: "<ACCESS-KEY>"
      secretKey: "<SECRET-KEY>"
      subnets:
      - "<SUBNET_ID>"
      securityGroupId: "<SECURITY_GROUP_ID>"
```
- オプション 2: ご自身で Kubernetes シークレットを作成する values.yaml ファイルにアクセスキーとシークレットを提供する代わりに、Kubernetes シークレットをご自身で作成することも可能です。
  kubectl create secret generic vm-service-secret \ --from-literal=ec2AccessKey=<access-key> \ --from-literal=ec2SecretKey=<secret-key>

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 サービス用のファイヤーウォールルールを作成します。
ユーザーを作成します。

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

サービスアカウントで Workload Identity を有効化、または JSON キーファイルを取得します

Workload Identity を使用しているかどうかにより、以下のいずれかのオプションを選択してください。
この手順は、GKE で Workload Identity を使用している場合のみ実行する必要があります。 Workload Identity を有効化する手順は、ステップ 1: 前提条件を参照してください。

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]"
GKE で Workload Identity を使用している場合は、この手順は不要です。

以下のコマンドを実行すると、circleci-server-vm-keyfile という名前のファイルがローカル作業ディレクトリに作成されます。このファイルはサーバーインストールを設定する際に必要になります。

gcloud iam service-accounts keys create circleci-server-vm-keyfile --iam-account <YOUR_SERVICE_ACCOUNT_EMAIL>
サーバーを設定します。

サービスアカウントキーを使って VM サービスのアクセス許可を設定する場合、2 つのオプションがあります。
オプション 1: CircleCI が Kubernetes シークレットを作成する

values.yaml に VM サービスの設定を追加します。

vm_service: enabled: true replicas: 1 providers: gcp: enabled: false project_id: <project-id> network_tags: - circleci-vm - <your-network> zone: <zone> network: <network> subnetwork: <subnetwork> service_account: <service-account-json> # OR workloadIdentity: "" # Leave blank if using JSON keys of service account else service account email address
オプション 2: ご自身で Kubernetes シークレットを作成する

サービスアカウントを values.yaml ファイルに保存する代わりに、ご自身で Kubernetes シークレットを作成することも可能です。

kubectl create secret generic vm-service-secret \ --from-literal=gcp_sa.json=<access-key>

VM サービスの検証

values.yaml ファイルへの変更を適用します。

namespace=<your-namespace>
helm upgrade circleci-server oci://cciserver.azurecr.io/circleci-server -n $namespace --version 4.0.0 -f <path-to-values.yaml>

CircleCI Server の設定とデプロイが完了したら、VM サービスが適切に動作しているか確認する必要がありあます。 CircleCI Server 内で、realitycheck プロジェクトを再実行できます。 VM サービスジョブは完了しているはずです。この時点で、すべてのテストが合格しているはずです。

4. ランナー

概要

CircleCI のランナーには、追加のサーバー設定は不要です。 CircleCI Server はランナーと連携する準備ができています。ただし、ランナーを作成し、CircleCI Server のインストールを認識するようにランナーエージェントを設定する必要があります。ランナーの設定についての詳細は、ランナーに関するドキュメントをご覧ください。

ランナーには組織ごとに１つ名前空間が必要です。 CircleCI Server には複数の組織が存在する場合があります。 CircleCI Server 内に複数の組織が存在する場合、各組織につき１つランナーの名前空間を設定する必要があります。

次のステップ

ステップ 4: ポストインストール