Start Building for Free
CircleCI.comアカデミーブログコミュニティサポート

ステップ 2 - コアサービス

1 week ago4 min read
Server v4.x
サーバー管理者
このページの内容

CircleCI Server v4.x のコアサービスのインストールステップを開始する前に、 前提条件 をすべて満たしていることをご確認ください。

1. 名前空間を作成します

アプリケーションをインストールする名前空間を作成します。

kubectl create ns <namespace>

2. イメージをプルします

CircleCI のイメージレジストリからイメージをプルするための認証情報は、このセットアッププロセスの一部としてお客様に提供されます。 Azure Container Registry (ACR) からのイメージのプルには、 docker-registry Kubernetes のシークレットを使用します。 パブリックインターネットへのアクセスが可能かどうかにより、 2 つのオプションがあります。

3. Helm 値を作成します

CircleCI をインストールする前に、インストール専用の values.yaml ファイルを新たに作成することをお勧めします。 インストールのリファレンスセクション には values.yaml のサンプルファイルが複数含まれており、第一歩としてお勧めです。 以下は、values.yaml に含める必要がある最小限の値です。 更にカスタマイズすることも可能です。利用できるオプションについては提供されている values.yaml を参照してください。

シークレットについては 2 つのオプションがあります。

  • values.yaml ファイルに追加する

  • Kubernetes シークレットとして直接追加する

お好きな方法で柔軟に Kubernetes シークレットを管理していただけます。 どちらのオプションを選んでも、シークレットは CircleCI 内に Kubernetes シークレットとして保存されます。

a. API トークン

このアプリケーションでは API トークンを含む Kubernetes シークレットが必要です。 この API トークンは、API サービスへの API 内部通信を簡易化するために使用されます。 ランダムな文字列を使って安全に保存してください。紛失した場合、復元することはできません。 この Kubernetes シークレットの作成には 2 つのオプションがあり、ご自身で作成することも、CircleCI がお客様のシークレットを作成することも可能です。

このアプリケーションでは、セッション Cookie に署名する際に使用するセッション Cookie キーの Kubernetes シークレットが必要です。 このシークレットは 16 文字にする必要があります。 ランダムな文字列を使って安全に保存してください。紛失した場合、復元することはできません。 この Kubernetes シークレットの作成には 2 つのオプションがあり、ご自身で作成することも、CircleCI がお客様のシークレットを作成することも可能です。

c. 暗号化

このアプリケーションでは、署名と暗号化のキーセットを含む Kubernetes シークレットが必要です。 CircleCI で生成されるアーティファクトの暗号化と署名には、キーセットを使用します。 これらのキーは、 前提条件のステップ で作成されています。 値を紛失した場合、復元できません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

d. Postgres

認証情報

このアプリケーションでは、Postgres 認証情報を含む Kubernetes シークレットが必要です。 これは、Postgres の内部インスタンス (デフォルト) または外部ホストインスタンスのいずれかを使用する場合に当てはまります。 値を紛失した場合、復元できません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

TLS

Postgres は TLS 暗号化トラフィックを使用するように拡張できます。 内部でデプロイした場合、このオプションはデフォルトでは無効になっていますが、values.yaml の postgresql のブロックに以下を追加することにより有効化できます。

postgresql:
  ...
  tls:
    enabled: true
    autoGenerated: true # Generate automatically self-signed TLS certificates

証明書ファイルは、自動作成するのではなく提供することもできます。 その場合、必要な TLC 証明書とキーを含むシークレットを作成します。

kubectl create secret generic postgres-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem

すると、values.yaml の postgresql のブロックに以下の内容が含まれます。

postgresql:
  ...
  tls:
    enabled: true
    certificatesSecret: "postgres-tls-secret" # Name of an existing secret that contains the certificates
    certFilename: "cert.pem" # Certificate filename
    certKeyFilename: "cert.key" # Certificate key filename
    certCAFilename: "ca.pem" # CA Certificate filename

e. MongoDB 認証情報

このアプリケーションでは、Postgres 認証情報を含む Kubernetes シークレットが必要です。 これは、MongoDB の内部インスタンス (デフォルト) または外部ホストインスタンスのいずれかを使用する場合に当てはまります。 値を紛失した場合、復元できません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

f. RabbitMQ の設定と Auth シークレット

RabbitMQ のインストールには 2 つのランダムな英数字の文字列が必要です。 値を紛失した場合、復元できません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

g. Pusher 用の Kubernetes シークレット

このアプリケーションでは Pusher 用の Kubernetes シークレットが必要です。 値を紛失した場合、復元できません。 Kubernetes シークレットの管理方法には、2 つのオプションがあります。

h. Global

このセクションでの値はすべて values.yamlglobal の子です。

CircleCI ドメイン名 (必須)

フロントエンド TLS キーと証明書 を作成した際に指定したドメイン名を入力します。

global:
  ...
  domainName: "<full-domain-name-of-your-install>"

ライセンス

CircleCI からライセンスが提供されます。そのライセンスを values.yaml に追加します。

global:
  ...
  license: '<license>'

レジストリ

イメージをプルするレジストリが既に提供されている、またはお客様がホストしているレジストリにイメージを追加している場合があります。 そのレジストリを values.yaml に追加します。

global:
  ...
  container:
    registry: <registry-domain eg: cciserver.azurecr.io >
    org: <your-org-if-applicable>

i. Static IPs

If you provisioned a Static IP (GCP) or Elastic IPs (AWS) in the prerequisites, you can now add the values under the nginx block.

GCP - Add Static IP

For GCP, add the provisioned IPv4 address under the loadBalancerIp field in the nginx block.

nginx:
  ...
  loadBalancerIp: "<gcp-provisioned-ipv4-address>"

AWS - Add Elastic IPs

For AWS, under nginx annotations, add the service.beta.kubernetes.io/aws-load-balancer-eip-allocations annotation with each of the AllocationId values generated as a comma separated list. Please note, the number of `AllocationId`s must match the number of subnets the load balancer is deployed into (default 3).

nginx:
  ...
  annotations:
    ...
    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: <eip-id-1>,<eip-id-2>,<eip-id-3>

j. TLS

TLS では 4 つのオプションがあります。

k. GitHub との連携

GitHub を CircleCI で設定する場合、デプロイに認証情報を提供する方法が 2 つあります。 GitHub と GitHub Enterprise (GHE) の手順は、次の 2 つのセクションで説明します。

GitHub

下記は GitHub Enterprise ではなく GitHub.com の場合の説明です。 前提条件のステップ で Github OAuth アプリケーションを使って作成したクライアント ID とシークレットを使用します。

GitHub Enterprise

GitHub Enterprise の場合も同様の手順ですが、Enterprise を有効化し、必要なデフォルトのトークンを作成するための追加手順がいくつかあります。

GitHub Enterprise の場合は、 前提条件のステップ で作成した defaultTokenGitHub のセクションに追加します。 ホスト名には、github.exampleorg.com などのプロトコルを含めないでください。

l. オブジェクトストレージ

ストレージプロバイダーに関わらず、 前提条件のステップ で作成したバケット名を含める必要があります。

object_storage:
  bucketName: "<bucket-name>"

S3 互換

s3 のセクションを object_storage の子として追加します。 AWS S3 の場合の endpoint は、 regional endpoint で、https://s3.<region>.amazonaws.com の形式です。 それ以外の場合は、オブジェクトストレージサーバーの API エンドポイントです。

object_storage:
  ...
  s3:
    enabled: true
    endpoint: "<storage-server-or-s3-endpoint>"

object_storage.s3 の配下に、前提条件のステップで作成した accessKeysecretKeyirsaRole のいずれかを指定します。 または何も指定しません。

CircleCI Server は S3 への認証で提供されたロールを使用します。

Google Cloud Storage

object_storage の配下に以下を追加します。

gcs:
    enabled: true

object_storage.gcs の配下に service_accountworkloadIdentity のいずれかを追加します。またはどちらも追加しません。 キーとロールは前提条件のステップで作成しています。

m. プロキシ経由でのインストール

セキュリティ要件に応じて、CircleCI Server をプロキシ経由でインストールすることも可能です。 プロキシ経由で設定することにより、お客様のインストール環境とインターネット全体のアクセスを監視・制御することができます。 プロキシ経由でのインストールの制限事項などの詳細については、 プロキシ経由でのサーバーのインストール を参照してください。

以下のフィールドを values.yaml に設定する必要があります。

  • proxy.enabled"1" に切り替えます。

  • proxy.http.hostproxy.https.host の詳細を関連付けられているポートと共に入力します。 これらの値は同じでも構いませんが、両方とも設定する必要があります。

  • 認証ように proxy.http.auth.enabledproxy.https.auth.enabled"1" に設定する必要があります。 HTTP と HTTPS の両方にそれぞれユーザー名とパスワードを設定する必要があります。

  • no_proxy ホストとサブネットを設定します。 ローカルホスト、GitHub Enterprise (オプション) 、インストールした CircleCI のホスト名 ( 既知の制限事項 で詳細を参照) および vm-service と Nomad の両方の CIDR を含む必要があります。

proxy:
  enabled: "1"
  http:
    host: "<proxy.example.internal>"
    port: "3128"
    auth:
      enabled: "1"
      username: "<proxy-user>"
      password: "<proxy-password>"
  https:
    host: "<proxy.example.internal>"
    port: "3128"
    auth:
      enabled: "1"
      username: "<proxy-user>"
      password: "<proxy-password>"
  no_proxy:
    - localhost
    - 127.0.0.1
    - "<github.example.internal>"
    - "<circleci.example.internal>"
    - "<nomad-subnet-cidr>"
    - "<vm-service-cidr>"
    - "<vpc-or-subnet-cidr>"   # VPC or subnets to exclude from the proxy (optional)

4. デプロイ

上記項目の設定が完了したら、いよいよ CircleCI のコアサービスのデプロイです。

USERNAME=<provided-username>
PASSWORD=<token>
namespace=<your-namespace>
helm registry login cciserver.azurecr.io/circleci-server -u $USERNAME -p $PASSWORD
helm install circleci-server oci://cciserver.azurecr.io/circleci-server -n $namespace --version 4.0.0 -f <path-to-values.yaml>

5. DNS エントリーを作成します

NGINX ロードバランサー の DNS エントリを作成します (例: circleci.your.domain.comapp.circleci.your.domain.com )。 この DNS エントリは、前提条件のステップで TLS 証明書とGitHub OAuth アプリケーションを作成する際に使用した DNS 名と一致している必要があります。 すべてのトラフィックは、この DNS レコードを介してルーティングされます。

IP アドレスが必要です。AWS を使用している場合は、NGINX ロードバランサーの DNS 名が必要です。 以下のコマンドで情報を入手します。

kubectl get service circleci-proxy

新しい DNS レコードを追加する方法について詳しくは、以下のドキュメントを参照してください。

6. バリデーション

これで、CircleCI Server に移動し、アプリケーションに正常にログインできるはずです。

次は、サービスのビルドを行います。 すべてのサービスが立ち上がるまで時間がかかることがあります。 次のコマンドを実行して、定期的に確認します (ステータスが runningfrontend ポッドを探します。ready は 1/1 と表示されいてる必要があります)。

kubectl get pods -n <YOUR_CIRCLECI_NAMESPACE>

ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。

サポートが必要ですか

CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。

または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。