バックアップ用の共通オブジェクトストア

バックアップ用の共通オブジェクトストアファイルは、 Barman

Cloudインフラストラクチャでサポートされている任意のサービスに保存できます。つまり

サポートされているサービスの互換性のある実装を使用することもできます。

必要なセットアップは、選択したストレージプロバイダーによって異なり、以降のセクションで説明します。

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シークレットを作成する必要があります。これは、次のコマンドで行うことができます。

kubectl create secret generic aws-creds \
  --from-literal=ACCESS_KEY_ID=<access key here> \
  --from-literal=ACCESS_SECRET_KEY=<secret key here>
#  --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required

資格情報はKubernetes内に保存され、インストールで保存時の暗号化が構成されている場合、暗号化されます。

そのシークレットが作成されたら、次の例のようにクラスターを構成できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      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を構成できます。

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 を使用します。

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 を使用します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "s3://[your-bucket-name]/[your-backup-folder]/"
      endpointURL: "https://sfo3.digitaloceanspaces.com"
      s3Credentials:
        [...]

重要

HTTPS経由でMinIOを使用する場合など、プライベートCAで署名された証明書を使用するオブジェクトストレージプロバイダーを構成するとします。その場合、 Barmanが証明書を正しく検証できるように、CAバンドルを含むシークレットを参照するオプション endpointCA を設定する必要があります。

注釈

ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`cnpg.io/reload` のラベルをSecrets/ConfigMapsに追加できます。それ以外の場合は、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

Azure Blob Storage

Azure Blob Storage は、Microsoftが提供するobectストレージサービスです。

CloudNativePG管理対象データベースのバックアップとリカバリーのためにストレージアカウントにアクセスするには、次の資格情報のいずれかの組み合わせが必要です。

Connection String
ストレージアカウント名と Storage account access key
ストレージアカウント名と Storage account SAS Token
ストレージアカウント名と Azure AD Workload Identity

適切に構成されました。

Azure AD Workload Identity を使用すると、資格情報をKubernetesシークレットに保存せず、次のようにinheritFromAzureAD を追加するクラスター構成にすることができます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      azureCredentials:
        inheritFromAzureAD: true

一方、 ストレージアカウントアクセスキー または ストレージアカウントSASトークン の両方を使用する場合、資格情報をKubernetes Secret内に保存し、必要な場合にのみデータエントリを追加する必要があります。次のコマンドはそれを実行します。

kubectl create secret generic azure-creds \
  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>

使用されるKubernetesクラスターでこの機能が有効になっている場合、資格情報は保存時に暗号化されます。

前述のシークレットを踏まえて、提供された資格情報をクラスター構成内に注入できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      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 は次の構造を満たします。

<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>

<resource-path> は<container>/<blob> です。 ストレージアカウント名 とも呼ばれる アカウント名 は、使用されるホスト名に含まれます。

その他のAzure Blob Storage互換プロバイダー

Azure Blob Storage APIの別の実装を使用している場合、destinationPath は次の構造になります。

<http|https>://<local-machine-address>:<port>/<account-name>/<resource-path>

その場合、<account-name> はパスの最初のコンポーネントです。

これは、 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 アノテーションを設定する

次の例を参考として使用してください。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  [...]
  backup:
    barmanObjectStore:
      destinationPath: "gs://<destination path here>"
      googleCredentials:
        gkeEnvironment: true

  serviceAccountTemplate:
    metadata:
      annotations:
        iam.gke.io/gcp-service-account:  [...].iam.gserviceaccount.com
        [...]

認証を使用する

instruction from Google をフォローする

認証に必要な情報をすべて含むJSONファイルを取得します。

JSONファイルのコンテンツは、次のコマンドで作成できるSecret を使用して提供する必要があります。

kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json

これにより、次のようにyamlファイルで使用されるbackup-creds という名前でSecret が作成されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "gs://<destination path here>"
      googleCredentials:
        applicationCredentials:
          name: backup-creds
          key: gcsCredentials

次に、オペレーターは資格情報を使用してGoogle Cloud Storageに対して認証します。

重要

この認証方法は、Google Cloud Storageバケットにアクセスするために必要なすべての情報を含むJSONファイルをコンテナ内に作成します。つまり、誰かがポッドへのアクセスを取得すると、バケットへの書き込み権限もあります。

MinIOゲートウェイ

オプションで、バックアップオブジェクトをS3やGCSなどの他のクラウドストレージソリューションに中継する共通インターフェイスとしてMinIOゲートウェイを使用できます。詳細については、: MinIO official documentation を参照してください。

具体的には、CloudNativePGクラスターは、以前に作成した資格情報とサービスを使用して、エンドポイントとしてローカルMinIOゲートウェイを直接ポイントできます。

MinIOシークレットは、PostgreSQLクラスターとMinIOインスタンスの両方で使用されます。したがって、それらを同じ名前空間に作成する必要があります。

kubectl create secret generic minio-creds \
  --from-literal=MINIO_ACCESS_KEY=<minio access key here> \
  --from-literal=MINIO_SECRET_KEY=<minio secret key here>

注釈

この場合、クラウドオブジェクトストレージ資格情報はMinIOゲートウェイによってのみ使用されます。

重要

PostgreSQLがMinIOゲートウェイに到達できるようにオーダーには、MinIOゲートウェイインスタンスにバインドされたポート`9000` に`ClusterIP` サービスを作成する必要があります。

例

apiVersion: v1
kind: Service
metadata:
  name: minio-gateway-service
spec:
  type: ClusterIP
  ports:
    - port: 9000
      targetPort: 9000
      protocol: TCP
  selector:
    app: minio

警告

このドキュメントの執筆時点では、公式の MinIO Operator

for Kubernetesは、ゲートウェイ機能をサポートしていません。そのため、代わりにdeployment を使用します。

MinIO展開は、クラウドストレージの資格情報を使用してオブジェクトをリモートバケットにアップロードし、バックアップファイルを別の場所に中継します。

次に、AWS S3をクラウドオブジェクトストレージとして使用する例を示します。

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 を置き換えるバケット名を選択します。

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ファイルの存在を確認します。