Skip to main content
NetApp public and hybrid cloud solutions
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Proteção de dados para aplicativos em contêineres na OpenShift Container Platform usando Trident Protect

Colaboradores banum-netapp kevin-hoke
PDFs

Esta seção do documento de referência fornece detalhes sobre a criação de snapshots e backups de Container Apps usando Trident Protect. NetApp Trident Protect oferece recursos avançados de gerenciamento de dados de aplicativos que aprimoram a funcionalidade e a disponibilidade de aplicativos Kubernetes com estado, com suporte pelos sistemas de armazenamento NetApp ONTAP e pelo provisionador de armazenamento NetApp Trident CSI. Trident Protect cria snapshots e backups de aplicativos. Isso significa que snapshots e backups são criados não apenas para os dados do aplicativo em volumes persistentes, mas também para metadados do aplicativo. Os snapshots e backups criados pelo Trident Protect podem ser armazenados em qualquer um dos seguintes storage de objetos e restaurados a partir deles posteriormente.

  • AWS S3

  • Armazenamento de Blobs do Azure

  • Armazenamento em nuvem do Google

  • ONTAP S3

  • StorageGrid

  • Qualquer outro storage compatível com S3

Trident Protect utiliza o modelo Kubernetes de controle de acesso baseado em funções (RBAC). Por padrão, Trident Protect fornece um único namespace de sistema chamado trident-protect e sua conta de serviço padrão associada. Se você tem uma organização com muitos usuários ou necessidades de segurança específicas, pode usar os recursos de RBAC do Trident Protect para obter um controle mais granular sobre o acesso a recursos e namespaces.

Informações adicionais sobre RBAC no Trident Protect podem ser encontradas no "Documentação do Trident Protect"

Observação O administrador do cluster tem acesso aos recursos no namespace padrão trident-protect e também pode acessar recursos em todos os outros namespaces. Os usuários não podem criar recursos personalizados (CRs) de gerenciamento de dados de aplicativos, como CRs de instantâneo e backup, no namespace trident-protect. Como prática recomendada, os usuários precisarão criar essas CRs no namespace do aplicativo.

Trident Protect pode ser instalado seguindo as instruções fornecidas na documentação "aqui". Esta seção mostrará o fluxo de trabalho para a proteção de dados de aplicações em contêineres e a restauração das aplicações usando Trident Protect. 1. Criação de Snapshot (sob demanda ou agendada) 2. Restauração a partir do Snapshot (restaurar para o mesmo ou para um namespace diferente) 3. Criação de backup 4. Restauração a partir do backup

Pré-requisito

Antes de criar os snapshots e backups para um aplicativo, o storage de objetos deve ser configurado no Trident Protect para armazenar os snapshots e backups. Isso é feito usando o bucket CR. Somente administradores podem criar um bucket CR e configurá-lo. O bucket CR é conhecido como AppVault no Trident Protect. Os objetos AppVault são a representação declarativa do fluxo de trabalho do Kubernetes de um bucket de armazenamento. Um CR AppVault contém as configurações necessárias para que um bucket seja usado em operações de proteção, como backups, snapshots, operações de restauração e replicação SnapMirror.

Neste exemplo, mostraremos o uso do ONTAP S3 como storage de objetos. Aqui está o fluxo de trabalho para criar AppVault CR para ONTAP S3: 1. Crie um servidor de armazenamento de objetos S3 na SVM no cluster ONTAP. 2. Crie um bucket no servidor de armazenamento de objetos. 3. Crie um usuário S3 na SVM. Guarde a chave de acesso e a chave secreta em um local seguro. 4. No OpenShift, crie um segredo para armazenar as credenciais do ONTAP S3. 5. Crie um objeto AppVault para ONTAP S3

Configurar Trident Protect AppVault para ONTAP S3

Arquivo YAML de exemplo para configurar Trident Protect com ONTAP S3 como o AppVault

# alias tp='tridentctl-protect'

appvault-secret.yaml

apiVersion: v1
stringData:
  accessKeyID: "<access key id created for a user to access ONTAP S3 bucket>"
  secretAccessKey: "corresponding Secret Access Key"
#data:
# base 64 encoded values
#  accessKeyID: <base64 access key id created for a user to access ONTAP S3 bucket>
#  secretAccessKey: <base 64  Secret Access Key>
kind: Secret
metadata:
  name: appvault-secret
  namespace: trident-protect
type: Opaque

appvault.yaml

apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: <bucket-name for storing the snapshots and backups>
      endpoint: <endpoint IP for S3>
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-secret
  providerType: OntapS3

# oc create -f appvault-secret.yaml -n trident-protect
# oc create -f appvault.yaml -n trident-protect

AppVault criado

Arquivo yaml de exemplo para instalar o aplicativo postgresql

postgres.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:14
        env:
        - name: POSTGRES_USER
          #value: "myuser"
          value: "admin"
        - name: POSTGRES_PASSWORD
          #value: "mypassword"
          value: "adminpass"
        - name: POSTGRES_DB
          value: "mydb"
        - name: PGDATA
          value: "/var/lib/postgresql/data/pgdata"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  type: ClusterIP

Now create the Trident Protect application CR for the postgres app. Include the objects in the namespace postgres and create it in the postgres namespace.
# tp create app postgres-app --namespaces postgres -n postgres

Aplicativo criado

Criar instantâneos

Criando um snapshot sob demanda

# tp create snapshot postgres-snap1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Snapshot "postgres-snap1" created.

Snapshot criado

snapshot-pvc criado

Criando um agendamento Usando o comando a seguir, os snapshots serão criados diariamente às 15:33 e dois snapshots e backups serão mantidos.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Anexo 1 criado

Criando uma programação usando yaml

# tp create schedule schedule2 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres --dry-run > hourly-snapshotschedule.yaml

cat hourly-snapshotschedule.yaml

apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  creationTimestamp: null
  name: schedule2
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault
  applicationRef: postgres-app
  backupRetention: "2"
  dataMover: Restic
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  #hour: "15"
  minute: "33"
  recurrenceRule: ""
  snapshotRetention: "2"
status: {}

Schedule2 criado

Você pode ver instantâneos criados nesta programação.

Snap criado conforme programado

Snapshots de volume também são criados.

PVC Snap criado conforme o cronograma

Excluir o aplicativo para simular a perda do aplicativo 
# oc delete deployment/postgres -n postgres
# oc get pod,pvc -n postgres
No resources found in postgres namespace.
Restaurar do Snapshot para o mesmo namespace 
# tp create sir postgres-sir --snapshot postgres/hourly-3f1ee-20250214183300 -n postgres
SnapshotInplaceRestore "postgres-sir" created.

Senhor criou

O aplicativo e seus PVCis são restaurados para o mesmo namespace.

Aplicativo restaurado, senhor

Restaurar do Snapshot para um namespace diferente 
# tp create snapshotrestore postgres-restore --snapshot postgres/hourly-3f1ee-20250214183300 --namespace-mapping postgres:postgres-restore -n postgres-restore
SnapshotRestore "postgres-restore" created.

snapRestore criado

Você pode ver que o aplicativo foi restaurado para um novo namespace.

Aplicativo restaurado, snapRestore

Criar backups

Criando um backup sob demanda

# tp create backup postgres-backup1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Backup "postgres-backup1" created.

Backup criado

Criando agendamento para backup

Os backups diários e horários na lista acima são criados a partir da programação configurada anteriormente.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Cronograma criado anteriormente

Restaurar do backup

Exclua o aplicativo e os PVCs para simular uma perda de dados.

Cronograma criado anteriormente

Restaurar para o mesmo namespace #tp create bir postgres-bir --backup postgres/hourly-3f1ee-20250224023300 -n postgres BackupInplaceRestore "postgres-bir" criado.

restaurar para o mesmo namespace

O aplicativo e os PVCs são restaurados no mesmo namespace.

aplicação e restauração de pvcs para o mesmo namespace

Restaurar para um namespace diferente Criar um novo namespace. Restaurar de um backup para o novo namespace.

restaurar para um namespace diferente

Migrar aplicativos

Para clonar ou migrar um aplicativo para um cluster diferente (realizar uma clonagem entre clusters), crie um backup no cluster de origem e, em seguida, restaure o backup em um cluster diferente. Certifique-se de que Trident Protect esteja instalado no cluster de destino.

No cluster de origem, execute as etapas conforme mostrado na imagem abaixo:

restaurar para um namespace diferente

Do cluster de origem, alterne o contexto para o cluster de destino. Em seguida, certifique-se de que o AppVault esteja acessível a partir do contexto do cluster de destino e obtenha o conteúdo do AppVault do cluster de destino.

mudar o contexto para o destino

Use o caminho de backup da lista e crie um objeto CR de backuprestore, conforme mostrado no comando abaixo.

# tp create backuprestore backup-restore-cluster2 --namespace-mapping postgres:postgres --appvault ontap-s3-appvault --path postgres-app_4d798ed5-cfa8-49ff-a5b6-c5e2d89aeb89/backups/postgres-backup-cluster1_ec0ed3f3-5500-4e72-afa8-117a04a0b1c3 -n postgres
BackupRestore "backup-restore-cluster2" created.

restaurar para o destino

Agora você pode ver que os pods do aplicativo e os pvcs são criados no cluster de destino.

aplicativo no cluster de destino