Auto DevOpsのPostgreSQLのアップグレード
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
POSTGRES_ENABLEDがtrueの場合、Auto DevOpsはアプリケーション用のインクラスタをプロビジョニングします。
PostgreSQLのプロビジョニングに使用されるチャートのバージョン:
- 0.7.1から8.2.1に設定できます。
GitLabでは、データベースを新しいPostgreSQLチャートに移行することを推奨しています。
このガイドでは、PostgreSQLデータベースを移行する方法について説明します。これには次の手順が含まれます。:
- データのデータベースダンプを取得します。
- 新しいバージョン8.2.1のチャートを使用して新しいPostgreSQLデータベースをインストールし、古いPostgreSQLのインストールを削除します。
- 新しいPostgreSQLにデータベースダンプを復元します。
前提要件
kubectlをインストールします。kubectlを使用してKubernetesクラスタにアクセスできることを確認してください。これは、Kubernetesプロバイダーによって異なります。- ダウンタイムに備えてください。以下の手順では、データベースダンプの作成後にインクラスタデータベースが変更されないように、アプリケーションをオフラインにします。
- この設定は既存のチャンネル1データベースを削除するため、
POSTGRES_ENABLEDをfalseに設定していないことを確認してください。詳細については、既存のPostgreSQLデータベースが検出されましたを参照してください。
Auto DevOpsをステージングするように設定している場合は、最初にステージングでバックアップと復元の手順を試すか、レビューアプリで試してみてください。
アプリケーションをオフラインにする
必要に応じて、データベースダンプの作成後にデータベースが変更されないように、アプリケーションをオフラインにします。
環境のKubernetesネームスペースを取得します。通常は
<project-name>-<project-id>-<environment>のようになります。この例では、ネームスペースはminimal-ruby-app-4349298-productionと呼ばれています。$ kubectl get ns NAME STATUS AGE minimal-ruby-app-4349298-production Active 7d14h使いやすくするために、ネームスペース名をエクスポートします。:
export APP_NAMESPACE=minimal-ruby-app-4349298-production次のコマンドを使用して、アプリケーションのデプロイ名を取得します。この例では、デプロイメント名は
productionです。$ kubectl get deployment --namespace "$APP_NAMESPACE" NAME READY UP-TO-DATE AVAILABLE AGE production 2/2 2 2 7d21h production-postgres 1/1 1 1 7d21hデータベースが変更されないようにするには、次のコマンドを使用して、デプロイメントのレプリカを0に設定します。前の手順 (
deployments/<DEPLOYMENT_NAME>) からデプロイ名を使用します。$ kubectl scale --replicas=0 deployments/production --namespace "$APP_NAMESPACE" deployment.extensions/production scaledもしもワーカーがある場合は、レプリカをゼロに設定する必要があります。
バックアップ
PostgreSQLのサービス名を取得します。サービスの名前は、
-postgresで終わる必要があります。この例では、サービス名はproduction-postgresです。$ kubectl get svc --namespace "$APP_NAMESPACE" NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE production-auto-deploy ClusterIP 10.30.13.90 <none> 5000/TCP 7d14h production-postgres ClusterIP 10.30.4.57 <none> 5432/TCP 7d14h次のコマンドを使用して、PostgreSQLのポッド名を取得します。この例では、ポッド名は
production-postgres-5db86568d7-qxlxvです。$ kubectl get pod --namespace "$APP_NAMESPACE" -l app=production-postgres NAME READY STATUS RESTARTS AGE production-postgres-5db86568d7-qxlxv 1/1 Running 0 7d14h次のコマンドを使用してポッドに接続します:
kubectl exec -it production-postgres-5db86568d7-qxlxv --namespace "$APP_NAMESPACE" -- bash接続したら、次のコマンドでダンプファイルを作成します。
SERVICE_NAMEは前の手順で取得したサービス名です。USERNAMEは、PostgreSQL用に構成したユーザー名です。デフォルトはuserです。DATABASE_NAMEは通常、環境名です。データベースパスワードの入力を求められた場合、デフォルトは
testing-passwordです。## Format is: # pg_dump -h SERVICE_NAME -U USERNAME DATABASE_NAME > /tmp/backup.sql pg_dump -h production-postgres -U user production > /tmp/backup.sql
バックアップダンプが完了したら、Kubernetes execプロセスをControl-Dまたは
exitで終了します。次のコマンドを使用して、ダンプファイルをダウンロードします。:
kubectl cp --namespace "$APP_NAMESPACE" production-postgres-5db86568d7-qxlxv:/tmp/backup.sql backup.sql
永続ボリュームを保持する
デフォルトでは、PostgreSQLの基盤となるデータを格納するために使用される永続ボリュームは、ボリュームを使用するポッドとポッドクレームが削除されると、Deleteとしてマークされます。
これは、新しい8.2.1 PostgreSQLを選択すると、古い0.7.1 PostgreSQLが削除され、永続ボリュームも削除されるため、重要です。
これは、次のコマンドを使用して確認できます。:
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 8Gi RWO Delete Bound minimal-ruby-app-4349298-staging/staging-postgres standard 7d22h
pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 8Gi RWO Delete Bound minimal-ruby-app-4349298-production/production-postgres standard 7d22h古い0.7.1 PostgreSQLが削除されても、永続ボリュームを保持するには、保持ポリシーをRetainに変更します。この例では、クレーム名を見て永続ボリューム名を見つけます。minimal-ruby-app-4349298アプリケーションのステージングと本番環境のボリュームを保持することに関心があるため、ここでのボリューム名はpvc-0da80c08-5239-11ea-9c8d-42010a8e0096とpvc-9085e3d3-5239-11ea-9c8d-42010a8e0096です:
$ kubectl patch pv pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
persistentvolume/pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 patched
$ kubectl patch pv pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
persistentvolume/pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 patched
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 8Gi RWO Retain Bound minimal-ruby-app-4349298-staging/staging-postgres standard 7d22h
pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 8Gi RWO Retain Bound minimal-ruby-app-4349298-production/production-postgres standard 7d22h新しいPostgreSQLをインストールする
新しいバージョンのPostgreSQLを使用すると、古い0.7.1 PostgreSQLが削除されます。基になるデータが削除されないようにするには、永続ボリュームを保持することを選択できます。
AUTO_DEVOPS_POSTGRES_CHANNEL、AUTO_DEVOPS_POSTGRES_DELETE_V1、およびPOSTGRES_VERSIONの変数のスコープを特定の環境（stagingなど）に設定することもできます。
AUTO_DEVOPS_POSTGRES_CHANNELを2に設定します。これにより、新しい8.2.1ベースのPostgreSQLの使用が選択され、古い0.7.1ベースのPostgreSQLが削除されます。AUTO_DEVOPS_POSTGRES_DELETE_V1を空でない値に設定します。このフラグは、データベースの誤った削除を防ぐための安全策です。POSTGRES_VERSIONが設定されている場合は、9.6.16以降に設定されていることを確認してください。これは、Auto DevOpsでサポートされている最小PostgreSQLのバージョンです。利用可能なタグの一覧も参照してください。PRODUCTION_REPLICASを0に設定します。他の環境では、環境スコープでREPLICASを使用します。DB_INITIALIZEまたはDB_MIGRATEの変数を設定した場合は、変数を削除するか、変数の名前を一時的にXDB_INITIALIZEまたはXDB_MIGRATEに変更して、それらを効果的に無効にします。- ブランチの新しいCIパイプラインを実行します。この場合、
mainの新しいCIパイプラインを実行します。 - パイプラインが成功すると、アプリケーションは新しいPostgreSQLがインストールされた状態でアップグレードされます。この時点ではレプリカは存在しないため、アプリケーションにトラフィックは提供されません (新しいデータが入力されないようにするため)。
復元する
新しいPostgreSQLのポッド名を取得します。この例では、ポッド名は
production-postgresql-0です:$ kubectl get pod --namespace "$APP_NAMESPACE" -l app=postgresql NAME READY STATUS RESTARTS AGE production-postgresql-0 1/1 Running 0 19mバックアップ手順からポッドにダンプファイルをコピーします。:
kubectl cp --namespace "$APP_NAMESPACE" backup.sql production-postgresql-0:/tmp/backup.sqlポッドに接続します:
kubectl exec -it production-postgresql-0 --namespace "$APP_NAMESPACE" -- bashポッドに接続したら、次のコマンドを実行してデータベースを復元します。
- データベースパスワードの入力を求められた場合、デフォルトは
testing-passwordです。 USERNAMEは、PostgreSQL用に構成したユーザー名です。デフォルトはuserです。DATABASE_NAMEは通常、環境名です。
## Format is: # psql -U USERNAME -d DATABASE_NAME < /tmp/backup.sql psql -U user -d production < /tmp/backup.sql- データベースパスワードの入力を求められた場合、デフォルトは
復元が完了したら、データが正しく復元されたことを確認できます。
psqlを使用して、データのスポットチェックを実行できます。
アプリケーションを元に戻す
データベースが復元されたことに満足したら、次の手順を実行してアプリケーションを元に戻します:
- 以前に削除または無効にした場合は、
DB_INITIALIZEおよびDB_MIGRATE変数を復元します。 PRODUCTION_REPLICASまたはREPLICAS変数を元の値に復元します。- ブランチの新しいCIパイプラインを実行します。この場合、
mainの新しいCIパイプラインを実行します。パイプラインが成功すると、アプリケーションは以前と同様にトラフィックを処理するようになります。