CircleCI Server v3.x インストールステップ 3

7 months ago4 min read

Server v3.x

サーバー管理者

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

Flow chart showing the installation flow for server 3.x with phase 3 highlighted

Figure 1. インストール手順のフローチャートステップ 3

以下のセクションでは、< > の中に表示される認証情報の項目にご自身の情報を入力してください。

ステップ 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) の３番目の 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を参照してください。

Table 1. 環境変数
名前	値
CIRCLE_HOSTNAME	<YOUR_CIRCLECI_INSTALLATION_URL>
CIRCLE_TOKEN	<YOUR_CIRCLECI_API_TOKEN>

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

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"

自動モードを使用した場合は、こちらの表を参照して、リージョンに基づいて Nomad クライアントの CIDR を見つけることができます。

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 のインストールを認識するようにランナーエージェントを設定する必要があります。ランナー設定の詳細については、ランナーのドキュメントを参照してください。

ランナーには組織ごとに１つ名前空間が必要です。 CircleCI Server には複数の組織が存在する場合があります。 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.

CircleCI Server v3.x インストール ステップ 3

このページの内容