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.roleestablecido enAppDB, 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.applicationDatabaseexternaspec.externalApplicationDatabaseRefcon.
Requisitos previos
Antes de comenzar, cumpla con las siguientes tareas:
Implementar un clúster de Kubernetes con un
StorageClasspor defecto.Instale
kubectlyhelmy configúrelos para ese clúster.Obtener acceso a la gráfica Helm del operador de Kubernetes.
Considerations
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.
Procedimiento
Establezca las variables de entorno para la implementación.
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.
Crear el secreto de administrador de MongoDB Ops Manager.
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}"Implementar la instancia de MongoDB Ops Manager de gestión.
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.2EOFLa 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.
Espere a que la instancia de gestión de MongoDB Ops Manager esté lista.
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=1800sConfirme que la API pública de MongoDB Ops Manager responde a las solicitudes. Un
opsManager.phasedeRunningsignifica 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 respuesta401es 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 10doneConfirme 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}"
Crear la base de datos externa de la aplicación.
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=1200sCuando 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.
Implementar la instancia primaria de MongoDB Ops Manager.
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.2EOFPara 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.
Espere a que la instancia primaria de MongoDB Ops Manager esté lista.
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=600sEl 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.
Verifique la implementación.
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}"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}.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}"
Problemas comunes de la base de datos de la aplicación externa
El recurso de MongoDB informa de un error de versión
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.
La base de datos externa de la aplicación permanece pendiente
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 operador rechaza la referencia externa de la base de datos de la aplicación
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.
Próximos pasos
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.