付録A-バックアップ用の共通オブジェクトストア ============================================ :ref:`付録A-バックアップ用の共通オブジェクトストア <付録A-バックアップ用の共通オブジェクトストア>` ファイルは、 Barman Cloudインフラストラクチャでサポートされている任意のサービスに保存できます。つまり - :ref:`Amazon S3 <#aws-s3>` - :ref:`Microsoft Azure Blob Storage <ストレージ>` - :ref:`Google Cloud Storage ` サポートされているサービスの互換性のある実装を使用することもできます。 必要なセットアップは、選択したストレージプロバイダーによって異なり、以降のセクションで説明します。 AWS S3 ------ `AWS Simple Storage Service (S3) `_ は、Amazonが提供する非常に人気のオブジェクトストレージサービスです。 CloudNativePGバックアップに関する限り、2つの方法でバックアップをS3バケットに保存する権限を定義できます。 - CloudNativePGがEKSで実行されている場合。 `IRSA authentication method `_ を使用することができます - または、 ``ACCESS_KEY_ID`` および\ ``ACCESS_SECRET_KEY`` 資格情報を使用できます AWSアクセスキー ^^^^^^^^^^^^^^^ 環境に関する次の情報が必要です。 - ``ACCESS_KEY_ID`` S3にファイルをアップロードするために使用されるアクセスキーのID - ``ACCESS_SECRET_KEY`` 上記のアクセスキーのシークレット部分 - ``ACCESS_SESSION_TOKEN`` オプションのセッショントークン、必要な場合 使用されるアクセスキーには、バケットにファイルをアップロードする権限が必要です。そのため、資格情報を使用してKubernetesシークレットを作成する必要があります。これは、次のコマンドで行うことができます。 .. code:: sh kubectl create secret generic aws-creds \ --from-literal=ACCESS_KEY_ID= \ --from-literal=ACCESS_SECRET_KEY= # --from-literal=ACCESS_SESSION_TOKEN= # if required 資格情報はKubernetes内に保存され、インストールで保存時の暗号化が構成されている場合、暗号化されます。 そのシークレットが作成されたら、次の例のようにクラスターを構成できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "" s3Credentials: accessKeyId: name: aws-creds key: ACCESS_KEY_ID secretAccessKey: name: aws-creds key: ACCESS_SECRET_KEY 宛先パスには、インスタンスがWALファイルをアップロードできるフォルダーを指す任意のURLを指定できます。 ``s3://BUCKET_NAME/path/to/folder`` . サービスアカウントIRSAのIAMロール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IRSAを使用するには、Postgresクラスターの\ ``ServiceAccount`` で\ ``annotation`` を設定する必要があります。 ``serviceAccountTemplate`` スタンザを使用してそれらを注入するようにCloudNativePGを構成できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: serviceAccountTemplate: metadata: annotations: eks.amazonaws.com/role-arn: arn:[...] [...] S3ライフサイクルポリシー ^^^^^^^^^^^^^^^^^^^^^^^^ Barman CloudはS3にオブジェクトを書き込み、 Barman Cloudリテンションポリシーによって削除されるまで更新しません。 S3ライフサイクルポリシーで推奨されるアプローチは、オブジェクトの現在のバージョンをBarman保持ポリシーより数日長く有効期限があり、オブジェクトのバージョニングを有効にし、数日後に非最新バージョンの有効期限を有効にすることです。このようなポリシーは、誤った削除から保護し、CloudNativePGワークロードへの権限を制限できるように、オブジェクトを完全に削除する権限を付与せずにS3からオブジェクトを削除できます。 その他のS3互換オブジェクトストレージプロバイダー ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **MinIO** や **Linode Object Storage** のようなS3互換オブジェクトストレージを使用している場合、デフォルトのS3のものを使用する代わりにエンドポイントを指定できます。 この例では、リージョン\ ``us-east1`` の **Linode** の\ ``bucket`` を使用します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "s3://bucket/" endpointURL: "https://us-east1.linodeobjects.com" s3Credentials: [...] **Digital Ocean Spaces** を使用している場合、Pathスタイルの構文を使用する必要があります。この例では、リージョン\ ``SFO3`` の **Digital Ocean Spaces** の\ ``bucket`` を使用します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "s3://[your-bucket-name]/[your-backup-folder]/" endpointURL: "https://sfo3.digitaloceanspaces.com" s3Credentials: [...] .. Important:: HTTPS経由でMinIOを使用する場合など、プライベートCAで署名された証明書を使用するオブジェクトストレージプロバイダーを構成するとします。その場合、 Barmanが証明書を正しく検証できるように、CAバンドルを含むシークレットを参照するオプション `endpointCA` を設定する必要があります。 .. Note:: ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`cnpg.io/reload` のラベルをSecrets/ConfigMapsに追加できます。それ以外の場合は、 `kubectl cnpg reload` サブコマンドを使用してインスタンスをリロードする必要があります。 Azure Blob Storage ------------------ `Azure Blob Storage `_ は、Microsoftが提供するobectストレージサービスです。 CloudNativePG管理対象データベースのバックアップとリカバリーのためにストレージアカウントにアクセスするには、次の資格情報のいずれかの組み合わせが必要です。 - :ref:`Connection String <ストレージ>` - ストレージアカウント名と :ref:`Storage account access key <ストレージ>` - ストレージアカウント名と :ref:`Storage account SAS Token <ストレージ>` - ストレージアカウント名と `Azure AD Workload Identity `_ 適切に構成されました。 **Azure AD Workload Identity** を使用すると、資格情報をKubernetesシークレットに保存せず、次のように\ ``inheritFromAzureAD`` を追加するクラスター構成にすることができます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "" azureCredentials: inheritFromAzureAD: true 一方、 **ストレージアカウントアクセスキー** または **ストレージアカウントSASトークン** の両方を使用する場合、資格情報をKubernetes Secret内に保存し、必要な場合にのみデータエントリを追加する必要があります。次のコマンドはそれを実行します。 :: kubectl create secret generic azure-creds \ --from-literal=AZURE_STORAGE_ACCOUNT= \ --from-literal=AZURE_STORAGE_KEY= \ --from-literal=AZURE_STORAGE_SAS_TOKEN= \ --from-literal=AZURE_STORAGE_CONNECTION_STRING= 使用されるKubernetesクラスターでこの機能が有効になっている場合、資格情報は保存時に暗号化されます。 前述のシークレットを踏まえて、提供された資格情報をクラスター構成内に注入できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "" azureCredentials: connectionString: name: azure-creds key: AZURE_CONNECTION_STRING storageAccount: name: azure-creds key: AZURE_STORAGE_ACCOUNT storageKey: name: azure-creds key: AZURE_STORAGE_KEY storageSasToken: name: azure-creds key: AZURE_STORAGE_SAS_TOKEN Azure Blob Storageを使用する場合、\ ``destinationPath`` は次の構造を満たします。 :: ://..core.windows.net/ ```` は\ ``/`` です。 **ストレージアカウント名** とも呼ばれる **アカウント名** は、使用されるホスト名に含まれます。 その他のAzure Blob Storage互換プロバイダー ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Azure Blob Storage APIの別の実装を使用している場合、\ ``destinationPath`` は次の構造になります。 :: ://:// その場合、\ ```` はパスの最初のコンポーネントです。 これは、 Azureストレージエミュレータまたは `Azurite `_ を介してAzureサポートをテストする場合に必要です。 Google Cloud Storage -------------------- 現在、CloudNativePGオペレーターは、 `Google Cloud Storage `_ の2つの認証方法をサポートしています。 - 最初のものは、ポッドがGoogle Kubernetes Engineクラスター内で実行されていることを前提としています - 2つ目は、環境変数\ ``GOOGLE_APPLICATION_CREDENTIALS`` を活用します Google Kubernetes Engine内での実行 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Google Kubernetes Engine内で実行されている場合、資格情報を設定せずに `Workload Identity `_ に単に依存するようにバックアップを構成できます。特に、次のことを行う必要があります。 - ``.spec.backup.barmanObjectStore.googleCredentials.gkeEnvironment`` を\ ``true`` に設定します - ``serviceAccountTemplate`` スタンザに\ ``iam.gke.io/gcp-service-account`` アノテーションを設定する 次の例を参考として使用してください。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: [...] backup: barmanObjectStore: destinationPath: "gs://" googleCredentials: gkeEnvironment: true serviceAccountTemplate: metadata: annotations: iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com [...] 認証を使用する ^^^^^^^^^^^^^^ `instruction from Google `_ をフォローする 認証に必要な情報をすべて含むJSONファイルを取得します。 JSONファイルのコンテンツは、次のコマンドで作成できる\ ``Secret`` を使用して提供する必要があります。 .. code:: shell kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json これにより、次のようにyamlファイルで使用される\ ``backup-creds`` という名前で\ ``Secret`` が作成されます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: "gs://" googleCredentials: applicationCredentials: name: backup-creds key: gcsCredentials 次に、オペレーターは資格情報を使用してGoogle Cloud Storageに対して認証します。 .. Important:: この認証方法は、Google Cloud Storageバケットにアクセスするために必要なすべての情報を含むJSONファイルをコンテナ内に作成します。つまり、誰かがポッドへのアクセスを取得すると、バケットへの書き込み権限もあります。 MinIOゲートウェイ ----------------- オプションで、バックアップオブジェクトをS3やGCSなどの他のクラウドストレージソリューションに中継する共通インターフェイスとしてMinIOゲートウェイを使用できます。詳細については、 `MinIO official documentation `_ を参照してください。 具体的には、CloudNativePGクラスターは、以前に作成した資格情報とサービスを使用して、エンドポイントとしてローカルMinIOゲートウェイを直接ポイントできます。 MinIOシークレットは、PostgreSQLクラスターとMinIOインスタンスの両方で使用されます。したがって、それらを同じ名前空間に作成する必要があります。 .. code:: sh kubectl create secret generic minio-creds \ --from-literal=MINIO_ACCESS_KEY= \ --from-literal=MINIO_SECRET_KEY= .. Note:: この場合、クラウドオブジェクトストレージ資格情報はMinIOゲートウェイによってのみ使用されます。 .. Important:: PostgreSQLがMinIOゲートウェイに到達できるようにオーダーには、MinIOゲートウェイインスタンスにバインドされたポート`9000` に`ClusterIP` サービスを作成する必要があります。 例 .. code:: yaml apiVersion: v1 kind: Service metadata: name: minio-gateway-service spec: type: ClusterIP ports: - port: 9000 targetPort: 9000 protocol: TCP selector: app: minio .. Warning:: このドキュメントの執筆時点では、公式の `MinIO Operator `_ for Kubernetesは、ゲートウェイ機能をサポートしていません。そのため、代わりに\ ``deployment`` を使用します。 MinIO展開は、クラウドストレージの資格情報を使用してオブジェクトをリモートバケットにアップロードし、バックアップファイルを別の場所に中継します。 次に、AWS S3をクラウドオブジェクトストレージとして使用する例を示します。 .. code:: yaml apiVersion: apps/v1 kind: Deployment [...] spec: containers: - name: minio image: minio/minio:RELEASE.2020-06-03T22-13-49Z args: - gateway - s3 env: # MinIO access key and secret key - name: MINIO_ACCESS_KEY valueFrom: secretKeyRef: name: minio-creds key: MINIO_ACCESS_KEY - name: MINIO_SECRET_KEY valueFrom: secretKeyRef: name: minio-creds key: MINIO_SECRET_KEY # AWS credentials - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aws-creds key: ACCESS_KEY_ID - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: aws-creds key: ACCESS_SECRET_KEY # Uncomment the below section if session token is required # - name: AWS_SESSION_TOKEN # valueFrom: # secretKeyRef: # name: aws-creds # key: ACCESS_SESSION_TOKEN ports: - containerPort: 9000 ``Cluster`` 定義の\ ``endpointURL`` としてMinIO Gatewayサービスを構成し、 ``BUCKET_NAME`` を置き換えるバケット名を選択します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster [...] spec: backup: barmanObjectStore: destinationPath: s3://BUCKET_NAME/ endpointURL: http://minio-gateway-service:9000 s3Credentials: accessKeyId: name: minio-creds key: MINIO_ACCESS_KEY secretAccessKey: name: minio-creds key: MINIO_SECRET_KEY [...] バックアップを続行する前に、\ ``s3://BUCKET_NAME/`` でアーカイブされたWALファイルの存在を確認します。