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

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

4 months ago4 min read
このページの内容

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 つのオプションがあります。

ii. 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.yaml の global の子です。

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. 静的 IP アドレス

前提条件のセクションで静的 IP アドレス (GCP) または Elastic IP アドレス (AWS) をプロビジョニングした場合、ここで nginx ブロックの下に値を追加します。

GCP: 静的 IP アドレスを追加

GCP の場合は、プロビジョニングした IPv4 アドレスを nginx ブロックの loadBalancerIp フィールドの下に追加します。

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

AWS: Elastoc IP アドレスを追加

AWS の場合は、service.beta.kubernetes.io/aws-load-balancer-eip-allocations の注釈とコンマ区切りのリストとして生成された AllocationId の各値を nginx の注釈の下に追加します。 AllocationId の数はロードバランサーがデプロイされるサブネットの数と一致している必要があるのでご注意ください (デフォルト設定は 3)。

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

j. TLS

TLS では以下のオプションがあります。

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 の場合は、 前提条件のステップ で作成した defaultToken を GitHub のセクションに追加します。 ホスト名には、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 の配下に、前提条件のステップで作成した accessKey 、 secretKey 、irsaRole のいずれかを指定します。 または何も指定しません。

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

Google Cloud Storage

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

gcs:
    enabled: true

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

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

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

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

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

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

  • 認証用に proxy.http.auth.enabled と proxy.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.com と app.circleci.your.domain.com )。 この DNS エントリは、前提条件のステップで TLS 証明書とGitHub OAuth アプリケーションを作成する際に使用した DNS 名と一致している必要があります。 すべてのトラフィックは、この DNS レコードを介してルーティングされます。

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

kubectl get service circleci-proxy

6. バリデーション

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

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

kubectl get pods -n <YOUR_CIRCLECI_NAMESPACE>

次のステップ

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

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

サポートが必要ですか

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

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

Creative Commons License

CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.