Konfigurieren und Bereitstellen eines MongoDB-Clusters in Azure Kubernetes Service (AKS)

In diesem Artikel konfigurieren Sie einen MongoDB-Cluster in Azure Kubernetes Service (AKS) und stellen ihn bereit.

Konfigurieren einer Workloadidentität

1. Erstellen Sie für den MongoDB-Cluster einen Namespace, indem Sie den Befehl kubectl create namespace verwenden.

   kubectl create namespace ${AKS_MONGODB_NAMESPACE} --dry-run=client --output yaml | kubectl apply -f -
   

   Beispielausgabe:

   namespace/mongodb created
   

2. Erstellen Sie ein Dienstkonto, und konfigurieren Sie eine Workloadidentität mithilfe des Befehls kubectl apply.

   export TENANT_ID=$(az account show --query tenantId -o tsv)
   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       azure.workload.identity/client-id: "${MY_IDENTITY_NAME_CLIENT_ID}"
       azure.workload.identity/tenant-id: "${TENANT_ID}"
     name: "${SERVICE_ACCOUNT_NAME}"
     namespace: "${AKS_MONGODB_NAMESPACE}"
   EOF
   

   Beispielausgabe:

   serviceaccount/mongodb created
   

Installieren von External Secrets Operator

In diesem Abschnitt verwenden Sie Helm, um External Secrets Operator zu installieren. External Secrets Operator ist ein Kubernetes-Operator, der den Lebenszyklus externer Geheimnisse verwaltet, die in externen Geheimnisspeichern wie Azure Key Vault gespeichert sind.

1. Fügen Sie das Helm-Repository für externe Geheimnisse hinzu, und aktualisieren Sie das Repository, indem Sie die Befehle helm repo add und helm repo update verwenden.

   helm repo add external-secrets https://charts.external-secrets.io
   helm repo update
   

   Beispielausgabe:

   Hang tight while we grab the latest from your chart repositories...
   ...Successfully got an update from the "external-secrets" chart repository
   

2. Installieren Sie den Operator für externe Geheimnisse mithilfe des Befehls helm install.

   helm install external-secrets \
   external-secrets/external-secrets \
   --namespace ${AKS_MONGODB_NAMESPACE} \
   --create-namespace \
   --set installCRDs=true \
   --wait \
   --set nodeSelector."kubernetes\.azure\.com/agentpool"=mongodbpool
   

   Beispielausgabe:

   NAME: external-secrets
   LAST DEPLOYED: Tue Jun 11 11:55:32 2024
   NAMESPACE: mongodb
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None
   NOTES:
   external-secrets has been deployed successfully in namespace mongodb!
   
   In order to begin using ExternalSecrets, you will need to set up a SecretStore
   or ClusterSecretStore resource (for example, by creating a 'vault' SecretStore).
   
   More information on the different types of SecretStores and how to configure them
   can be found in our Github: https://github.com/external-secrets/external-secrets
   

3. Generieren Sie ein zufälliges Kennwort mithilfe der Funktion:

   #MongoDB connection strings can contain special characters in the password, which need to be URL encoded. 
   #This is because the connection string is a URI, and special characters can interfere with the URI structure.
   #This function generates secrets of 32 characters using only alphanumeric characters.
   
   generateRandomPasswordString() {
       cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1
   }
   

Erstellen von MongoDB-Geheimnissen

1. Erstellen Sie mithilfe des Befehls ein MongoDB-Geheimnis vom Typ az keyvault secret set, das für alle Sicherungs- und Wiederherstellungsvorgänge verwendet werden soll.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-BACKUP-USER --value MONGODB_BACKUP_USER --output none
   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-BACKUP-PASSWORD --value $(generateRandomPasswordString) --output none
   

2. Erstellen Sie mithilfe des Befehls ein MongoDB-Geheimnis vom Typ az keyvault secret set für die Datenbankverwaltung.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-DATABASE-ADMIN-USER --value MONGODB_DATABASE_ADMIN_USER --output none
   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-DATABASE-ADMIN-PASSWORD --value $(generateRandomPasswordString) --output none
   

3. Erstellen Sie mithilfe des Befehls ein MongoDB-Geheimnis vom Typ az keyvault secret set für eine Clusterverwaltungsrolle, die die Verwaltung von mehreren Datenbanken ermöglicht.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-CLUSTER-ADMIN-USER --value MONGODB_CLUSTER_ADMIN_USER --output none
   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-CLUSTER-ADMIN-PASSWORD --value $(generateRandomPasswordString) --output none
   

4. Erstellen Sie mithilfe des Befehls ein MongoDB-Geheimnis vom Typ az keyvault secret set für die Clusterüberwachung.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-CLUSTER-MONITOR-USER --value MONGODB_CLUSTER_MONITOR_USER --output none
   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-CLUSTER-MONITOR-PASSWORD --value $(generateRandomPasswordString) --output none
   

5. Erstellen Sie mithilfe des Befehls Geheimnis vom Typ „Benutzer und Kennwort“ für die az keyvault secret set.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-USER-ADMIN-USER --value MONGODB_USER_ADMIN_USER --output none
   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name MONGODB-USER-ADMIN-PASSWORD --value $(generateRandomPasswordString) --output none
   

6. Erstellen Sie mithilfe des Befehls az keyvault secret set ein Geheimnis für den API-Schlüssel, der für den Zugriff auf den Percona Monitoring and Management-Server (PMM) verwendet wird. Sie aktualisieren den Wert dieses Geheimnisses später, wenn Sie den PMM-Server bereitstellen.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name PMM-SERVER-API-KEY --value $(openssl rand -base64 32) --output none
   

7. Fügen Sie mithilfe des Befehls AZURE-STORAGE-ACCOUNT-NAME später az keyvault secret set für Sicherungen hinzu.

   az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name AZURE-STORAGE-ACCOUNT-NAME --value $AKS_MONGODB_BACKUP_STORAGE_ACCOUNT_NAME --output none
   

1. Führen Sie den folgenden Befehl aus, um die mongodb.tfvars zuvor erstellte Datei mit der folgenden Konfiguration zu aktualisieren:

   cat >> mongodb.tfvars <<EOL
   mongodb_kv_secrets = {
     MONGODB-BACKUP-USER              = "MONGODB_BACKUP_USER"
     MONGODB-BACKUP-PASSWORD          = "$(generateRandomPasswordString)"
     MONGODB-DATABASE-ADMIN-USER      = "MONGODB_DATABASE_ADMIN_USER"
     MONGODB-DATABASE-ADMIN-PASSWORD  = "$(generateRandomPasswordString)"
     MONGODB-CLUSTER-ADMIN-USER       = "MONGODB_CLUSTER_ADMIN_USER"
     MONGODB-CLUSTER-ADMIN-PASSWORD   = "$(generateRandomPasswordString)"
     MONGODB-CLUSTER-MONITOR-USER     = "MONGODB_CLUSTER_MONITOR_USER"
     MONGODB-CLUSTER-MONITOR-PASSWORD = "$(generateRandomPasswordString)"
     MONGODB-USER-ADMIN-USER          = "MONGODB_USER_ADMIN_USER"
     MONGODB-USER-ADMIN-PASSWORD      = "$(generateRandomPasswordString)"
     PMM-SERVER-API-KEY               = "$(generateRandomPasswordString)"
   }
   EOL
   

2. Wenden Sie die Terraformkonfiguration auf die Zielressource an.

   terraform fmt
   terraform apply -var-file="mongodb.tfvars" -target module.mongodb[0].azurerm_key_vault_secret.this
   

Erstellen von Geheimnisressourcen

1. Erstellen Sie eine SecretStore-Ressource, um auf die im Schlüsseltresor gespeicherten MongoDB-Kennwörter zuzugreifen, indem Sie den Befehl kubectl apply verwenden.

   kubectl apply -f - <<EOF
   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: azure-store
     namespace: ${AKS_MONGODB_NAMESPACE}
   spec:
     provider:
       # provider type: azure keyvault
       azurekv:
         authType: WorkloadIdentity
         vaultUrl: "${KEYVAULTURL}"
         serviceAccountRef:
           name: ${SERVICE_ACCOUNT_NAME}
   EOF
   

   Beispielausgabe:

   secretstore.external-secrets.io/azure-store created
   

2. Erstellen Sie mithilfe des Befehls ExternalSecret eine kubectl apply-Ressource. Diese Ressource erstellt ein Kubernetes-Geheimnis im Namespace mongodb mit den MongoDB-Geheimnissen in Ihrem Schlüsseltresor.

   kubectl apply -f - <<EOF
   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: ${AKS_MONGODB_SECRETS_NAME}
     namespace: ${AKS_MONGODB_NAMESPACE}
   spec:
     refreshInterval: 1h
     secretStoreRef:
       kind: SecretStore
       name: azure-store
   
     target:
       name: "${AKS_MONGODB_SECRETS_NAME}"
       creationPolicy: Owner
   
     data:
       # name of the SECRET in the Azure key vault (no prefix is by default a SECRET)
       - secretKey: MONGODB_BACKUP_USER
         remoteRef:
           key: MONGODB-BACKUP-USER
       - secretKey: MONGODB_BACKUP_PASSWORD
         remoteRef:
           key: MONGODB-BACKUP-PASSWORD
       - secretKey: MONGODB_DATABASE_ADMIN_USER
         remoteRef:
           key: MONGODB-DATABASE-ADMIN-USER
       - secretKey: MONGODB_DATABASE_ADMIN_PASSWORD
         remoteRef:
           key: MONGODB-DATABASE-ADMIN-PASSWORD
       - secretKey: MONGODB_CLUSTER_ADMIN_USER
         remoteRef:
           key: MONGODB-CLUSTER-ADMIN-USER
       - secretKey: MONGODB_CLUSTER_ADMIN_PASSWORD
         remoteRef:
           key: MONGODB-CLUSTER-ADMIN-PASSWORD
       - secretKey: MONGODB_CLUSTER_MONITOR_USER
         remoteRef:
           key: MONGODB-CLUSTER-MONITOR-USER
       - secretKey: MONGODB_CLUSTER_MONITOR_PASSWORD
         remoteRef:
           key: MONGODB-CLUSTER-MONITOR-PASSWORD
       - secretKey: MONGODB_USER_ADMIN_USER
         remoteRef:
           key: MONGODB-USER-ADMIN-USER
       - secretKey: MONGODB_USER_ADMIN_PASSWORD
         remoteRef:
           key: MONGODB-USER-ADMIN-PASSWORD
       - secretKey: PMM_SERVER_API_KEY
         remoteRef:
           key: PMM-SERVER-API-KEY
   EOF
   

   Beispielausgabe:

   externalsecret.external-secrets.io/cluster-aks-mongodb-secrets created
   

3. Erstellen Sie mithilfe des Befehls ExternalSecret eine kubectl apply-Ressource. Diese Ressource erstellt ein Kubernetes-Geheimnis im Namespace mongodb für Azure Blob Storage-Geheimnisse in Ihrem Schlüsseltresor.

   kubectl apply -f - <<EOF
   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: ${AKS_AZURE_SECRETS_NAME}
     namespace: ${AKS_MONGODB_NAMESPACE}
   spec:
     refreshInterval: 1h
     secretStoreRef:
       kind: SecretStore
       name: azure-store
   
     target:
       name: "${AKS_AZURE_SECRETS_NAME}"
       creationPolicy: Owner
   
     data:
       # name of the SECRET in the Azure key vault (no prefix is by default a SECRET)
       - secretKey: AZURE_STORAGE_ACCOUNT_NAME
         remoteRef:
           key: AZURE-STORAGE-ACCOUNT-NAME
       - secretKey: AZURE_STORAGE_ACCOUNT_KEY
         remoteRef:
           key: AZURE-STORAGE-ACCOUNT-KEY
   EOF
   

   Beispielausgabe:

   externalsecret.external-secrets.io/cluster-aks-azure-secrets created
   

4. Erstellen Sie mit dem Befehl az identity federated-credential create Verbundanmeldeinformationen.

   az identity federated-credential create \
               --name external-secret-operator \
               --identity-name ${MY_IDENTITY_NAME} \
               --resource-group ${MY_RESOURCE_GROUP_NAME} \
               --issuer ${OIDC_URL} \
               --subject system:serviceaccount:${AKS_MONGODB_NAMESPACE}:${SERVICE_ACCOUNT_NAME} \
               --output none
   

5. Erteilen Sie mit dem Befehl az keyvault set-policy der vom Benutzer zugewiesenen Identität die Berechtigung für den Zugriff auf das Geheimnis.

   az keyvault set-policy --name $MY_KEYVAULT_NAME --object-id $MY_IDENTITY_NAME_PRINCIPAL_ID --secret-permissions get --output table
   

   Beispielausgabe:

   Location       Name            ResourceGroup
   -------------  --------------  --------------------------------
   australiaeast  vault-cjcfc-kv  myResourceGroup-rg-australiaeast
   

4. Fügen Sie die folgende Terraform-Konfiguration in mongodb/main.tf hinzu, um Verbundanmeldeinformationen zu erstellen.

   ## Section to create the federated identity credential for external secret operator
   resource "azurerm_federated_identity_credential" "this" {
     name                = "external-secret-operator"
     resource_group_name = var.resource_group_name
     audience            = ["api://AzureADTokenExchange"]
     issuer              = var.oidc_issuer_url
     parent_id           = azurerm_user_assigned_identity.this.id
     subject             = "system:serviceaccount:${var.mongodb_namespace}:${var.service_account_name}"
   }
   

5. Fügen Sie die folgende Terraform-Konfiguration in mongodb/main.tf hinzu, um der vom Benutzer zugewiesenen Identität die Berechtigung zum Zugriff auf das Secret zu erteilen.

   ## Section to assign permission to the user-assigned identity to access the secret
   resource "azurerm_key_vault_access_policy" "this" {
     key_vault_id = var.key_vault_id
     tenant_id    = azurerm_user_assigned_identity.this.tenant_id
     object_id    = azurerm_user_assigned_identity.this.principal_id
   
     secret_permissions = [
       "Get"
     ]
   }
   

6. Wenden Sie die Terraform-Konfiguration an.

       terraform fmt
   
       terraform apply -var-file="mongodb.tfvars" \
      -target=module.mongodb[0].azurerm_federated_identity_credential.this \
      -target=module.mongodb[0].azurerm_key_vault_access_policy.this
   

Installieren von Percona Operator und CRDs

Percona Operator wird in der Regel als Kubernetes-Deployment oder -Operator verteilt. Die Bereitstellung erfolgt mit einem kubectl apply -f-Befehl über eine Manifestdatei. Sie finden die neuesten Manifeste im GitHub-Repository für Percona oder in der offiziellen Dokumentation.

• Stellen Sie den Percona-Operator und benutzerdefinierte Ressourcendefinitionen (CRDs) mithilfe des Befehls kubectl apply bereit.

  kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.16.0/deploy/bundle.yaml -n "${AKS_MONGODB_NAMESPACE}"
  

  Beispielausgabe:

  customresourcedefinition.apiextensions.k8s.io/perconaservermongodbbackups.psmdb.percona.com serverside-applied
  customresourcedefinition.apiextensions.k8s.io/perconaservermongodbrestores.psmdb.percona.com serverside-applied
  customresourcedefinition.apiextensions.k8s.io/perconaservermongodbs.psmdb.percona.com serverside-applied
  role.rbac.authorization.k8s.io/percona-server-mongodb-operator serverside-applied
  serviceaccount/percona-server-mongodb-operator serverside-applied
  rolebinding.rbac.authorization.k8s.io/service-account-percona-server-mongodb-operator serverside-applied
  deployment.apps/percona-server-mongodb-operator serverside-applied
  

Bereitstellen des MongoDB-Clusters

1. Stellen Sie mithilfe des Befehls kubectl apply einen MongoDB-Cluster mit dem Percona Operator bereit. Um eine hohe Verfügbarkeit zu gewährleisten, stellen Sie den MongoDB-Cluster mit einer Replikatgruppe mit aktiviertem Sharding in mehreren Verfügbarkeitszonen und mit einer Sicherungslösung bereit, die die Sicherungen in einem Azure Blob Storage-Konto speichert.

   kubectl apply -f - <<EOF
   apiVersion: psmdb.percona.com/v1
   kind: PerconaServerMongoDB
   metadata:
     name: ${AKS_MONGODB_CLUSTER_NAME}
     namespace: ${AKS_MONGODB_NAMESPACE}
     finalizers:
       - delete-psmdb-pods-in-order
   spec:
     crVersion: 1.16.0
     image: ${MY_ACR_REGISTRY}.azurecr.io/percona-server-mongodb:7.0.8-5
     imagePullPolicy: Always
     updateStrategy: SmartUpdate
     upgradeOptions:
       versionServiceEndpoint: https://check.percona.com
       apply: disabled
       schedule: "0 2 * * *"
       setFCV: false
     secrets:
       users: "${AKS_MONGODB_SECRETS_NAME}"
       encryptionKey: "${AKS_MONGODB_SECRETS_ENCRYPTION_KEY}"
     pmm:
       enabled: true
       image: ${MY_ACR_REGISTRY}.azurecr.io/pmm-client:2.41.2
       serverHost: monitoring-service
     replsets:
       - name: rs0
         size: 3
         affinity:
           antiAffinityTopologyKey: "failure-domain.beta.kubernetes.io/zone"
         nodeSelector:
           kubernetes.azure.com/agentpool: "mongodbpool"
         podDisruptionBudget:
           maxUnavailable: 1
         expose:
           enabled: false
           exposeType: ClusterIP
         resources:
           limits:
             cpu: "300m"
             memory: "0.5G"
           requests:
             cpu: "300m"
             memory: "0.5G"
         volumeSpec:
           persistentVolumeClaim:
             storageClassName: managed-csi-premium
             accessModes: ["ReadWriteOnce"]
             resources:
               requests:
                 storage: 1Gi
         nonvoting:
           enabled: false
           size: 3
           affinity:
             antiAffinityTopologyKey: "failure-domain.beta.kubernetes.io/zone"
           nodeSelector:
             kubernetes.azure.com/agentpool: "mongodbpool"		 
           podDisruptionBudget:
             maxUnavailable: 1
           resources:
             limits:
               cpu: "300m"
               memory: "0.5G"
             requests:
               cpu: "300m"
               memory: "0.5G"
           volumeSpec:
             persistentVolumeClaim:
               storageClassName: managed-csi-premium
               accessModes: ["ReadWriteOnce"]
               resources:
                 requests:
                   storage: 1Gi
         arbiter:
           enabled: false
           size: 1
           affinity:
             antiAffinityTopologyKey: "failure-domain.beta.kubernetes.io/zone"
           nodeSelector:
             kubernetes.azure.com/agentpool: "mongodbpool"
           resources:
             limits:
               cpu: "300m"
               memory: "0.5G"
             requests:
               cpu: "300m"
               memory: "0.5G"
     sharding:
       enabled: true
       configsvrReplSet:
         size: 3
         affinity:
           antiAffinityTopologyKey: "failure-domain.beta.kubernetes.io/zone"
         nodeSelector:
           kubernetes.azure.com/agentpool: "mongodbpool"
         podDisruptionBudget:
           maxUnavailable: 1
         expose:
           enabled: false
         resources:
           limits:
             cpu: "300m"
             memory: "0.5G"
           requests:
             cpu: "300m"
             memory: "0.5G"
         volumeSpec:
           persistentVolumeClaim:
             storageClassName: managed-csi-premium
             accessModes: ["ReadWriteOnce"]
             resources:
               requests:
                 storage: 1Gi
       mongos:
         size: 3
         affinity:
           antiAffinityTopologyKey: "failure-domain.beta.kubernetes.io/zone"
         nodeSelector:
           kubernetes.azure.com/agentpool: "mongodbpool"
         podDisruptionBudget:
           maxUnavailable: 1
         resources:
           limits:
             cpu: "300m"
             memory: "0.5G"
           requests:
             cpu: "300m"
             memory: "0.5G"
         expose:
           exposeType: ClusterIP
     backup:
       enabled: true
       image: ${MY_ACR_REGISTRY}.azurecr.io/percona-backup-mongodb:2.4.1
       storages:
         azure-blob:
           type: azure
           azure:
             container: "${AKS_MONGODB_BACKUP_STORAGE_CONTAINER_NAME}"
             prefix: psmdb
             endpointUrl: "https://${AKS_MONGODB_BACKUP_STORAGE_ACCOUNT_NAME}.blob.core.windows.net"
             credentialsSecret: "${AKS_AZURE_SECRETS_NAME}"
       pitr:
         enabled: false
         oplogOnly: false
         compressionType: gzip
         compressionLevel: 6
       tasks:
         - name: daily-azure-us-east
           enabled: true
           schedule: "0 0 * * *"
           keep: 3
           storageName: azure-blob    
           compressionType: gzip
           compressionLevel: 6
   EOF
   

   Beispielausgabe:

   perconaservermongodb.psmdb.percona.com/cluster-aks-mongodb created
   

2. Schließen Sie den MongoDB-Clusterbereitstellungsprozess mit dem folgenden Skript ab:

   while [ "$(kubectl get psmdb -n ${AKS_MONGODB_NAMESPACE} -o jsonpath='{.items[0].status.state}')" != "ready" ]; do echo "waiting for MongoDB cluster to be ready"; sleep 10; done
   

3. Nach Abschluss des Prozesses weist Ihr Cluster den Status Ready auf. Sie können den Status mithilfe des Befehls kubectl get anzeigen.

   kubectl get psmdb -n ${AKS_MONGODB_NAMESPACE}
   

   Beispielausgabe:

   NAME                  ENDPOINT                                               STATUS   AGE
   cluster-aks-mongodb   cluster-aks-mongodb-mongos.mongodb.svc.cluster.local   ready    3m1s
   

4. Zeigen Sie die Verfügbarkeitszonen der Knoten in Ihrem Cluster mithilfe des Befehls kubectl get an.

   kubectl get node -o custom-columns=Name:.metadata.name,Zone:".metadata.labels.topology\.kubernetes\.io/zone"
   

   Beispielausgabe:

   Name                                   Zone
   aks-mongodbpool-30094695-vmss000000    australiaeast-1
   aks-systempool-28994785-vmss000000     australiaeast-1
   aks-systempool-28994785-vmss000001     australiaeast-2
   aks-systempool-28994785-vmss000002     australiaeast-3
   

Herstellen einer Verbindung mit Percona Server

Um eine Verbindung mit Percona Server for MongoDB herzustellen, müssen Sie die Zeichenfolge für den MongoDB-Verbindungs-URI erstellen. Er enthält die Anmeldeinformationen des Administratorbenutzers, die im Secrets-Objekt gespeichert sind.

1. Listen Sie die Secrets-Objekte mithilfe des Befehls kubectl get auf.

   kubectl get secrets -n ${AKS_MONGODB_NAMESPACE}
   

   Beispielausgabe:

   NAME                                                 TYPE                 DATA   AGE
   cluster-aks-azure-secrets                            Opaque               2      2m56s
   cluster-aks-mongodb-mongodb-keyfile                  Opaque               1      2m54s
   cluster-aks-mongodb-secrets                          Opaque               11     2m56s
   cluster-aks-mongodb-secrets-mongodb-encryption-key   Opaque               1      2m54s
   cluster-aks-mongodb-ssl                              kubernetes.io/tls    3      2m55s
   cluster-aks-mongodb-ssl-internal                     kubernetes.io/tls    3      2m54s
   external-secrets-webhook                             Opaque               4      3m49s
   internal-cluster-aks-mongodb-users                   Opaque               11     2m56s
   sh.helm.release.v1.external-secrets.v1               helm.sh/release.v1   1      3m49s
   

2. Zeigen Sie mithilfe des Befehls Secrets den kubectl get-Inhalt an, um die Administratorbenutzer-Anmeldeinformationen abzurufen.

   kubectl describe secret ${AKS_MONGODB_SECRETS_NAME} -n ${AKS_MONGODB_NAMESPACE}
   

   Beispielausgabe:

   Name:         cluster-aks-mongodb-secrets
   Namespace:    mongodb
   Labels:       reconcile.external-secrets.io/managed=true
   Annotations:  <none>
   
   Type:  Opaque
   
   Data
   ====
   MONGODB_CLUSTER_ADMIN_USER:        12 bytes
   MONGODB_CLUSTER_MONITOR_PASSWORD:  16 bytes
   MONGODB_CLUSTER_MONITOR_USER:      14 bytes
   MONGODB_DATABASE_ADMIN_USER:       13 bytes
   MONGODB_USER_ADMIN_USER:           9 bytes
   MONGODB_BACKUP_PASSWORD:           16 bytes
   MONGODB_BACKUP_USER:               6 bytes
   MONGODB_CLUSTER_ADMIN_PASSWORD:    18 bytes
   MONGODB_DATABASE_ADMIN_PASSWORD:   18 bytes
   MONGODB_USER_ADMIN_PASSWORD:       17 bytes
   

3. Decodieren Sie den Base64-codierten Anmeldenamen und das Kennwort, und exportieren Sie die Verbindungszeichenfolge mithilfe der folgenden Befehle in die Umgebungsvariable:

Important

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Der in diesem Verfahren beschriebene Authentifizierungsflow erfordert ein sehr hohes Maß an Vertrauen in die Anwendung und birgt Risiken, die bei anderen Flows nicht vorhanden sind. Sie sollten diesen Flow nur verwenden, wenn andere sicherere Flows, z. B. verwaltete Identitäten, nicht praktikabel sind.

export databaseAdmin=$(kubectl get secret ${AKS_MONGODB_SECRETS_NAME} -n ${AKS_MONGODB_NAMESPACE} -o jsonpath="{.data.MONGODB_DATABASE_ADMIN_USER}" | base64 --decode)
export databaseAdminPassword=$(kubectl get secret ${AKS_MONGODB_SECRETS_NAME} -n ${AKS_MONGODB_NAMESPACE} -o jsonpath="{.data.MONGODB_DATABASE_ADMIN_PASSWORD}" | base64 --decode)
export connectionString="mongodb://${databaseAdmin}:${databaseAdminPassword}@${AKS_MONGODB_CLUSTER_NAME}-mongos.mongodb.svc.cluster.local/admin?replicaSet=rs0&ssl=false&directConnection=true"

Verifizieren des MongoDB-Clusters

In diesem Abschnitt überprüfen Sie Ihren MongoDB-Cluster, indem Sie einen Container mit einem MongoDB-Client ausführen und die Konsolenausgabe mit Ihrem Terminal verbinden.

1. Erstellen Sie einen Pod namens percona-client unter dem ${AKS_MONGODB_NAMESPACE}-Namespace in Ihrem Cluster mithilfe des Befehls kubectl run.

   kubectl -n "${AKS_MONGODB_NAMESPACE}" run -i --rm --tty percona-client --image=${MY_ACR_REGISTRY}.azurecr.io/percona-server-mongodb:7.0.8-5 --restart=Never -- env CONN_STR=$connectionString bash -il
   

2. Überprüfen Sie in einem anderen Terminalfenster mithilfe des Befehls kubectl get, ob der Pod erfolgreich erstellt wurde.

   kubectl get pod percona-client -n ${AKS_MONGODB_NAMESPACE}
   

   Beispielausgabe:

   NAME             READY   STATUS    RESTARTS   AGE
   percona-client   1/1     Running   0          39s
   

3. Stellen Sie mithilfe der Administratorbenutzer-Anmeldeinformationen aus dem vorherigen Abschnitt in dem Terminalfenster, das Sie zum Erstellen des percona-client-Pods verwendet haben, eine Verbindung mit dem MongoDB-Cluster her.

   mongosh $CONN_STR
   

   Beispielausgabe:

   Current Mongosh Log ID: L6mN7oP8qR9sT0uV1wX2yZ3a
   Connecting to:          mongodb://<credentials>@cluster-aks-mongodb-mongos.mongodb.svc.cluster.local/admin?replicaSet=rs0&ssl=false&directConnection=true&appName=mongosh+2.1.5
   Using MongoDB:          7.0.8-5
   Using Mongosh:          2.1.5
   
   For mongosh info see: https://docs.mongodb.com/mongodb-shell/
   ...
   

4. Listen Sie die Datenbanken in Ihrem Cluster mit dem Befehl show dbs auf.

   show dbs
   

   Beispielausgabe:

   rs0 [direct: mongos] admin> show dbs
   admin   960.00 KiB
   config    3.45 MiB
   rs0 [direct: mongos] admin>
   

Erstellen einer MongoDB-Sicherung

Sie können Ihre Daten mit einer der folgenden Methoden in Azure sichern:

• Manuell: Sichern Sie Ihre Daten jederzeit manuell.
• Geplant: Konfigurieren Sie Sicherungen und deren Zeitpläne im CRD-YAML. Percona Operator führt sie automatisch entsprechend dem angegebenen Zeitplan aus.

Percona Operator kann die folgenden Sicherungstypen ausführen:

• Logische Sicherung: Abfragen von Percona Server for MongoDB nach den Datenbankdaten und Schreiben der abgerufenen Daten in den Remotesicherungsspeicher.
• Physische Sicherung: Kopieren von physischen Dateien aus dem Percona Server for MongoDB-Datenverzeichnis dbPath in den Remotesicherungsspeicher.

Logische Sicherungen verwenden weniger Speicher, sind aber langsamer als physische Sicherungen.

Um Sicherungen mit Percona in Azure Blob Storage zu speichern, müssen Sie ein Geheimnis erstellen. Sie haben diesen Schritt in einem früheren Befehl abgeschlossen. Ausführliche Anweisungen finden Sie in der Percona-Dokumentation zu Azure Blob Storage.

Konfigurieren von geplanten Sicherungen

Sie können den Sicherungszeitplan im Sicherungsabschnitt der CRD in mongodb-cr.yaml mithilfe der folgenden Anleitung definieren:

• Legen Sie den backup.enabled-Schlüssel auf true fest.
• Stellen Sie sicher, dass der Unterabschnitt backup.storages mindestens eine konfigurierte Speicherressource enthält.
• Stellen Sie sicher, dass der Unterabschnitt backup.tasks die Sicherungsplanung ermöglicht.

Weitere Informationen finden Sie unter Planen von Sicherungen.

Durchführen manueller Sicherungen

Sie können eine manuelle bedarfsgesteuerte Sicherung im Sicherungsabschnitt der CRD in mongodb-cr.yaml mithilfe der folgenden Anleitung erstellen:

• Legen Sie den backup.enabled-Schlüssel auf true fest.
• Stellen Sie sicher, dass der Unterabschnitt backup.storages mindestens eine konfigurierte Speicherressource enthält.

Weitere Informationen finden Sie unter Erstellen von bedarfsgesteuerten Sicherungen.

Bereitstellen einer MongoDB-Sicherung

1. Stellen Sie Ihre MongoDB-Sicherung mithilfe des Befehls kubectl apply bereit.

   kubectl apply -f - <<EOF
   apiVersion: psmdb.percona.com/v1
   kind: PerconaServerMongoDBBackup
   metadata:
     finalizers:
     - delete-backup
     name: az-backup1
     namespace: ${AKS_MONGODB_NAMESPACE}
   spec:
     clusterName: ${AKS_MONGODB_CLUSTER_NAME}
     storageName: azure-blob
     type: logical
   EOF
   

   Beispielausgabe:

   perconaservermongodbbackup.psmdb.percona.com/az-backup1 created
   

2. Schließen Sie den MongoDB-Sicherungsbereitstellungsprozess mit dem folgenden Skript ab:

   while [ "$(kubectl get psmdb-backup -n ${AKS_MONGODB_NAMESPACE} -o jsonpath='{.items[0].status.state}')" != "ready" ]; do echo "waiting for the backup to be ready"; sleep 10; done
   

   Beispielausgabe:

   waiting for the backup to be ready
   

3. Nach Abschluss des Prozesses sollte die Sicherung den Status Ready zurückgeben. Überprüfen Sie, ob die Sicherungsbereitstellung erfolgreich war, indem Sie den Befehl kubectl get verwenden.

   kubectl get psmdb-backup -n ${AKS_MONGODB_NAMESPACE}
   

   Beispielausgabe:

   NAME         CLUSTER               STORAGE      DESTINATION                                                                       TYPE      STATUS   COMPLETED   AGE
   az-backup1   cluster-aks-mongodb   azure-blob   https://mongodbsacjcfc.blob.core.windows.net/backups/psmdb/2024-07-01T12:27:57Z   logical   ready    3h3m        3h3m
   

4. Wenn Sie Probleme mit der Sicherung haben, können Sie mithilfe des Befehls backup-agent Protokolle aus dem Container kubectl logs des entsprechenden Pods anzeigen.

   kubectl logs pod/${AKS_MONGODB_CLUSTER_NAME}-rs0-0 -c backup-agent -n ${AKS_MONGODB_NAMESPACE}
   

Nächster Schritt

Bereitstellen einer Clientanwendung (Mongo Express)