CircleCI Server v3.x 外部サービスの設定

Server v3.x

サーバー管理者

このページの内容

PostgreSQL

このドキュメントでは、CircleCI Server 3.x で使用する以下の外部サービスの設定方法について説明します。このガイドで説明している設定は、KOTS の管理者コンソールで確認できます。名前空間を変更して `kubectl kots admin-console -n <YOUR_CIRCLECI_NAMESPACE>`を実行し、KOTS 管理者コンソールにアクセスします。

PostgreSQL

PostgreSQL のベストプラクティス

ご自身の PostgreSQLインスタンスを使用する場合は、バージョン12.1 以上である必要があります。

プライマリで障害が発生した場合の復旧や、バックアップのために、PostgreSQL レプリカは 2 つ以上実行することをお勧めします。推奨される PostgreSQL マシンの仕様は以下のとおりです。

1 日のアクティブユーザー数	PostgreSQL レプリカ数	CPU	RAM	ディスク	NIC 速度
50 名未満	2	8 コア	16 GB	100 GB	1 Gbps
50 ～ 250 名	2	8 コア	16 GB	200 GB	1 Gbps
250 ～ 1000 名	3	8 コア	32 GB	500 GB	10 Gbps
1000 ～ 5000 名	3	8 コア	32 GB	1 TB	10 Gbps
5000名以上	3	8 コア	32 GB	1 TB	10 Gbps

PostgreSQL のバックアップ

PostgreSQL から、PostgreSQL 12 システムのバックアップと復元に関する公式ドキュメント ( こちら ) が提供されています。

CircleCI では、以下を行っていただくよう強くお勧めしています。

毎日バックアップを行う
バックアップを少なくとも 30 日間保持する
データベースには機密情報が含まれている場合があるので、バックアップには暗号化ストレージを使用する
CircleCI Server のアップグレードを行う前には毎回バックアップを行う

内部 PostgreSQL から外部ソースへの移行

If you are doing a fresh install of CircleCI server, then you can skip this section and head to 外部の Postgres インスタンスを CircleCI サーバーに接続する

When a CircleCI server instance is deployed, Postgres is deployed internally by default via its helm chart. However, as an operator, you may wish to externalize this database to have better control over scalability and availability. Once you have configured your external Postgres, you may use the guide below to migrate your Postgres data to your external database.

This process requires downtime.

1. Disable the application

Disable the CircleCI server application by scaling down the application layer pods. No Data is lost in this process, but the application will be unreachable.

Scale down your application layer pods:

namespace=<your-server-namespace>
kubectl -n "$namespace" scale deploy -l "layer=application" --replicas="0"

Running kubectl -n "$namespace" get pods will show most of your pods scaling to down, leaving your database pods running including Postgres.

2. Validate access to your external PostgreSQL from within the cluster (optional)

Confirm that pods within your CircleCI Server cluster can access your external Postgres. You can do this from within your internal Postgres.

PG_POD=$(kubectl -n "$namespace" get pods | grep postgresql | tail -1 | awk '{print $1}')
kubectl exec -it -n "$namespace" "$PG_POD" -- bash

While still connected to the pod run:

psql -h <your-external-postgres-host> -U postgres -p <your-external-postgres-port>

You should be able to connect to your external Postgres at this point. If not, resolve any issues before proceeding.

You may use helm upgrade … to restore your CircleCI server instance to a running state.

3. Generate export of your internal PostgreSQL

Retrieve your internal Postgres credentials:
```
PG_PASSWORD=$(kubectl -n "$namespace" get secrets postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
```
The username for your internal Postgres is postgres. The password is randomly generated unless directly set at installation.
Connect to your Postgres pod and perform a Postgres dump:
```
kubectl -n "$namespace" exec -it "$PG_POD" -- bash -c "export PGPASSWORD='$PG_PASSWORD' && pg_dumpall -U postgres -c" > circle.sql
```
This backup is created in the filesystem used by the Postgres pod. If you wish to store it locally, you may use kubectl cp -n "$namespace" "$PG_POD":circle.sql /local/dir/circle.sql
Clean up the Postgres Dump. Your internally deployed Postgres uses the username postgres. However, during the restore, the Postgres dump will drop all resources before trying to create new ones, including the postgres user. Access the Postgres pod where the dump is stored and run the following commands on the Postgres dump file to remove the lines that would delete the Postgres user.
```
PG_POD=$(kubectl -n "$namespace" get pods | grep postgresql | tail -1 | awk '{print $1}')
kubectl exec -it -n "$namespace" "$PG_POD" -- bash

sed -i".bak" '/DROP ROLE postgres/d' circle.sql
sed -i".bak" '/CREATE ROLE postgres/d' circle.sql
sed -i".bak" '/ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD/d' circle.sql
```

4. Restore your data in your external PostgreSQL

While still connected to your the internally deployed Postgres, restore the dumped data to your external Postgres:

psql -h <your-external-postgres-host> -U postgres -p <your-external-postgres-port> < circle.sql

Now your external Postgres will have your CircleCI server data. In the next section you will update CircleCI server to point to your external Postgres.

外部の Postgres インスタンスを CircleCI サーバーに接続する

Screenshot of KOTS admin console config showing settings for using an external PostgreSQL instance

外部 PostgreSQL インスタンスの使用を選択した場合は、以下のフィールドに入力してください。

PostgreSQL Service Domain (PostgreSQL サービスドメイン)(必須): PostgreSQL インスタンスのドメインまたは IP アドレス
PostgreSQL Service Port (PostgreSQL サービスポート)] (必須): PostgreSQL インスタンスのポート
PostgreSQL Service Username (PostgreSQL サービスユーザーネーム)(必須): PostgreSQL インスタンスへのアクセス権を持つユーザー
PostgreSQL Service Password (PostgreSQL サービスパスワード) (必須): PostgreSQL インスタンスへのアクセスに使用されるユーザーアカウントのパスワード

KOTS admin で変更を適用すると、CircleCI サーバーインスタンスが復元され、以前と同じようにPodが実行されます。

MongoDB

ご自身の Mongo DB インスタンスを使用する場合は、バージョン 3.6 以上である必要があります。

内部 MongoDB から外部化ソースへの移行

If you are doing a fresh install of CircleCI Server, then you can skip this section and head to 外部の MongoDB インスタンスを CircleCI サーバーに接続する

When a CircleCI server instance deployed, MongoDB is deployed internally by default via its helm chart. However, as an operator, you may wish to externalize this database to have better control over scalability and availability. Once you have configured your external MongoDB, you may use the guide below to migrate your Mongo data to your external database.

This process requires downtime.

1. Disable the application

Disable the CircleCI server application by scaling down the application layer pods. No Data is lost in this process, but the application will be unreachable.

Scale down your application layer pods:

namespace=<your-server-namespace>
kubectl -n "$namespace" scale deploy -l "layer=application" --replicas="0"

Running kubectl -n "$namespace" get pods will show most of your pods scaling to down, leaving your database pods running, including Mongo.

2. Validate access to your external MongoDB from within the cluster (optional)

Confirm that pods within your CircleCI server cluster can access your external MongoDB. You can do this from within your internal MongoDB pod:
```
MONGO_POD="mongodb-0"
kubectl exec -it -n "$namespace" "$MONGO_POD" -- bash
```

While still connected to the pod run the following:

mongo --username <username> --password --authenticationDatabase admin --host <external-mongodb-host> --port <external-mongodb-port>

You should be able to connect to your external MongoDB at this point. If not, resolve any issues before proceeding.

You may use helm upgrade … to restore your CircleCI server instance to a running state.

3. Generate export of your internal MongoDB

Retrieve your internal MongoDB credentials:

MONGO_POD="mongodb-0"
MONGODB_USERNAME="root"
MONGODB_PASSWORD=$(kubectl -n "$namespace" get secrets mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)

Create a backup directory in your MongoDB pod:

kubectl -n "$namespace" exec "$MONGO_POD" -- mkdir -p /tmp/backups/

Generate a MongoDB database dump to the backup directory you just created:

kubectl -n "$namespace" exec -it "$MONGO_POD" -- bash -c "mongodump -u '$MONGODB_USERNAME' -p '$MONGODB_PASSWORD' --authenticationDatabase admin --db=circle_ghe --out=/tmp/backups/"

4. Restore your data in your external MongoDB

Use the generated MongoDB backup to restore the data to your external MongoDB:

kubectl -n "$namespace" exec "$MONGO_POD" -- mongorestore --drop -u "$MONGODB_USERNAME" -p "$MONGODB_PASSWORD" --authenticationDatabase admin /tmp/backups/circle_ghe;

Now your external MongoDB will have your CircleCI server data. In the next section you will update CircleCI server to point to your external MongoDB.

外部の MongoDB インスタンスを CircleCI サーバーに接続する

Screenshot of KOTS admin console config showing settings for using an external MongoDB instance

外部 MongoDB インスタンスの使用を選択した場合は、以下のフィールドに入力してください。

MongoDB connection host(s) or Ip(s) (MongoDB 接続ホストまたは IP (必須): MongoDB インスタンスのホスト名または IP。コロンによるポートの指定と、シャードインスタンスに対する複数のホストの両方がサポートされています。
Use SSL for connection to MongoDB (MongoDB への接続に SSL を使用)](必須): 外部 MongoDB インスタンスへの接続に SSL を使用するかどうかを指定します。
Allow insecure TLS connections (セキュアでない TLS 接続を許可)](必須): 自己署名証明書またはカスタム CA により署名された証明書を使用している場合、この設定を有効にする必要があります。ただし、この設定はセキュアではありません。可能な限り、有効な CA によって署名された TLS 証明書を使用することをお勧めします。
MongoDB user (MongoDB ユーザー)] (必須): 使用するアカウントのユーザー名。このアカウントには dbAdmin ロールが指定されている必要があります。
MongoDB password (MongoDB パスワード)] (必須): 使用するアカウントのパスワード。
MongoDB authentication source database (MongoDB 認証元データベース) (必須)]: アカウント情報を保持するデータベース (通常は管理)。
MongoDB authentication mechanism (MongoDB 認証メカニズム)] (必須): 使用する認証メカニズム (通常は SCRAM-SHA-1)。
Additional connection options (追加の接続オプション)](オプション): 使用する他の接続オプションを指定します。これはクエリ文字列の形式で指定する必要があります (key=value のペア、& で区切る。特殊文字は URL エンコードが必要です。) 利用可能なオプションについては、 MongoDB のドキュメントを参照してください。

KOTS adminで変更を適用すると、CircleCI Serverインスタンスが復元され、以前と同じように Pod が実行されます。

Vault

Figure 1. 外部 Vault

外部 Vault インスタンスの使用を選択した場合は、以下のフィールドに入力してください。

URL: VaultサービスのURL
Transit Path: Vault シークレットの Transit パス
Token: Vault のアクセストークン

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

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

このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。

サポートが必要ですか

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

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

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