Implemente um banco de dados de aplicativos externos multi-cluster

Você pode implantar um recurso do Ops Manager que usa um banco de dados de aplicativos externo de vários clusters: um recurso personalizado do MongoDBMultiCluster com spec.role definido como AppDB. Esse recurso distribui os membros do banco de dados de aplicativos em vários clusters do Kubernetes. Uma segunda instância do Ops Manager gerencia o recurso como um projeto, o que permite ao Ops Manager fazer backup e restaurar o banco de dados de aplicativos. Para saber mais, consulte Fazer backup do Ops Manager Application Database.

Este procedimento implanta uma nova instância do Ops Manager. Para converter uma instância existente do Ops Manager que usa um banco de dados de aplicativos de vários clusters gerenciado internamente, consulte Migrar um banco de dados de aplicativos de vários clusters. Para a variante de cluster único deste procedimento, consulte Implementar o Ops Manager com um banco de dados de aplicativo externo.

Este procedimento implanta os seguintes recursos:

Uma instância de gerenciamento do Ops Manager com seu próprio banco de dados de aplicativos gerenciado internamente, em execução no cluster central. Esta instância gerencia o projeto que contém o Banco de Dados de Aplicativo externo.
Um banco de dados de aplicativo externo: um conjunto de réplicas do MongoDBMultiCluster com spec.role definido como AppDB, chamado <primary-om-name>-db. O Operador Kubernetes cria um StatefulSet por cluster de membro, denominado <primary-om-name>-db-<cluster-index>.
Uma instância principal do Ops Manager que omite spec.applicationDatabase e faz referência ao banco de dados de aplicativo externo com spec.externalApplicationDatabaseRef definido como MongoDBMultiCluster.

Pré-requisitos

Antes de começar, conclua as seguintes tarefas:

Implemente três clusters Kubernetes, cada um com um StorageClass padrão: um cluster central e dois clusters de membros.
Implemente uma malha de serviços que abranja os clusters e forneça descoberta de serviços entre clusters. Os membros do Banco de Dados de Aplicativos se comunicam através de clusters sobre a malha.

Esse procedimento usa o Istipo, mas você pode usar qualquer interface de serviço que forneça resolução de nome de host FQDN entre Pods em clusters. Uma interface de serviço não é um requisito para o próprio banco de dados de aplicativos externo de vários clusters. Para obter um padrão de sistema sem rede, consulte Multi-Cluster Ops Manager sem rede de serviço.
Instale kubectl, helm e o plugin-inkubectl mongodb e configure-os para todos os três clusters.
Obtenha acesso ao gráfico Helm do Kubernetes operador.

Considerações

Revise as seguintes considerações antes de implementar:

Defina a versão do MongoDB Ops Manager e a versão do banco de dados de aplicativo como um par consistente. A instância do MongoDB Ops Manager de gerenciamento gerencia o banco de dados de aplicativo externo, portanto, a versão do banco de dados de aplicativo deve ser uma versão do MongoDB que a instância do MongoDB Ops Manager de gerenciamento ofereça em seu manifesto da versão. Por exemplo, uma 8.0.x instância do MongoDB Ops Manager oferece 8.0.x versões do MongoDB, mas uma 7.0.x A instância do MongoDB Ops Manager não. Para encontrar um par compatível, consulte a matriz de compatibilidade do banco de dados de aplicativo.
Um aplicativo de banco de dados externo de vários clusters exige criptografia TLS. Quando o Banco de Dados de Aplicativos usa TLS, o MongoDB Agent valida cada conexão HTTPS de saída em relação ao pacote CA em spec.security.tls.ca, incluindo o download do binário MongoDB de downloads.mongodb.com. O pacote de CA deve incluir as raizes públicas que assinam downloads.mongodb.com além da sua própria CA. Para configurar certificados TLS para um sistema de vários clusters, consulte Gerenciar certificados TLS.
O cluster central executa o Kubernetes Operator, ambas as instâncias do Ops Manager, e mantém o recurso MongoDBMultiCluster. Os clusters de membros executam os pods de dados do aplicativo de banco de dados.

Procedimento

Defina as variáveis de ambiente para a implantação.

export K8S_CTX_0="<central-cluster-context>"export K8S_CTX_1="<member-cluster-1-context>"export K8S_CTX_2="<member-cluster-2-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 APPDB_MEMBERS_C1=2export APPDB_MEMBERS_C2=2
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 CERT_MANAGER_NAMESPACE="cert-manager"export APPDB_TLS_SELF_SIGNED_ISSUER="mongodb-self-signed-issuer"export APPDB_TLS_CA_CERT_NAME="mongodb-ca"export APPDB_TLS_CA_SECRET_NAME="mongodb-ca-key-pair"export APPDB_TLS_CA_ISSUER="mongodb-ca-issuer"export APPDB_CERT_PREFIX="appdb"export APPDB_CA_CONFIGMAP="${APPDB_NAME}-ca"
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"

O operador do Kubernetes exige que o banco de dados de aplicativo externo seja nomeado como <primary-om-name>-db, e é por isso que APPDB_NAME deriva de PRIMARY_OM_NAME.

Crie o namespace em cada cluster.

O namespace deve existir no cluster central e em ambos os clusters de membros. O rótulo istio-injection=enabled adiciona um sidecar aos pods do aplicativo de banco de dados para que seus agentes possam resolver o serviço de gerenciamento do Ops Manager nos clusters.

for ctx in "${K8S_CTX_0}" "${K8S_CTX_1}" "${K8S_CTX_2}"; do  kubectl create namespace "${MDB_NS}" --context "${ctx}" --dry-run=client -o yaml \    | kubectl apply --context "${ctx}" -f -  kubectl label namespace "${MDB_NS}" istio-injection=enabled --overwrite --context "${ctx}"done

Instale o Kubernetes Operator no modo de vários clusters.

Configure contas de serviço e roles nos clusters com o plugin-inkubectl mongodb e, em seguida, instale o Operador Kubernetes no cluster central com os clusters de membros registrados. Para saber mais, consulte Pré-requisitos de implantação de vários clusters.

kubectl mongodb multicluster setup \  --central-cluster="${K8S_CTX_0}" \  --member-clusters="${K8S_CTX_0},${K8S_CTX_1},${K8S_CTX_2}" \  --member-cluster-namespace="${MDB_NS}" \  --central-cluster-namespace="${MDB_NS}" \  --create-service-account-secrets \  --install-database-roles=true
helm upgrade --install --kube-context "${K8S_CTX_0}" \  --create-namespace --namespace "${MDB_NS}" \  mongodb-kubernetes-operator-multi-cluster \  --set operator.name=mongodb-kubernetes-operator-multi-cluster \  --set operator.createOperatorServiceAccount=false \  --set operator.createResourcesServiceAccountsAndRoles=false \  --set "multiCluster.clusters={${K8S_CTX_0},${K8S_CTX_1},${K8S_CTX_2}}" \  "${OPERATOR_HELM_CHART}"
kubectl rollout status deployment/mongodb-kubernetes-operator-multi-cluster \  --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=300s

Criar o segredo de administrador do MongoDB Ops Manager.

Ambos os recursos do MongoDB Ops Manager referenciam este segredo com spec.adminCredentials.

kubectl create secret generic ops-manager-admin-secret \  --context "${K8S_CTX_0}" -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}"

Instale o cert-manager no cluster central.

Os membros do Banco de Dados de Aplicativo de vários clusters usam TLS, portanto, cert-manager deve emitir a CA e o certificado de servidor do Banco de Dados de Aplicativo.

helm upgrade --install --kube-context "${K8S_CTX_0}" \  cert-manager jetstack/cert-manager \  --namespace "${CERT_MANAGER_NAMESPACE}" --create-namespace \  --set crds.enabled=true

Configure o TLS CA.

Crie a cadeia de assinatura e, em seguida, publique a CA em um ConfigMap que o operador Kubernetes referencia como spec.security.tls.ca. O pacote combina sua CA autoassinada com o pacote de CA pública do host, porque o MongoDB Agent valida o download binário do MongoDB de downloads.mongodb.com em relação a esse pacote. O pacote combinado excede o limite de tamanho da anotação kubectl apply do lado do cliente , portanto, aplique o ConfigMap do lado do servidor.

kubectl apply --context "${K8S_CTX_0}" -f - <<EOFapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:  name: ${APPDB_TLS_SELF_SIGNED_ISSUER}spec:  selfSigned: {}EOF
kubectl apply --context "${K8S_CTX_0}" -n "${CERT_MANAGER_NAMESPACE}" -f - <<EOFapiVersion: cert-manager.io/v1kind: Certificatemetadata:  name: ${APPDB_TLS_CA_CERT_NAME}spec:  isCA: true  commonName: mongodb-ca  secretName: ${APPDB_TLS_CA_SECRET_NAME}  duration: 87600h  renewBefore: 8760h  privateKey:    algorithm: ECDSA    size: 256  issuerRef:    name: ${APPDB_TLS_SELF_SIGNED_ISSUER}    kind: ClusterIssuerEOF
kubectl wait --for=condition=Ready certificate/"${APPDB_TLS_CA_CERT_NAME}" \  -n "${CERT_MANAGER_NAMESPACE}" --context "${K8S_CTX_0}" --timeout=120s
kubectl apply --context "${K8S_CTX_0}" -f - <<EOFapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:  name: ${APPDB_TLS_CA_ISSUER}spec:  ca:    secretName: ${APPDB_TLS_CA_SECRET_NAME}EOF
ca_crt=$(kubectl get secret "${APPDB_TLS_CA_SECRET_NAME}" \  -n "${CERT_MANAGER_NAMESPACE}" --context "${K8S_CTX_0}" \  -o jsonpath='{.data.ca\.crt}' | base64 -d)
system_ca=""for candidate in /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/cert.pem; do  [[ -r "${candidate}" ]] && { system_ca=$(cat "${candidate}"); break; }done
ca_bundle_file=$(mktemp)printf '%s\n%s\n' "${ca_crt}" "${system_ca}" > "${ca_bundle_file}"
kubectl create configmap "${APPDB_CA_CONFIGMAP}" \  --context "${K8S_CTX_0}" -n "${MDB_NS}" \  --from-file=ca-pem="${ca_bundle_file}" \  --from-file=mms-ca.crt="${ca_bundle_file}" \  --dry-run=client -o yaml \  | kubectl apply --server-side --force-conflicts --context "${K8S_CTX_0}" -n "${MDB_NS}" -f -
rm -f "${ca_bundle_file}"

Gere o certificado do servidor do Banco de Dados do Aplicativo.

O nome secreto do certificado segue a convenção do Operador Kubernetes <certs-secret-prefix>-<appdb-name>-cert. A entrada curinga dnsNames abrange o serviço FQDN de cada membro do Banco de Dados de Aplicativos em cada cluster.

kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: cert-manager.io/v1kind: Certificatemetadata:  name: ${APPDB_CERT_PREFIX}-${APPDB_NAME}-certspec:  secretName: ${APPDB_CERT_PREFIX}-${APPDB_NAME}-cert  duration: 8760h  renewBefore: 720h  privateKey:    algorithm: RSA    size: 2048  usages: ["server auth", "client auth"]  dnsNames:    - "*.${MDB_NS}.svc.cluster.local"  issuerRef:    name: ${APPDB_TLS_CA_ISSUER}    kind: ClusterIssuerEOF
kubectl wait --for=condition=Ready certificate/"${APPDB_CERT_PREFIX}-${APPDB_NAME}-cert" \  -n "${MDB_NS}" --context "${K8S_CTX_0}" --timeout=120s

Implantar a instância do MongoDB Ops Manager de gerenciamento.

kubectl apply --context "${K8S_CTX_0}" -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

As configurações de e-mail mms.* são obrigatórias. Quando mms.ignoreInitialUiSetup é true, a verificação prévia do MongoDB Ops Manager não inicia o MongoDB Ops Manager, a menos que mms.fromEmailAddr e as configurações de e-mail relacionadas estejam presentes.

Aguarde até que a instância de gerenciamento do MongoDB Ops Manager esteja pronta.

Aguarde o banco de dados de aplicativo gerenciado internamente e o recurso do MongoDB Ops Manager:
```
kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \  om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1200s
kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \  om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1800s
```
Confirme se a API pública do MongoDB Ops Manager responde às solicitações. Um opsManager.phase de Running significa que o pod do MongoDB Ops Manager está ativo, mas a API que o operador do Kubernetes usa para criar o projeto do banco de dados de aplicativo pode atrasar alguns segundos. Uma resposta 401 é a resposta não autenticada esperada e significa que a API está pronta:
```
om_pod="${MANAGEMENT_OM_NAME}-0"until [ "$(kubectl exec "${om_pod}" -c mongodb-ops-manager --context "${K8S_CTX_0}" -n "${MDB_NS}" -- \  curl -s -o /dev/null -w '%{http_code}' \  "http://$(kubectl get pod "${om_pod}" --context "${K8S_CTX_0}" -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
```
Confirmar que o operador Kubernetes criou o segredo da chave de API programática para a instância de gerenciamento do MongoDB Ops Manager:
```
kubectl get secret "${MANAGEMENT_OM_ADMIN_KEY_SECRET}" \  --context "${K8S_CTX_0}" -n "${MDB_NS}"
```

Crie o ConfigMap do projeto para o banco de dados de aplicativo externo.

A entrada sslMMSCAConfigMap anuncia a CA em que os agentes do banco de dados de aplicativos habilitados para TLSdevem confiar quando se conectam à instância de gerenciamento do Ops Manager.

kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \  --context "${K8S_CTX_0}" -n "${MDB_NS}" \  --from-literal=baseUrl="${MANAGEMENT_OM_URL}" \  --from-literal=projectName="${APPDB_PROJECT_NAME}" \  --from-literal=sslMMSCAConfigMap="${APPDB_CA_CONFIGMAP}" \  --from-literal=orgId="" \  --dry-run=client -o yaml \  | kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f -

Crie o banco de dados de aplicativo externo.

Aplique o recurso MongoDBMultiCluster no cluster central. O Operador Kubernetes cria os nós do banco de dados de aplicativos nos clusters de membros.

kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata:  name: ${APPDB_NAME}spec:  version: ${APPDB_VERSION}  type: ReplicaSet  role: AppDB  persistent: true  credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET}  opsManager:    configMapRef:      name: ${APPDB_PROJECT_CONFIGMAP}  security:    certsSecretPrefix: ${APPDB_CERT_PREFIX}    tls:      enabled: true      ca: ${APPDB_CA_CONFIGMAP}  clusterSpecList:    - clusterName: ${K8S_CTX_1}      members: ${APPDB_MEMBERS_C1}    - clusterName: ${K8S_CTX_2}      members: ${APPDB_MEMBERS_C2}EOF
kubectl wait --for=jsonpath='{.status.phase}'=Running \  mdbmc/"${APPDB_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1200s

Quando você define spec.role como AppDB, o Operador Kubernetes configura a autenticação SCRAM para o recurso. Para saber mais, consulte spec.role.

Implantar a instância primária do MongoDB Ops Manager.

Este recurso omite spec.applicationDatabase e faz referência ao banco de dados do aplicativo externo com kind definido como MongoDBMultiCluster.

kubectl apply --context "${K8S_CTX_0}" -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: MongoDBMultiCluster  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 o backup para suas implantações do MongoDB, defina spec.backup.enabled como true neste recurso e configure o armazenamento de snapshot. Para aprender mais, consulte Configurar armazenar de backup do sistema de arquivos com o Kubernetes operador.

Aguarde a instância primária do Ops Manager ficar pronta.

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

O operador Kubernetes não gerencia um banco de dados de aplicativo interno para um recurso do MongoDB Ops Manager que usa um banco de dados de aplicativo externo, portanto, status.applicationDatabase.phase relata Disabled. Isso é esperado e não é um erro.

Verifique a implantação.

Em uma implantação de vários clusters, o banco de dados de aplicativos StatefulSets é executado nos clusters de membros e o Operador Kubernetes rastreia sua propriedade com o rótulo mongodbmulticluster em vez de uma referência de proprietário.

Confirme que os pods do Banco de Dados de Aplicativo estão em execução em cada cluster de membro e que cada StatefulSet carrega o rótulo mongodbmulticluster definido como <namespace>-<appdb-name>:
```
idx=0for ctx in "${K8S_CTX_1}" "${K8S_CTX_2}"; do  sts="${APPDB_NAME}-${idx}"  kubectl get pods --context "${ctx}" -n "${MDB_NS}" \    -l "mongodbmulticluster=${MDB_NS}-${APPDB_NAME}"  kubectl get statefulset "${sts}" --context "${ctx}" -n "${MDB_NS}" \    -o jsonpath='{.metadata.labels.mongodbmulticluster}{"\n"}'  idx=$((idx + 1))done
```
Confirme que o operador Kubernetes criou o segredo da string de conexão para a instância primária do MongoDB Ops Manager:
```
kubectl get secret "${APPDB_CONNECTION_STRING_SECRET}" \  --context "${K8S_CTX_0}" -n "${MDB_NS}"
```

Problemas comuns de banco de dados de aplicativo externo

Os agentes do banco de dados do aplicativo falham no download do binário

Se os agentes do Banco de Dados de Aplicativos não conseguirem baixar o binário MongoDB com x509: certificate signed by unknown authority, o pacote CA no spec.security.tls.ca não incluirá as raizes públicas que assinam downloads.mongodb.com. Com o TLS habilitado, o MongoDB Agent valida o download em relação a esse pacote em vez do armazenamento de confiança do sistema. Recrie o ConfigMap com seu pacote de CA autoassinado e o pacote de CA público do host, como mostra a etapa de CA do TLS.

Os pods do banco de dados de aplicativos não conseguem resolver o gerente de operações

Se os agentes do banco de dados de aplicativos registrarem Could not resolve host para o serviço do Ops Manager de gerenciamento, o namespace do member-cluster não terá o rótulo istio-injection=enabled. Sem o sidecar, os pods não podem resolver o serviço do Ops Manager do cluster central pela malha. Aplique o rótulo como mostra a etapa do namespace .

O CA ConfigMap é rejeitado por ser muito longo

Se o Kubernetes rejeitar o CA ConfigMap com metadata.annotations: Too long, o pacote CA combinado excederá o limite de tamanho da anotação kubectl apply do lado do cliente . Aplique o ConfigMap com kubectl apply --server-side --force-conflicts ou crie-o com kubectl create.

O recurso MongoDBMultiCluster relata um erro de versão

Se o banco de dados de aplicativos externo relatar Failed com uma mensagem de que a versão do MongoDB não está disponível, defina spec.version como uma versão que a instância do Ops Manager de gerenciamento ofereça. Mantenha a versão do Ops Manager e a versão do banco de dados de aplicativos na mesma versão principal.

O operador rejeita a Referência externa do banco de dados de aplicativo

O valor de spec.externalApplicationDatabaseRef.name deve ser exatamente <primary-om-name>-db e o recurso MongoDBMultiCluster deve estar no mesmo namespace que o recurso Ops Manager.

Próximos passos

Para fazer backup do Banco de Dados de Aplicativo externo, habilite o backup no recurso MongoDBMultiCluster no projeto que a instância de gerenciamento do Ops Manager gerencia. Para saber mais, consulte Configurar backups do banco de dados MongoDB .

Início rápido