外部のアプリケーション データベースを使用する MongoDBspec.role AppDBカスタムリソースを配置できます。これは、 が に設定されているMongoDBカスタムリソースであり、2 つ目の Ops Managerインスタンスがプロジェクトとして管理します。これにより、Ops Manager はアプリケーション データベースをバックアップして復元できるようになります。詳細については、「 Ops Manager Application Database のバックアップ 」を参照してください。
この手順では、新しい Ops Managerインスタンスを配置します。内部で管理されるアプリケーション データベースを使用する既存の Ops Managerインスタンスを変換するには、「 アプリケーション データベースの外部配置への移行 」を参照してください。
この手順では、次のリソースを配置します。
独自の内部管理型アプリケーションデータベースを持つマネジメント Ops Managerインスタンス。このインスタンスは、外部アプリケーション データベースを含むプロジェクトを管理します。
外部アプリケーション データベース:
spec.roleがAppDBに設定されているMongoDBレプリカセット(<primary-om-name>-dbという名前)。spec.externalApplicationDatabaseRefを省略し、 を持つ外部アプリケーション データベースを参照するspec.applicationDatabaseMongoDB Ops Manager のプライマリインスタンス。
前提条件
始める前に、次のタスクを完了してください。
デフォルトの
StorageClassを使用してKubernetesクラスターを配置します。kubectlとhelmをインストールし、そのクラスターに合わせて構成します。Kubernetes Operator Helmチャートへのアクセスを取得します。
Considerations
Ops Manager バージョンとアプリケーションデータベースバージョンをコンシステントペアに設定します。マネジメントの Ops Managerインスタンスは外部の アプリケーション データベース を管理するため、アプリケーション8.0 8.0データベースのバージョンは、マネジメントの Ops Managerインスタンスがバージョンマニフェストで提供するMongoDBバージョンである必要があります。例、.x Ops7.0 Managerインスタンスでは.x MongoDBバージョンが提供されていますが、.x Ops Managerインスタンスでは提供されていません。
手順
配置用の環境変数を設定します。
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"
Kubernetes演算子では、外部アプリケーション データベースの名前が <primary-om-name>-db である必要があります。そのため、APPDB_NAME は PRIMARY_OM_NAME から派生します。
MongoDB Ops Manager 管理シークレットを作成します。
どちらの MongoDB Ops Manager リソースも、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}"
Ops Manager のマネジメントインスタンスを配置します。
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
mms.* メール設定が必要です。 mms.ignoreInitialUiSetup が true の場合、MongoDB Ops Manager の事前チェックでは、mms.fromEmailAddr と関連するメール設定が存在しない限り、MongoDB Ops Manager は起動しません。
Ops Manager のマネジメントインスタンスが準備完了するまで待ちます。
内部管理型アプリケーション データベースと 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 Ops
opsManager.phaseRunningManager 公開API がリクエストに応答することを確認します。 の401は Ops Manager ポッドが起動していることを意味しますが、 Kubernetes Operator が Application Databaseプロジェクトを作成するために使用するAPI は数秒遅延する可能性があります。 応答は予想される未認証の応答であり、 API が準備できていることを意味します。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 Kubernetes Operator が MongoDB Ops ManagerインスタンスのプログラムAPIキー シークレットを作成したことを確認します。
kubectl get secret "${MANAGEMENT_OM_ADMIN_KEY_SECRET}" \ --context "${K8S_CTX}" -n "${MDB_NS}"
外部アプリケーション データベースを作成します。
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
spec.role を AppDB に設定すると、 Kubernetes Operator はリソースの SCRAM認証を構成します。詳しくは spec.role を参照してください。
プライマリ Ops Managerインスタンスを配置します。
このリソースは を省略し、代わりに外部のアプリケーションspec.applicationDatabase データベースを参照します。
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
MongoDB配置のバックアップを有効にするには、このリソースで をspec.backup.enabled に設定し、true スナップショットストレージを構成します。詳しくは、 「 Kubernetes Operator を使用したファイル システム バックアップ ストアの構成 」を参照してください。
Ops Manager のプライマリインスタンスが準備完了するまで待ちます。
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
Kubernetes Operator は、外部アプリケーション データベースを使用する Ops Managerリソースの内部アプリケーション データベースを管理しないため、status.applicationDatabase.phase は Disabled を報告します。これは予想されており、エラーではありません。
配置を確認します。
マネジメント Ops Manager ポッド、外部アプリケーション データベース ポッド、およびプライマリ Ops Manager ポッドが を実行中いることを確認します。
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}" MongoDBリソースがアプリケーション データベース ステートメントセットを所有しており、プライマリ Ops Managerリソースが所有していないことを確認します。
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}' このコマンドは
MongoDB/${APPDB_NAME}を返します。Kubernetes Operator が プライマリ Ops Managerインスタンスの接続文字列シークレットを作成したことを確認します。
kubectl get secret "${APPDB_CONNECTION_STRING_SECRET}" \ --context "${K8S_CTX}" -n "${MDB_NS}"
一般的な外部アプリケーション データベースの問題
MongoDBリソースがバージョン エラーを報告する
外部アプリケーションFailed データベースがMongoDBバージョンが利用できないというメッセージを含む を報告する場合は、管理用spec.version Ops Managerインスタンスが提供するバージョンに を設定します。 Ops Manager バージョンとアプリケーションデータベースバージョンは同じメジャー バージョンに保持します。 MongoDB Ops Manager インスタンス独自の内部管理アプリケーション データベースは影響を受けません。これは、 をautomation.versions.source mongodbに設定するとバイナリを直接ダウンロードするためです。
外部アプリケーション データベースは保留中のまま
外部アプリケーション データベースがPending フェーズに留まり、 MongoDB Agent がオートメーション構成を受信しない場合は、管理 Ops Manager 公開APIがリクエストを処理する前にMongoDBリソースが作成されている可能性があります。 Kubernetes Operator はプロジェクトを作成できませんでした。 API準備完了チェックで 401が返されることを確認し、リソースを再度調整します。
演算子が外部アプリケーション データベース参照を拒否
の値は正確にspec.externalApplicationDatabaseRef.name <primary-om-name>-dbであり、 MongoDBリソースはMongoDB Ops Managerリソースと同じ名前空間内になければなりません。
次のステップ
外部アプリケーション データベースをバックアップするには、マネジメント Ops Managerインスタンスが管理するプロジェクト内のMongoDBリソースのバックアップを有効にします。詳細については、 「 MongoDB database のバックアップの構成 」を参照してください。