CircleCI Server v3.x 内部データベースのボリューム拡張
概要
MongoDB および Postgres の永続ボリュームの拡張は、Server v3.2.0 以降で可能です。
CircleCI データベース（MongoDB または Postgres）を外部からプロビジョニングするのではなく、クラスタ内にデプロイすることを選択した場合、あらかじめ用意したデータベース用ストレージ容量では足りなくなる場合があります。 Kubernetes クラスタの内部データベースでは、永続的なストレージとして 永続ボリューム を使用しています。 ボリュームのサイズは、PVC（永続ボリューム要求）によって決定されます。 この PVC は、クラスタ内の Node に使用できる容量に基づいてストレージスペースを要求します。
ここでは、内部でデプロイしたデータベース用のスペースを増やすために PVC を増やす手順を説明します。 この操作には、データベースポッドを再起動する必要がない限り、ダウンタイムは生じません。
| 永続ボリュームを拡張しても、Node に接続されているストレージのサイズには影響しません。 Node ストレージの拡張は、ご使用のクラウドプロバイダーの制限範囲内で可能です。 クラスタの Node に接続されたストレージを拡張する方法の詳細については、ご使用のクラウドプロバイダーのドキュメントを参照してください。 |
永続ボリューム要求のサイズ変更
ここでは Postgres と MongoDB の 永続ボリューム要求のサイズを変更する方法を説明します。 この操作の前後で、要求のサイズやデータベースに利用できるディスク容量を確認します。
ステップ 0: 現在のボリュームサイズの確認
デフォルトでは、内部のデータベースが使用する永続ボリューム要求の容量は 8Gi です。 ただし、この初期値は最初のデプロイ時に KOTS 管理者コンソールから設定できます。 kubectl get pvc <pvc-name> コマンドにより、永続ボリューム要求のサイズを確認することができます。
Postgres の場合:
circleci-user ~ $ kubectl get pvc data-postgresql-0
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-postgresql-0 Bound pvc-c2a2d97b-2b7d-47d3-ac77-d07c76c995a3 8Gi RWO gp2 1dMongoDB の場合:
circleci-user ~ $ kubectl get pvc datadir-mongodb-0
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
datadir-mongodb-0 Bound pvc-58a2274c-31c0-487a-b329-0062426b5535 8Gi RWO gp2 1dデータベースのデータディレクトリのサイズを確認することで、この容量が確保されているかも確認できます。
Postgres の場合、ディレクトリは /bitnami/postgresql です。 以下のコマンドでサイズの確認ができます。
circleci-user ~ $ kubectl exec postgresql-0 -- df -h /bitnami/postgresql
Filesystem Size Used Avail Use% Mounted on
/dev/nvme4n1 7.8G 404M 7.4G 3% /bitnami/postgresqlMongoDB の場合、ディレクトリは /bitnami/mongodb です。
circleci-user ~ $ kubectl exec mongodb-0 -- df -h /bitnami/mongodb
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1 7.8G 441M 7.4G 3% /bitnami/mongodb上記の例では、容量は 8Gi のままです。 次のステップで、これを 10 Gi に増やす方法を紹介します。
ステップ 1: ボリュームの拡張が可能かどうかを確認する
まず、クラスタでボリューム拡張が許可されていることを確認します。
circleci-user ~ $ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 1dご覧の通り、デフォルトのストレージクラスではボリュームの拡張ができません。 しかし、 kubectl patch コマンドでこれを変更することができます。
circleci-user ~ $ kubectl patch sc gp2 -p '{"allowVolumeExpansion": true}'
storageclass.storage.k8s.io/gp2 patched
circleci-user ~ $ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 1dここからは、ボリュームを増やしていきましょう。
ステップ 2: データベースのステートフルセットを削除する
このステップでは、データベースポッドを制御するステートフルセットを削除します。 以下のコマンドは、ポッドを削除することなく、参照されるデータベースのステートフルセットを削除します。 ポッド自体を削除してしまうとダウンタイムが発生してしまうので、お勧めしません。 次のステップでは、ステートフルセットを再びデプロイします。 ボリュームを拡張するデータベースによって、どちらか一方または両方のステートフルセットを削除します。 ここでは、 --cascade=false フラグが最も重要です。
Postgres の場合:
kubectl delete sts postgresql --cascade=falseMongoDB の場合:
kubectl delete sts mongodb --cascade=falseステップ 3: データベースの PVC サイズを更新する
ステートフルセットが削除されたので、永続ボリューム要求のサイズを 10Gi に増やすことができます。
Postgres の場合:
kubectl patch pvc data-postgresql-0 -p '{"spec": {"resources": {"requests": {"storage": "10Gi"}}}}'MongoDB の場合:
kubectl patch pvc datadir-mongodb-0 -p '{"spec": {"resources": {"requests": {"storage": "10Gi"}}}}'ステップ 4: KOTS 管理者コンソールを新しい PVC サイズに更新する
次に、KOTS 管理者コンソールにアクセスして変更内容を永続化する必要があります。 設定セクションでは、以下のように PVC サイズの値を 10Gi に更新します。
変更内容を保存し、デプロイします。 これにより、先ほど削除したステートフルセットが再び作成されますが、次のリリースまで継続される新しい PVC サイズに変わっています。
ステップ 5: 新しいボリュームサイズを検証する
デプロイ後にデータベースに割り当てられたデータディレクトリのサイズを検証することができます。
Postgres の場合、ディレクトリは /bitnami/postgresql です。
circleci-user ~ $ kubectl exec postgresql-0 -- df -h /bitnami/postgresql
Filesystem Size Used Avail Use% Mounted on
/dev/nvme4n1 9.8G 404M 9.4G 5% /bitnami/postgresqlMongoDB の場合、ディレクトリは /bitnami/mongodb です。
circleci-user ~ $ kubectl exec mongodb-0 -- df -h /bitnami/mongodb
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1 9.8G 441M 9.3G 5% /bitnami/mongodbご覧のように、ディレクトリのサイズが拡張されています。
これらの手順を完了する際、新しいポッドでサイズ変更されたボリュームが期待通りに表示された場合は、下記の kubectl describe コマンドで確認することをお勧めします。 サイズ変更に失敗する場合がありますが、kubectl describe からの出力でイベントを表示する方法しかありません。
Postgres の場合:
kubectl describe pvc data-postgresql-0MongoDB の場合:
kubectl describe pvc datadir-mongodb-0成功すると、以下の例のように出力されます。
Events:
Type Reason Age From Message
Normal FileSystemResizeSuccessful 19m kubelet MountVolume.NodeExpandVolume succeeded for volume "pvc-b3382dd7-3ecc-45b0-aeff-45edc31f48aa"失敗すると、以下の例のように出力されます。
Warning VolumeResizeFailed 58m volume_expand error expanding volume "circleci-server/datadir-mongodb-0" of plugin "kubernetes.io/aws-ebs": AWS modifyVolume failed for vol-08d0861715c313887 with VolumeModificationRateExceeded: You've reached the maximum modification rate per volume limit. Wait at least 6 hours between modifications per EBS volume.
status code: 400, request id: 3bd43d1e-0420-4807-9c33-df26a4ca3f23
Normal FileSystemResizeSuccessful 55m (x2 over 81m) kubelet MountVolume.NodeExpandVolume succeeded for volume "pvc-29456ce2-c7ff-492b-add4-fcf11872589f"トラブルシューティング
これらのステップを実行しても、データディレクトリに割り当てられたディスクサイズが拡張しない場合は、データベースポッドを再起動する必要があります。 この場合、データベースの再起動に伴い 1～5分程度のダウンタイムが発生します。 以下のコマンドでデータベースを再起動することができます。
Postgres の場合:
kubectl rollout restart sts postgresqlMongoDB の場合:
kubectl rollout restart sts mongodbドキュメントの改善にご協力ください
このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。
- このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
- ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
- CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。 フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。
サポートが必要ですか
CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。
または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.