外部サービスの設定

Server v4.x

サーバー管理者

このページの内容

PostgreSQL

このページでは、CircleCI Server 4.x を新規にインストールする場合、および既存の CircleCI Server 4.x から内部の Postgres および MongoDB のデータを外部データストアに移行する場合に使用する以下の外部サービスの設定方法について説明します。

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 から外部ソースへの移行

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

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.

外部の PostgreSQL インスタンスを CircleCI Server に接続する

外部の PostgreSQL インスタンスをセットアップしたら、CircleCI Server インスタンスがアクセスできるように、values.yaml ファイルに以下を追加します。

postgresql:
  internal: false
  postgresqlHost: <domain> # The domain or IP address of your PostgreSQL instance
  postgresqlPort: <port> # The port of your PostgreSQL instance

postgresql.internal: false は、内部にデプロイ済みの Postgres インスタンスを削除します。

この変更は、helm install/upgrade を実行したときに有効になります。外部化した Postgres インスタンスへの移行を完了している場合、helm upgrade を実行すると、スケールダウンされたポッドが values.yaml で定義されたレプリカ番号にスケールバックされます。

PostgreSQL のバックアップ

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

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

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

MongoDB

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

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

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

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 Server に接続する

外部の MongoDB インスタンスを設定したら、values.yaml ファイルに以下を追加して、CircleCI Server インスタンスに接続します。

mongodb:
  internal: false
  hosts: <hostname:port> # this can be a comma-separated list of multiple hosts for sharded instances
  ssl: <ssl-enabled>
  # If using an SSL connection with custom CA or self-signed certs, set this
  # to true
  tlsInsecure: false
  # Any other options you'd like to append to the MongoDB connection string.
  # Format as query string (key=value pairs, separated by &, special characters
  # need to be URL encoded)
  options: <additional-options>
  auth:
    database: <authentication-source-database
    mechanism: SCRAM-SHA-1

この変更は、helm install/upgrade を実行したときに有効になります。外部化した MongoDB インスタンスへの移行を完了している場合、helm upgrade を実行すると、スケールダウンされたポッドが values.yaml で定義されたレプリカ番号にスケールバックされます。

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

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

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

サポートが必要ですか

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

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

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