Partager via

Configurer et déployer un cluster MongoDB sur Azure Kubernetes Service (AKS)

Dans cet article, vous configurez et déployez un cluster MongoDB sur Azure Kubernetes Service (AKS).

Configurer une identité de charge de travail

  1. Créez un espace de noms pour le cluster MongoDB à l’aide de la commande kubectl create namespace.

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

    Exemple de sortie :

    namespace/mongodb created

  2. Créez un compte de service et configurez une identité de charge de travail à l’aide de la commande 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

    Exemple de sortie :

    serviceaccount/mongodb created

Installer External Secrets Operator

Dans cette section, vous utilisez Helm pour installer External Secrets Operator. External Secrets Operator est un opérateur Kubernetes qui gère le cycle de vie des secrets externes stockés dans des magasins de secrets externes comme Azure Key Vault.

  1. Ajoutez le référentiel External Secrets Helm et mettez à jour le référentiel à l’aide des commandes helm repo add et helm repo update.

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

    Exemple de sortie :

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

  2. Installez External Secrets Operator à l’aide de la commande 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"=userpool

    Exemple de sortie :

    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. Générez un mot de passe aléatoire pour le cluster MongoDB et stockez-le dans Azure Key Vault à l’aide de la commande az keyvault secret set.

    #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
}

Créer des secrets MongoDB

  1. Créez un secret Utilisateur et mot de passe de sauvegarde MongoDB à utiliser pour toutes les opérations de sauvegarde et de restauration à l’aide de la commande az keyvault secret set.

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

  2. Créez un secret Utilisateur administrateur et mot de passe de base de données MongoDB pour l’administration de base de données à l’aide de la commande az keyvault secret set.

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

  3. Créez un secret Utilisateur d’administration de cluster et administrateur MongoDB pour un rôle d’administration de cluster qui fournit l’administration de plusieurs bases de données à l’aide de la commande az keyvault secret set.

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

  4. Créez un secret Utilisateur de surveillance de cluster et administrateur MongoDB pour la surveillance de cluster à l’aide de la commande az keyvault secret set.

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

  5. Créez un secret d’utilisateur et de mot de passe pour l’administration des utilisateurs à l’aide de la commande az keyvault secret set.

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

  6. Créez un secret pour la clé API utilisée pour accéder au serveur PMM (Percona Monitoring and Management) à l’aide de la commande az keyvault secret set. Vous mettez à jour la valeur de ce secret ultérieurement lorsque vous déployez le serveur PMM.

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

  7. Ajoutez AZURE-STORAGE-ACCOUNT-NAME à utiliser ultérieurement pour les sauvegardes à l’aide de la commande az keyvault secret set.

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

Créer des ressources de secrets

  1. Créez une ressource SecretStore pour accéder aux mots de passe MongoDB stockés dans votre coffre de clés à l’aide de la commande kubectl apply.

    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

    Exemple de sortie :

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

  2. Créez une ressource ExternalSecret en utilisant la commande kubectl apply. Cette ressource crée un secret Kubernetes dans l’espace de noms mongodb avec les secrets MongoDB stockés dans votre coffre de clés.

    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

    Exemple de sortie :

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

  3. Créez une ressource ExternalSecret en utilisant la commande kubectl apply. Cette ressource crée un secret Kubernetes dans l’espace de noms mongodb pour les secrets Stockage Blob Azure stockés dans votre coffre de clés.

    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

    Exemple de sortie :

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

  4. Créez les informations d’identification fédérées à l’aide de la commande az identity federated-credential create.

    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 table

    Exemple de sortie :

    Issuer                                                                                                                   Name                      ResourceGroup                     Subject
-----------------------------------------------------------------------------------------------------------------------  ------------------------  --------------------------------  -------------------------------------
https://australiaeast.oic.prod-aks.azure.com/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/  external-secret-operator  myResourceGroup-rg-australiaeast  system:serviceaccount:mongodb:mongodb

  5. Donnez l’autorisation à l’identité affectée par l’utilisateur d’accéder au secret à l’aide de la commande az keyvault set-policy.

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

    Exemple de sortie :

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

Installer l’opérateur Percona et les CRD

L’opérateur Percona est généralement distribué en tant que Deployment ou Operator Kubernetes. Vous pouvez le déployer à l’aide d’une commande kubectl apply -f avec un fichier manifeste. Vous trouverez les derniers manifestes dans le référentiel GitHub Percona ou dans la documentation officielle.

  • Déployez l’opérateur Percona et les définitions de ressources personnalisées (CRD) à l’aide de la commande kubectl apply.

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

    Exemple de sortie :

    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

Déployer le cluster MongoDB

  1. Déployez un cluster MongoDB avec l’opérateur Percona à l’aide de la commande kubectl apply. Pour garantir la haute disponibilité, vous déployez le cluster MongoDB avec un jeu de réplicas, avec le partitionnement activé, dans plusieurs zones de disponibilité et avec une solution de sauvegarde qui stocke les sauvegardes dans un compte de Stockage Blob Azure.

    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: "userpool"
      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: "userpool"		 
        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: "userpool"
        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: "userpool"
      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: "userpool"
      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

    Exemple de sortie :

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

  2. Terminez le processus de déploiement du cluster MongoDB en utilisant le script suivant :

    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. Une fois le processus terminé, votre cluster affiche l’état Ready. Vous pouvez afficher l’état à l’aide de la commande kubectl get.

    kubectl get psmdb -n ${AKS_MONGODB_NAMESPACE}

    Exemple de sortie :

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

  4. Affichez les zones de disponibilité des nœuds de votre cluster à l’aide de la commande kubectl get.

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

    Exemple de sortie :

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

Se connecter au serveur Percona

Pour vous connecter au serveur Percona pour MongoDB, vous devez construire la chaîne d’URI de connexion MongoDB. Celle-ci inclut les informations d’identification de l’utilisateur administrateur, qui sont stockées dans l’objet Secrets.

  1. Répertoriez les objets Secrets à l’aide de la commande kubectl get.

    kubectl get secrets -n ${AKS_MONGODB_NAMESPACE}

    Exemple de sortie :

    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. Affichez le contenu de Secrets pour récupérer les informations d’identification de l’utilisateur administrateur à l’aide de la commande kubectl get.

    kubectl get secret ${AKS_MONGODB_SECRETS_NAME} -o yaml -n ${AKS_MONGODB_NAMESPACE}

    Exemple de sortie :

    apiVersion: v1
data:
MONGODB_BACKUP_PASSWORD: aB1cD2eF-3gH...
MONGODB_BACKUP_USER: cD2eF3gH4iJ...
MONGODB_CLUSTER_ADMIN_PASSWORD: eF3gH4iJ5kL6mN7oP...
MONGODB_CLUSTER_ADMIN_USER: gH4iJ5kL6mN7oP8...
MONGODB_CLUSTER_MONITOR_PASSWORD: iJ5kL6mN7oP8qR9sT0-u...
MONGODB_CLUSTER_MONITOR_USER: kL6mN7oP8qR9sT0...
MONGODB_DATABASE_ADMIN_PASSWORD: mN7oP8qR9sT0uV1...
MONGODB_DATABASE_ADMIN_USER: A1bC2dE3fH4iJ5kL...
MONGODB_USER_ADMIN_PASSWORD: C2dE3fH4iJ5kL6mN7oP...
MONGODB_USER_ADMIN_USER: E3fH4iJ5kL6mN7...
immutable: false
kind: Secret
metadata:
annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
    {"apiVersion":"external-secrets.io/v1beta1","kind":"ExternalSecret","metadata":{"annotations":{},"name":"cluster-aks-mongodb-secrets","namespace":"mongodb"},"spec":{"data":[{"remoteRef":{"key":"MONGODB-BACKUP-USER"},"secretKey":"MONGODB_BACKUP_USER"},{"remoteRef":{"key":"MONGODB-BACKUP-PASSWORD"},"secretKey":"MONGODB_BACKUP_PASSWORD"},{"remoteRef":{"key":"MONGODB-DATABASE-ADMIN-USER"},"secretKey":"MONGODB_DATABASE_ADMIN_USER"},{"remoteRef":{"key":"MONGODB-DATABASE-ADMIN-PASSWORD"},"secretKey":"MONGODB_DATABASE_ADMIN_PASSWORD"},{"remoteRef":{"key":"MONGODB-CLUSTER-ADMIN-USER"},"secretKey":"MONGODB_CLUSTER_ADMIN_USER"},{"remoteRef":{"key":"MONGODB-CLUSTER-ADMIN-PASSWORD"},"secretKey":"MONGODB_CLUSTER_ADMIN_PASSWORD"},{"remoteRef":{"key":"MONGODB-CLUSTER-MONITOR-USER"},"secretKey":"MONGODB_CLUSTER_MONITOR_USER"},{"remoteRef":{"key":"MONGODB-CLUSTER-MONITOR-PASSWORD"},"secretKey":"MONGODB_CLUSTER_MONITOR_PASSWORD"},{"remoteRef":{"key":"MONGODB-USER-ADMIN-USER"},"secretKey":"MONGODB_USER_ADMIN_USER"},{"remoteRef":{"key":"MONGODB-USER-ADMIN-PASSWORD"},"secretKey":"MONGODB_USER_ADMIN_PASSWORD"}],"refreshInterval":"1h","secretStoreRef":{"kind":"SecretStore","name":"azure-store"},"target":{"creationPolicy":"Owner","name":"cluster-aks-mongodb-secrets"}}}
    reconcile.external-secrets.io/data-hash: aB1cD2eF-3gH4iJ5kL6-mN7oP8qR=
creationTimestamp: "2024-07-01T12:24:38Z"
labels:
    reconcile.external-secrets.io/created-by: N7oP8qR9sT0uV1wX2yZ3aB4cD5eF6g
name: cluster-aks-mongodb-secrets
namespace: mongodb
ownerReferences:
- apiVersion: external-secrets.io/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ExternalSecret
    name: cluster-aks-mongodb-secrets
    uid: aaaaaaaa-0b0b-1c1c-2d2d-333333333333
resourceVersion: "1872"
uid: bbbbbbbb-1c1c-2d2d-3e3e-444444444444
type: Opaque

  3. Décodez le nom de connexion et le mot de passe codés en Base64 à partir de la sortie à l’aide des commandes suivantes :

    #Decode login name and password on the output, which are Base64-encoded
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)

echo $databaseAdmin
echo $databaseAdminPassword
echo $AKS_MONGODB_CLUSTER_NAME

    Exemple de sortie :

    MONGODB_DATABASE_ADMIN_USER
gH4iJ5kL6mN7oP8...
cluster-aks-mongodb

Vérifier le cluster MongoDB

Dans cette section, vous vérifiez votre cluster MongoDB en exécutant un conteneur avec un client MongoDB et connectez sa sortie de console à votre terminal.

  1. Créez un pod nommé percona-client sous l’espace de noms ${AKS_MONGODB_NAMESPACE} dans votre cluster à l’aide de la commande 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 -- bash -il

  2. Dans une autre fenêtre de terminal, vérifiez que le pod a été créé avec succès à l’aide de la commande kubectl get.

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

    Exemple de sortie :

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

  3. Connectez-vous au cluster MongoDB à l’aide des informations d’identification de l’utilisateur administrateur de la section précédente dans la fenêtre de terminal que vous avez utilisée pour créer le pod percona-client.

    # Note: Replace variables `databaseAdmin` , `databaseAdminPassword` and `AKS_MONGODB_CLUSTER_NAME` with actual values printed in step 3.

mongosh "mongodb://${databaseAdmin}:${databaseAdminPassword}@${AKS_MONGODB_CLUSTER_NAME}-mongos.mongodb.svc.cluster.local/admin?replicaSet=rs0&ssl=false&directConnection=true"

    Exemple de sortie :

    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. Répertoriez les bases de données de votre cluster à l’aide de la commande show dbs.

    show dbs

    Exemple de sortie :

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

Créer une sauvegarde MongoDB

Vous pouvez sauvegarder vos données dans Azure avec l’une des méthodes suivantes :

  • Manuelle : sauvegardez manuellement vos données à tout moment.
  • Planifiée : configurez les sauvegardes et leurs planifications dans le YAML CRD. L’opérateur Percona procède automatiquement aux sauvegardes selon la planification spécifiée.

L’opérateur Percona peut effectuer l’un ou l’autre des types de sauvegardes suivants :

  • Sauvegarde logique : interroge le serveur Percona pour MongoDB pour les données de base de données, puis écrit les données récupérées dans le stockage de sauvegarde à distance.
  • Sauvegarde physique : copie les fichiers physiques du répertoire de données dbPath du serveur Percona pour MongoDB dans le stockage de sauvegarde à distance.

Les sauvegardes logiques utilisent moins de stockage, mais sont plus lentes que les sauvegardes physiques.

Pour stocker des sauvegardes sur le Stockage Blob Azure à l’aide de Percona, vous devez créer un secret. Vous avez effectué cette étape dans une commande précédente. Pour obtenir des instructions détaillées, suivez les étapes de la documentation Percona sur le Stockage Blob Azure..

Configuration de sauvegardes planifiées

Vous pouvez définir la planification des sauvegardes dans la section de sauvegarde des CRD dans mongodb-cr.yaml en utilisant les instructions suivantes :

  • Définissez la clé backup.enabled sur true.
  • Vérifiez que la sous-section backup.storages contient au moins une ressource de stockage configurée.
  • Vérifiez que la sous-section backup.tasks active la planification des sauvegardes.

Pour plus d’informations, consultez Création de sauvegardes planifiées.

Effectuer des sauvegardes manuelles

Vous pouvez effectuer une sauvegarde manuelle à la demande dans la section de sauvegarde des CRD dans mongodb-cr.yaml en utilisant les instructions suivantes :

  • Définissez la clé backup.enabled sur true.
  • Vérifiez que la sous-section backup.storages contient au moins une ressource de stockage configurée.

Pour plus d’informations, consultez Création de sauvegardes à la demande.

Déployer une sauvegarde MongoDB

  1. Déployez votre sauvegarde MongoDB à l’aide de la commande kubectl apply.

    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

    Exemple de sortie :

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

  2. Terminez le processus de déploiement de la sauvegarde MongoDB en utilisant le script suivant :

    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

    Exemple de sortie :

    waiting for the backup to be ready

  3. Une fois le processus terminé, la sauvegarde devrait retourner l’état Ready. Vérifiez que le déploiement de sauvegarde a réussi à utiliser la commande kubectl get.

    kubectl get psmdb-backup -n ${AKS_MONGODB_NAMESPACE}

    Exemple de sortie :

    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. Si vous rencontrez des problèmes avec la sauvegarde, vous pouvez consulter les journaux du conteneur backup-agent du pod approprié à l’aide de la commande kubectl logs.

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

Étape suivante

Déployer une application cliente (Mongo Express)