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 Ops Manager. Para convertir una instancia existente de Ops Manager que utiliza una base de datos de aplicaciones administrada internamente, consulte Migrar una base de datos de aplicaciones a una implementación externa.
Este procedimiento despliega 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 aplicación externa: un conjunto de réplicas de MongoDB con
spec.roleconfigurado aAppDB, llamado<primary-om-name>-db.Una instancia principal de Ops Manager que omite
spec.applicationDatabasey hace referencia a la base de datos de la aplicación externa conspec.externalApplicationDatabaseRef.
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.Obtenga acceso al gráfico 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 que 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 ofrezca en su manifiesto de versión. Por ejemplo, una 8.0.x instancia de MongoDB Ops Manager ofrece 8.0.x versiones de MongoDB, pero una 7.0.x instancia de MongoDB Ops Manager no lo hace.
Procedimiento
Configura las variables de entorno para el despliegue.
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 deriva de PRIMARY_OM_NAME.
Cree el secreto de administrador de 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 - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: 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.2 EOF
Se requieren las configuraciones de correo mms.*. Cuando mms.ignoreInitialUiSetup es true, la comprobación previa al vuelo de Ops Manager no inicia Ops Manager a menos que mms.fromEmailAddr y las configuraciones de correo relacionadas 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=1800s Confirme que la API pública de Ops Manager responde a las solicitudes. Una respuesta
opsManager.phaseoRunningindica que el pod de Ops Manager está activo, pero la API que utiliza el operador de Kubernetes para crear el proyecto de base de datos de la aplicación puede presentar un retraso de unos segundos. Una respuesta401es la respuesta esperada sin autenticación e indica 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 10 done Confirme que el operador de Kubernetes creó la clave secreta de API programática para la instancia de administración de Ops Manager:
kubectl get secret "${MANAGEMENT_OM_ADMIN_KEY_SECRET}" \ --context "${K8S_CTX}" -n "${MDB_NS}"
Cree la base de datos de la aplicación externa.
kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDB metadata: 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: true EOF 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.
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 - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: 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.2 EOF
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.
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=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.
Verifique la implementación.
Confirme que los pods de administración de Ops Manager, los pods de la base de datos de aplicaciones externa y los pods principales de Ops Manager estén en ejecución:
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}" Confirme que el recurso MongoDB es propietario del StatefulSet de la base de datos de la aplicación y que el recurso principal del Administrador de operaciones no lo es:
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 que indica que la versión de MongoDB no está disponible, establezca spec.version en una versión que ofrezca la instancia de Ops Manager de administración. Mantenga la versión de 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 administrada internamente por la instancia de Ops Manager de administración no se ve afectada, ya que descarga los binarios directamente cuando se 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 fase Pending y el agente de MongoDB nunca recibe una configuración de automatización, es posible que haya creado el recurso de MongoDB antes de que la API pública del administrador de operaciones estuviera procesando las solicitudes. El operador de Kubernetes no pudo crear el proyecto. Confirme que la comprobación de disponibilidad de la API devuelva 401 y, a continuación, 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 espacio de nombres que el recurso de Ops Manager.
Próximos pasos
Para realizar una copia de seguridad de la base de datos de la aplicación externa, habilite la copia de seguridad en el recurso MongoDB del proyecto que administra la instancia de Ops Manager. Para obtener más información,consulte Configurar copias de seguridad de la base de datos MongoDB.