Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.

Implementar MongoDB Ops Manager con una base de datos de la aplicación externa

Puede implementar un recurso de MongoDB Ops Manager que utiliza una base de datos de la aplicación externa: un recurso personalizado de MongoDB con spec.role establecido en AppDB, que una segunda instancia de MongoDB Ops Manager gestiona como un Proyecto. Esto permite a MongoDB Ops Manager realizar copias de seguridad y restaurar la base de datos de la aplicación. Para obtener más información, consulte Realizar copias de seguridad de la base de datos de la aplicación de MongoDB Ops Manager.

Este procedimiento implementa una nueva instancia de MongoDB Ops Manager. Para convertir una instancia existente de Ops Manager que utiliza una base de datos de la aplicación gestionada internamente, consulte Migrar una base de datos de la aplicación a una implementación externa.

Este procedimiento implementa los siguientes recursos:

  • Una instancia de MongoDB Ops Manager de gestión con su propia base de datos de la aplicación gestionada internamente. Esta instancia gestiona el Proyecto que contiene la base de datos de la aplicación externa.

  • Una base de datos de la aplicación externa: un set de réplicas de MongoDB con spec.role establecido en AppDB, denominado <primary-om-name>-db.

  • Una instancia **primaria** de MongoDB Ops Manager que omite y hace referencia a la base de datos de la aplicación spec.applicationDatabase externa spec.externalApplicationDatabaseRef con.

Antes de comenzar, cumpla con las siguientes tareas:

  • Implementar un clúster de Kubernetes con un StorageClass por defecto.

  • Instale kubectl y helm y configúrelos para ese clúster.

  • Obtener acceso a la gráfica Helm del operador de Kubernetes.

Establezca la versión de MongoDB Ops Manager y la versión de la base de datos de la aplicación en un par coherente. La instancia de gestión de MongoDB Ops Manager gestiona la base de datos de la aplicación externa, por lo tanto, la versión de la base de datos de la aplicación debe ser una versión de MongoDB que la instancia de gestión de MongoDB Ops Manager ofrece en su manifiesto de versión. Por ejemplo, un 8.0.x La instancia de Ops Manager ofrece 8.0.x Versiones de MongoDB, pero una 7.0.x La instancia de MongoDB Ops Manager no lo hace. Para encontrar un par compatible, consulte la matriz de compatibilidad de la base de datos de la aplicación.

1
export K8S_CTX="<your-kube-context>"export MDB_NS="mongodb" export OPERATOR_HELM_CHART="oci://quay.io/mongodb/helm-charts/mongodb-kubernetes" export OM_VERSION="8.0.7"export APPDB_VERSION="8.0.5-ent" export MANAGEMENT_OM_NAME="management-om"export PRIMARY_OM_NAME="primary-om" export APPDB_NAME="${PRIMARY_OM_NAME}-db" export MANAGEMENT_OM_URL="http://${MANAGEMENT_OM_NAME}-svc.${MDB_NS}.svc.cluster.local:8080"export MANAGEMENT_OM_ADMIN_KEY_SECRET="${MDB_NS}-${MANAGEMENT_OM_NAME}-admin-key" export APPDB_PROJECT_CONFIGMAP="${APPDB_NAME}-config"export APPDB_PROJECT_NAME="external-appdb"export APPDB_CONNECTION_STRING_SECRET="${APPDB_NAME}-connection-string" export OM_ADMIN_EMAIL="admin@example.com"export OM_ADMIN_PASSWORD="<your-password>"export OM_ADMIN_FIRST_NAME="Admin"export OM_ADMIN_LAST_NAME="User"

El operador de Kubernetes requiere que la base de datos de la aplicación externa se llame <primary-om-name>-db, por lo que APPDB_NAME se deriva de PRIMARY_OM_NAME.

2
kubectl create namespace "${MDB_NS}" --context "${K8S_CTX}"
3
helm upgrade --install --kube-context "${K8S_CTX}" \ --namespace "${MDB_NS}" --create-namespace \ mongodb-kubernetes "${OPERATOR_HELM_CHART}" kubectl rollout status deployment/mongodb-kubernetes-operator \ --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=300s
4

Ambos recursos de MongoDB Ops Manager hacen referencia a este secreto con spec.adminCredentials.

kubectl create secret generic ops-manager-admin-secret \ --context "${K8S_CTX}" -n "${MDB_NS}" \ --from-literal=Username="${OM_ADMIN_EMAIL}" \ --from-literal=Password="${OM_ADMIN_PASSWORD}" \ --from-literal=FirstName="${OM_ADMIN_FIRST_NAME}" \ --from-literal=LastName="${OM_ADMIN_LAST_NAME}"
5
kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: ${MANAGEMENT_OM_NAME}spec: replicas: 1 version: ${OM_VERSION} adminCredentials: ops-manager-admin-secret applicationDatabase: members: 3 version: ${APPDB_VERSION} backup: enabled: false configuration: automation.versions.source: mongodb mms.ignoreInitialUiSetup: "true" mms.adminEmailAddr: admin@example.com mms.fromEmailAddr: admin@example.com mms.replyToEmailAddr: admin@example.com mms.mail.hostname: email-smtp.us-east-1.amazonaws.com mms.mail.port: "465" mms.mail.ssl: "true" mms.mail.transport: smtp mms.minimumTLSVersion: TLSv1.2EOF

La configuración de correo de mms.* es obligatoria. Cuando mms.ignoreInitialUiSetup es true, la comprobación previa de MongoDB Ops Manager no inicia MongoDB Ops Manager a menos que mms.fromEmailAddr y la configuración de correo relacionada estén presentes.

6
  1. Espere a la base de datos de la aplicación gestionada internamente y al recurso de MongoDB Ops Manager:

    kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \ om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1200s kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \ om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1800s
  2. Confirme que la API pública de MongoDB Ops Manager responde a las solicitudes. Un opsManager.phase de Running significa que el pod de MongoDB Ops Manager está en funcionamiento, pero la API que utiliza el operador de Kubernetes para crear el Proyecto de base de datos de la aplicación puede retrasarse unos segundos. Una respuesta 401 es la respuesta no autenticada esperada y significa que la API está lista:

    om_pod="${MANAGEMENT_OM_NAME}-0"until [ "$(kubectl exec "${om_pod}" -c mongodb-ops-manager --context "${K8S_CTX}" -n "${MDB_NS}" -- \ curl -s -o /dev/null -w '%{http_code}' \ "http://$(kubectl get pod "${om_pod}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{.status.podIP}'):8080/api/public/v1.0" 2>/dev/null)" = "401" ]; do echo "waiting for management Ops Manager public API..."; sleep 10done
  3. Confirme que el operador de Kubernetes creó el secreto de la clave de API programática para la instancia de gestión de MongoDB Ops Manager:

    kubectl get secret "${MANAGEMENT_OM_ADMIN_KEY_SECRET}" \ --context "${K8S_CTX}" -n "${MDB_NS}"
7
kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \ --context "${K8S_CTX}" -n "${MDB_NS}" \ --from-literal=baseUrl="${MANAGEMENT_OM_URL}" \ --from-literal=projectName="${APPDB_PROJECT_NAME}" \ --from-literal=orgId=""
8
kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBmetadata: name: ${APPDB_NAME}spec: members: 3 version: ${APPDB_VERSION} type: ReplicaSet role: AppDB opsManager: configMapRef: name: ${APPDB_PROJECT_CONFIGMAP} credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET} persistent: trueEOF kubectl wait --for=jsonpath='{.status.phase}'=Running \ mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1200s

Cuando estableces spec.role en AppDB, el operador de Kubernetes configura la autenticación SCRAM para el recurso. Para obtener más información, se puede consultar spec.role.

9

Este recurso omite spec.applicationDatabase y hace referencia a la base de datos de la aplicación externa en su lugar.

kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: ${PRIMARY_OM_NAME}spec: replicas: 1 version: ${OM_VERSION} adminCredentials: ops-manager-admin-secret externalApplicationDatabaseRef: name: ${APPDB_NAME} kind: MongoDB backup: enabled: false configuration: automation.versions.source: mongodb mms.ignoreInitialUiSetup: "true" mms.adminEmailAddr: admin@example.com mms.fromEmailAddr: admin@example.com mms.replyToEmailAddr: admin@example.com mms.mail.hostname: email-smtp.us-east-1.amazonaws.com mms.mail.port: "465" mms.mail.ssl: "true" mms.mail.transport: smtp mms.minimumTLSVersion: TLSv1.2EOF

Para habilitar la copia de seguridad para sus implementaciones de MongoDB, establezca spec.backup.enabled en true en este recurso y configure el almacenamiento de snapshot. Para obtener más información, consulte Configurar el almacenamiento de copia de seguridad del sistema de archivos con el operador de Kubernetes.

10
kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \ om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1800s kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Disabled \ om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=600s

El operador de Kubernetes no gestiona una base de datos de la aplicación interna para un recurso de MongoDB Ops Manager que utiliza una base de datos de la aplicación externa, por lo que status.applicationDatabase.phase informa de Disabled. Esto es lo esperado y no es un error.

11
  1. Confirme que los pods de gestión de MongoDB Ops Manager, los pods externos de la base de datos de la aplicación y los pods primarios de MongoDB Ops Manager están en ejecución:

    kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
  2. Confirme que el recurso de MongoDB controla el StatefulSet de la base de datos de la aplicación y que el recurso primario de MongoDB Ops Manager no lo controla:

    kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'

    El comando devuelve MongoDB/${APPDB_NAME}.

  3. Confirme que el operador de Kubernetes creó el secreto de la cadena de conexión para la instancia principal de MongoDB Ops Manager:

    kubectl get secret "${APPDB_CONNECTION_STRING_SECRET}" \ --context "${K8S_CTX}" -n "${MDB_NS}"

Si la base de datos de la aplicación externa informa Failed con un mensaje de que la versión de MongoDB no está disponible, establezca spec.version en una versión que ofrezca la instancia de MongoDB Ops Manager de gestión. Mantenga la versión de MongoDB Ops Manager y la versión de la base de datos de la aplicación en la misma versión principal. La base de datos de la aplicación gestionada internamente propia de la instancia de MongoDB Ops Manager de gestión no se ve afectada, porque descarga los binarios directamente cuando establece automation.versions.source en mongodb.

Si la base de datos de la aplicación externa permanece en la Pending fase y el MongoDB Agent nunca recibe una configuración de automatización, es posible que haya creado el recurso de MongoDB antes de que la API pública de gestión de MongoDB Ops Manager estuviera atendiendo solicitudes. El operador de Kubernetes no pudo crear el Proyecto. Confirme que la comprobación de disponibilidad de la API devuelve 401, luego vuelva a conciliar el recurso.

El valor de spec.externalApplicationDatabaseRef.name debe ser exactamente <primary-om-name>-db, y el recurso de MongoDB debe estar en el mismo namespace que el recurso de MongoDB Ops Manager.

Para hacer una copia de seguridad de la base de datos de la aplicación externa, habilite la copia de seguridad en el recurso de MongoDB en el Proyecto que gestiona la instancia de MongoDB Ops Manager de gestión. Para aprender más, consulte Configurar las copias de seguridad de la base de datos de MongoDB.