AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
Docs Home
Docs Home

MongoDB Ops Managerのリソースを計画する

MongoDB MongoDB Ops Manager は、 MongoDB の配置を管理、バックアップ、モニターするエンタープライズアプリケーションです。MongoDB Ops Managerを使用すると、 MongoDB の増やすとアップグレード、クエリの最適化、ポイントインタイム復元の実行、パフォーマンス アラートの受信、配置のモニターが可能です。 MongoDB Ops Managerとその基礎となるデータベース を管理および維持するには、 Kubernetes Operator 用のMongoDBコントロール を使用して、 MongoDB Ops Manager をKubernetesのコンテナに配置されたリソースとして実行できます。

MongoDB Ops Managerのリソースは、次のいずれかの方法で配置できます。

  • 単一 Kubernetes クラスター モード。 MongoDB Ops ManagerKubernetes単一のMongoDB インスタンスを配置して、 リソースの単一の クラスター配置をサポートできます。

  • 〈strong〉複数のKubernetesクラスターモード〈/strong〉。複数のKubernetesクラスターに複数のMongoDB Ops Managerインスタンスとアプリケーションデータベースインスタンスを配置できます。このモードでは、MongoDB Ops Managerリソースのマルチクラスターは、複数のKubernetesクラスターでのMongoDB Ops Managerアプリケーションとアプリケーションデータベースの配置をサポートします。

MongoDB Ops Manager単一または複数の Kubernetes クラスターにリソースを配置する前に、「MongoDB Ops Manager リソースアーキテクチャ」と「考慮事項を確認し、前提条件を完了してください。

アーキテクチャ

MongoDB Ops Managerリソース アーキテクチャの詳細については、以下を参照してください。

MongoDBOpsManagerカスタム リソース定義

The Kubernetes Operator は、リソースを配置する各Kubernetesクラスターの MongoDBOpsManager カスタムリソース を使用して、MongoDB Ops Manager の配置を管理します。Kubernetes演算子 は、リソースの仕様の変更を監視します。仕様が変更されると、 Kubernetes Operator は変更を検証し、 MongoDB Ops Managerコンポーネントを配置する各Kubernetesクラスターのリソースに適切な更新を行います。

MongoDBOpsManager カスタムリソースの仕様では、次のMongoDB Ops Managerコンポーネントが定義されます。

  • アプリケーション データベース

  • MongoDB Ops Managerアプリケーション

  • バックアップデーモン

以下の図では、 MongoDB Ops Managerの配置に関連するコンポーネントが説明されています。

  • 単一クラスター配置では、Kubernetes Operator がインストールされるのと同じ Kubernetes クラスターにこれらのコンポーネントを配置します。 このクラスターは「演算子クラスター」と呼ばれます。

  • マルチクラスター配置では、次の操作を行います。

MongoDB Enterprise Kubernetes Operator（単一の Kubernetes クラスター）の高レベルのアーキテクチャを示す図

MongoDB Ops Manager リソースのアプリケーション データベース

アプリケーション データベースの場合、 Kubernetes Operator はMongoDBレプリカセットをステートフルセットとして配置します。

アプリケーション データベースの各ポッドには、次のコンテナがあります。

  • mongod.

  • MongoDB Agent 。 MongoDB Agent のバージョンを上書きするには、 $AGENT_IMAGE環境変数または Kubernetes Operator のインストールに使用する Helm チャートのagent.versionを使用します。

  • モニタリングエージェント。 モニタリングエージェントのバージョンを上書きすることはできません。 Kubernetes Operator が使用するバージョンは、 MongoDB Ops Managerバージョンとの下位互換性を確保します。

    モニタリングエージェントのバージョンを表示するには、以下を行います。

    • Kubernetes Operator の ポッド または Kubernetes Operator の イメージ内の/usr/local/om_version_mapping.jsonを調べます。

    • アプリケーション データベースを配置するポッドで、モニタリングエージェントのコンテナのイメージを確認します。

マルチクラスター配置（ spec.applicationDatabase.topologyをMultiClusterに設定している場合）、Kubernetes Operator は、 spec.applicationDatabase.clusterSpecListのアプリケーション データベースに指定された各 Kubernetes クラスターにステートフルセットを作成します。

次のアクションは、アプリケーション データベースの MongoDB レプリカセット ノードをホストしている各ノードの Kubernetes クラスターで実行されます。

  • Kubernetes は、アプリケーション データベース レプリカセットを構成する各ノードに対して ステートメントを使用して 1 つのポッドを作成します。 ステートメントセット内の各ポッドは mongod とMongoDB Agentを実行します。

    各MongoDBエージェントがステートメントセット内のポッドでmongodを起動できるようにするには、spec.applicationDatabase.version設定を使用してアプリケーション データベース用に特定のMongoDB Serverバージョンを指定する必要があります。この設定で指定するバージョンは、コンテナレジストリ。のタグに対応している必要があります。

  • 各 MongoDB Agent は、アプリケーション データベース ポッドでmongodを開始します。 MongoDB Agent によるアプリケーション データベース レプリカセットへのmongodプロセスの追加

    アプリケーション データベースレプリカセットのレプリカ数とその他の構成オプションは、spec.applicationDatabase カスタムリソースのMongoDBOpsManager コレクションで構成します。Kubernetes Operatorは、アプリケーション データベース ステートメント セット内の各ポッドにマウントされるシークレットを使用して、この構成をMongoDB Agent の に渡します。

    マルチクラスターのアプリケーション データベースの配置（ spec.applicationDatabase.topologyがMultiClusterに設定されている場合）では、 spec.applicationDatabase.clusterSpecListの各ノードクラスターに対して各ノードクラスター内のノード数を個別に指定します。 マルチクラスター配置では、 spec.applicationDatabaseのreplicas設定は無視されます。

  • spec.applicationDatabaseコレクションを更新するたびに、Kubernetes Operator は MongoDB Agent の構成と Atlas Triggers 仕様に変更を適用します（該当する場合）。 ステートフルセットの仕様が変更された場合、Kubernetes はポッドを段階的にアップグレードし、各ポッドを再起動します。

  • アプリケーションデータベースをホストしている各Kubernetesクラスター内から各アプリケーションデータベースポッドへの接続を提供するため、Kubernetes演算子はヘッドレス サービス を作成します。アプリケーションデータベースのマルチクラスター配置では、Kubernetes演算子は、という名前のポッドごとに 1<om_resource_name>-db-N-svc つのサービスも作成し（これはmetadata.name に対応します）、特に は<om_resource_name>-db-0.<namespace>.svc.cluster.local mongod。

  • StorageClass またはKubernetes Operator を配置する環境によっては、 Kubernetes が動的ボリュームプロビジョニングを使用して永続ボリュームを作成する場合があります。

    またはspec.applicationDatabase.podSpec.persistence.single を使用して、アプリケーション データベース ポッドの 永続ボリューム要求spec.applicationDatabase.podSpec.persistence.multiple をカスタマイズできます。

アプリケーション データベースのトポロジー

プライマリを選択するには、アプリケーション データベースのレプリカセットのノードの過半数が利用可能である必要があります。 レプリカセットのノードの過半数が失敗した場合、レプリカセットはプライマリ ノードを選出するための投票過半数を形成できません。 詳細については、「レプリカセットの配置アーキテクチャ 」を参照してください。

可能であれば、奇数のメンバー Kubernetes クラスターを使用し、 アプリケーションデータベース ノードをデータセンター、ゾーン、または Kubernetes クラスターに分散します。 詳しくは、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。

アプリケーション データベースのトポロジーの次の例について考えてみましょう。

5 つのノードからなるアプリケーションデータベースの場合、ノードの分布には次のようなものがあります。

  • 2 つのクラスター: 3 つのノードからCluster 1への 2 つのノードで、 Cluster 2への 2 つのノード。

    • Cluster 2が失敗した場合、 Cluster 1はプライマリ ノードを選択するのに十分な数のアプリケーション データベースのレプリカセット メンバーをホストします。

    • Cluster 1が失敗した場合、 Cluster 2にはプライマリ ノードを選択するのに十分なアプリケーション データベースのメンバーがありません。

  • 3 つのクラスター: Cluster 1に 2 つのノード、 Cluster 2に 2 つのノード、 Cluster 3に 1 つのノード。

    • いずれかのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なメンバーが存在します。

    • 2 つのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なノードがありません。

7 つのノードからなるアプリケーション データベースの場合、次のノードの分布を考慮してください。

  • 2 つのクラスター: 4 つのノードからCluster 1への 3 つのノード、 Cluster 2への 3 つのノード。

    • Cluster 2が失敗した場合、 Cluster 1にはプライマリ ノードを選択するのに十分なメンバーが存在します。

    • Cluster 1が失敗した場合、プライマリ ノードを選択するのに十分なメンバーがCluster 2に存在しません。

Cluster 2はアプリケーション データベースの最小ノード 3 つを満たしていますが、アプリケーション データベースの 7 つのノードの過半数がプライマリ ノードの選択に使用できる必要があります。

詳細については、「 MongoDB Ops Managerと AppDB リソースの障害復旧 」を参照してください。

MongoDB Ops Managerアプリケーション サーバー

アプリケーション データベースが実行状態に達すると、 Kubernetes Operator によってMongoDB Ops Managerアプリケーションの配置が開始されます。

  • これにより、Kubernetes クラスターの各ノードに ステートメントが構成されます。

  • 配置するMongoDB Ops Managerレプリカセットごとに、 Kubernetesはステートフルセットに 1 つのポッドを作成します。

  • 各ポッドには 1 つのMongoDB Ops Managerアプリケーション プロセスが含まれています。

MongoDB Ops Managerの単一クラスターの配置を単一の ポッド障害に対して回復性のあるものにするには、 を使用してMongoDB Ops Manager spec.replicasアプリケーションをホストするレプリカの数を増やします。

マルチクラスターのMongoDB Ops Manager 配置をデータセンターまたはゾーン全体の障害に対して回復性のあるものにするには、MongoDB Ops Manager と を に設定して アプリケーションを複数のKubernetes spec.topologyspec.applicationDatabase.topologyMultiClusterクラスターに配置します。「 MongoDB Ops Managerと AppDB リソースの障害復旧 」も参照してください。

MongoDB Ops Manager リソースのバックアップデーモン

がspec.backup.enabled true の場合、各ノードのKubernetes クラスターでは、Kubernetes アプリケーションがMongoDB Ops Manager 実行中 のステージに達した後に Operator はバックアップデーモンを起動します。バックアップデーモンの場合、Kubernetes Operator はステートフルセットを各ノードの Kubernetes クラスターにデプロイします。 各ノード クラスターに、Kubernetes はspec.backup.membersで指定された数のバックアップ デーモン ポッドを Atlas App Services に作成します。 単一クラスター配置では、これらのアクションはKubernetes Operator のインストールとMongoDB Ops Managerコンポーネントの配置に使用するオペレータークラスターで行われます。

バックアップを有効にする場合は、Kubernetes ノードごとではなく、グローバル レベルで oplog ストア 、 ブロックストア 、または S3 スナップショット ストア を構成します。spec.backup

バックアップジョブを暗号化 することもできますが、同じ Kubernetes Operator インスタンスが MongoDPOsManager と MongoDB カスタム リソースの両方を管理していない配置には 制限が 適用されます。

バックアップを有効にすると、 Kubernetes Operator は、各ノードのKubernetesクラスター上のバックアップデーモンのヘッドデータベース用の永続ボリューム要求を作成します。spec.backup.headDB 設定を使用してヘッドデータベースを構成できます。

Kubernetes Operator はMongoDB Ops Manager API を呼び出して、 MongoDB Ops Managerアプリケーションのバックアップ構成が、各ノードのKubernetesクラスターのカスタム リソース定義で定義したバックアップ構成と一致することを確認します。

Considerations

暗号化のキー

Kubernetes Operator は、MongoDB Ops Manager Application Database 内の機密情報を保護するための暗号化のキーを生成します。Kubernetes Operator は、このキーをMongoDB Ops Managerリソースと同じ名前空間内のシークレットに保存します。Kubernetes Operator はシークレットに <om-resource-name>-gen-key という名前を付けます。

注意

Kubernetes の単一クラスター配置でシークレットが保存されないようにするには、 すべてのシークレットをシークレットストレージツールに移行 します。複数のKubernetesクラスターでの配置では、HashiCorp Vault などのシークレットストレージツールへのシークレットの保存はサポートされていません。

MongoDB Ops Managerリソースを削除しても、キーはKubernetesクラスターの シークレット に保存されたままになります。 アプリケーション データベースを永続ボリュームに保存し、同じ名前で別のMongoDB Ops Managerリソースを作成すると、 Kubernetes Operator はシークレットを再利用します。別の名前でMongoDB Ops Managerリソースを作成すると、 Kubernetes Operator によって新しいシークレットとアプリケーション データベースが作成され、古いシークレットは再利用されません。

アプリケーション データベース

トポロジー

モニタリング

Kubernetes Operator は、 MongoDB Ops Managerアプリケーションをサポートするアプリケーションデータベースを監視するようにMongoDB Ops Managerを自動的に構成します。 Kubernetes Operator は、アプリケーション データベースの配置を監視するための<ops-manager-deployment-name>-dbという名前のプロジェクトを作成します。

MongoDB Ops Managerはアプリケーション データベースの配置を監視しますが、 MongoDB Ops Managerはそれを管理しません。 MongoDB Ops Manager Application では、アプリケーション データベースの構成を変更できません。

重要

<ops-manager-deployment-name>-dbプロジェクトで、アプリケーション データベースのエージェントが古くなっていることを示す警告が MongoDB Ops Manager UI に表示される場合がある。 これらの警告を無視しても問題ありません。

認証

Kubernetes Operator は、アプリケーション データベースに対してSCRAM-SHA-256認証を強制します。

Kubernetes Operator は、 MongoDB Ops Managerがアプリケーションデータベースに接続するために使用するデータベースユーザーを作成します。 このデータベースユーザーには次の属性があります。

ユーザー名

mongodb-ops-manager

認証データベース

admin

ロール

MongoDB Ops Manager データベースユーザーの名前とロールを変更することはできません。 データベースユーザーのパスワードを設定するためのシークレットを作成します。 シークレットを編集してパスワードを更新します。 シークレットを作成したり、既存のシークレットを削除したりしない場合、Kubernetes Operator はパスワードを生成し、それを保存します。

シークレットストレージのその他のオプションについては、シークレット ストレージの構成を参照してください。マルチクラスター配置では、HashiCorp Vaultでのシークレットの保存はサポートされていません。

オフライン配置

KubernetesOperator では、オフライン配置を含むMongoDB Enterprise リソースの任意の配置を有効にするには、 アプリケーション データベース イメージに バージョンMongoDB Ops Manager を指定する必要があります。

効率化された構成

MongoDB Ops Managerを配置した後、それを構成する必要があります。 通常の手順では、MongoDB Ops Manager 構成ウィザード を使用して を設定します。配置する前にオブジェクト仕様にいくつかの重要な設定を設定すると、構成ウィザードをバイパスできます。

spec.configurationMongoDB Ops Managerオブジェクト仕様の ブロックでは、次の操作を行う必要があります。

例

MongoDB Ops Manager構成ウィザードを無効にするには、 spec.configurationブロックで次の設定を構成します。

1spec:
2  configuration:
3    mms.ignoreInitialUiSetup: "true"
4    automation.versions.source: "remote"
5    mms.adminEmailAddr: cloud-manager-support@mongodb.com
6    mms.fromEmailAddr: cloud-manager-support@mongodb.com
7    mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8    mms.mail.port: "465"
9    mms.mail.ssl: "true"
10    mms.mail.transport: smtp
11    mms.minimumTLSVersion: TLSv1.2
12    mms.replyToEmailAddr: cloud-manager-support@mongodb.com

サンプル値を、MongoDB Ops Manager で使用する値に置き換えます。

バックアップ

Kubernetes Operator はデフォルトでバックアップを有効にします。Kubernetes Operator は、1 つの ポッドで構成される StateulSet を配置してバックアップデーモンサービスをホストし、バックアップデーモンのヘッドデータベース用の 永続ボリューム要求 と 永続ボリュームを作成します。Kubernetes Operator は、MongoDB Ops Manager APIを使用してバックアップデーモンを有効にし、ヘッドデータベースを構成します。

重要

バックアップを構成するには、oplog ストアと次のいずれかに対して MongoDB リソースまたは MongoDBMultiCluster リソースを作成する必要があります。

これらのバックアップ リソースを構成するまで、 MongoDB Ops Managerリソースは Pending 状態のままになります。

バックアップジョブを暗号化 することもできますが、同じ Kubernetes Operator インスタンスが MongoDPOsManager と MongoDB カスタム リソースの両方を管理していない配置には 制限が 適用されます。

oplogストア

oplog スライスを保存するには、3 つのノードのレプリカセットを配置する必要があります。

oplogデータベースは SCRAM 認証メカニズムのみをサポートしています。 他の認証メカニズムを有効にすることはできません。

oplog データベースでSCRAM認証を有効にする場合は、次の操作を行う必要があります。

  • MongoDBMongoDB Ops Managerをoplog データベースに接続するための ユーザー リソースを作成します。

  • nameのリソース定義でユーザーのMongoDB Ops Manager を指定します。

S3 oplogストア

S3oplog ストアを構成するには、データベースバックアップAmazon Web Services を保存するための S3 または S3 と互換性のあるバケットを作成する必要があります。oplog

MongoDB Ops Managerのリソース定義で spec.backup.s3OpLogStores.mongodbResourceRef.name 設定を使用して、MongoDB リソースと MongoDBMultiCluster リソースの両方に oplog ストアを構成できます。

Blockstore

ブロックストアを構成するには、スナップショットを保存するためのレプリカセットを配置する必要があります。

S3 Snapshot Store

S3スナップショットストアを設定するには、データベースバックアップ スナップショットを保存するためのAmazon Web Services S3またはS3 と互換性のあるバケットを作成する必要があります。

デフォルト構成では、スナップショットのメタデータは アプリケーション データベース に保存されます。 また、レプリカセットを配置してスナップショット メタデータを保存し、spec.backup.s3Stores.mongodbResourceRef.name MongoDB Ops Managerのリソース定義で 設定を使用して構成することもできます。

MongoDB リソースと MongoDBMultiCluster リソースの両方でS3スナップショット ストアを構成できます。

Operator が管理しない追加の S3 構成設定 KubernetesMongoDB Ops Managerは、 アプリケーションを通じて更新できます。

バックアップの無効化

バックアップを有効にした後に無効にするには、以下の手順を行います。

  1. MongoDB Ops Manager Kubernetesオブジェクト spec.backup.enabled の設定を false に設定します。

  2. アプリケーションでの バックアップを無効 にします。MongoDB Ops Manager

  3. バックアップデーモンのサービス ステートメントセットを削除します。

    kubectl delete statefulset <metadata.name> -backup-daemon \
     -n <metadata.namespace>

重要

バックアップデーモンのヘッドデータベースの 永続的ボリューム要求 と 永続的ボリュームは 、バックアップデーモンサービスのステートメントを削除しても削除されません。これらのKubernetesリソースを削除する前に、保存されたデータを検索できます。

永続ボリューム の再利用の詳細については、 Kubernetesドキュメント を参照してください。

KMIP バックアップの暗号化の手動設定

同じKubernetes Operator インスタンスが MongoDBOpsManager と カスタムMongoDB リソースの両方を管理して いないMongoDB Ops Manager 配置の場合は、次の手順を使用して で KMIP バックアップ暗号化クライアント設定を手動で構成する必要があります。Kubernetes Operatorが両方のリソースを管理している場合は、代わりに「 MongoDB Ops Managerの KMIP バックアップ暗号化の構成 」を参照してください。

前提条件
手順

  1. TLSシークレットをMongoDBOpsManagerカスタム リソースにマウントします。 例:

    apiVersion: mongodb.com/v1
    kind: MongoDBOpsManager
    metadata:
      name: ops-manager-pod-spec
    spec:
      < ... omitted ... >
      statefulSet:
        spec:
          template:
            spec:
              volumes:
              - name: kmip-client-test-prefix-mdb-latest-kmip-client
                secretName: test-prefix-mdb-latest-kmip-client
              containers:
                - name: mongodb-ops-manager
                  volumeMounts:
                  - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client
                    name: kmip-client-test-prefix-mdb-latest-kmip-client
                    readOnly: true
      ...

  2. 「 KMIP を使用するようにプロジェクトを構成する 」の手順に従って、 でプロジェクトの KMIP 設定を構成します 。MongoDB Ops Manager

HTTPS 経由で実行するようにMongoDB Ops Managerを構成する

Operator MongoDB Ops Managerを通じて作成されたKubernetes インスタンスは、 ではなく HTTPHTTPS 経由 で実行するように構成できます。

MongoDB Ops Manager インスタンスをHTTPS 経由で実行するように構成するには、次の手順に従います。

  1. TLS証明書と秘密キーを含むシークレットを作成します。

  2. このシークレットを MongoDB Ops Manager 構成オブジェクト に追加します。

詳細な手順については、「 MongoDB Ops Managerリソースの配置 」を参照してください。

重要

既存の配置がある場合は、 HTTPSを有効にした後、それらを手動で再起動する必要があります。 配置が再起動しないようにするには、管理対象リソースを配置する前にHTTPSを構成します。

詳細については、「配置後のHTTPSの有効化」を参照してください。

MongoDB Ops Manager Application Access

デフォルトでは、Kubernetes OperatorKubernetes は、Kubernetes クラスターの外部から発生したトラフィックをMongoDB Ops Manager アプリケーションにルーティングする サービスを作成しません。

MongoDB Ops Managerアプリケーションにアクセスするには、次の方法を実行します。

  • Kubernetes Operator を構成して Kubernetes サービスを作成します。

  • Kubernetes サービスを手動で作成します。 MongoDB では、クラウドプロバイダーがサポートしている場合、 LoadBalancer Kubernetes サービスを使用することを推奨します。

  • OpenShiftを使用している場合は、 ルートを使用します。

  • Istio などのサードパーティ サービスを使用します。

最も単純な方法は、外部トラフィックをMongoDB Ops ManagerアプリケーションにルーティングするKubernetesサービスを作成するようにKubernetes Operator を構成することです。 MongoDB Ops Manager の配置手順では、 Kubernetes Operator がサービスを作成するように構成するオブジェクト仕様に次の設定を追加するよう指示します。

さらに、複数の Kubernetes クラスターにおける配置については、「複数のクラスターアーキテクチャ」を参照してください。

リモート モードまたはローカル モードでのMongoDB Ops Managerの配置

Kubernetes Operator を使用して、単一のMongoDB Ops Managerクラスターをローカルモードまたはリモートモードで動作するようにKubernetesできます。 これらのモードでは、バックアップデーモンと管理対象のMongoDBリソースは、インターネットからではなくMongoDB Ops Managerからインストール アーカイブをダウンロードします。

外部 MongoDB 配置の管理

Operator を使用してMongoDB Ops Manager を配置すると、KubernetesMongoDB Ops Manager は配置されたMongoDB データベース リソースを管理できます。

  • Kubernetesと同じMongoDB Ops Manager クラスターへの接続。

  • Kubernetes クラスターの外部。

が、MongoDB Ops Manager ManagerMongoDB とは異なる クラスター、または クラスターの外部に配置された データベースKubernetes MongoDB Ops ManagerKubernetesリソースを管理する場合は、次を行う必要があります。

  1. MongoDB Ops Managerリソース仕様で mms.centralUrl 設定を spec.configuration に追加します。

    URLMongoDB Ops ManagerがKubernetes クラスターの外部で公開される に値を設定します。

    spec:
      configuration:
        mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/

  2. Kubernetes Operator を使用して配置した Kubernetes クラスター内のすべての MongoDB database リソースが参照するConfigMaps を更新します。

    リソース仕様の data.baseUrl設定と同じ値にspec.configuration.mms.centralUrl を設定します。MongoDB Ops Manager

    重要

    これには、 oplog およびスナップショット ストア用の MongoDB データベース リソースが参照する ConfigMaps が含まれます。

マルチクラスターでのMongoDB Ops Managerの配置

「マルチクラスターアーキテクチャ」を参照してください。

シークレット ストレージ

Kubernetesにシークレットを保存しないでください。Kubernetes Operatorが作成するすべてのKubernetesシークレットをシークレットストレージツールに移行します。マルチクラスター配置では、HashiCorp Vault などのシークレットストレージツールにシークレットを保存することはできません。

前提条件

  1. まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべてのkubectlコマンドを実行します。

    kubectl config set-context $(kubectl config current-context) \
      -n <metadata.namespace>

    注意

    MongoDB Ops Manager リソースを複数の Kubernetes クラスター MongoDB 配置に配置している場合、次の手順に従います。

    • context を演算子クラスターの名前に設定します（kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME" など）。

    • MongoDB のマルチ配置に使用したのと同じスコープ（例: kubectl config --namespace "mongodb"に--namespaceを設定します。

  2. Kubernetes Operator 用のMongoDBコントロールをインストールします。

  3. MongoDB Ops Managerを配置するホストに少なくとも 5 ギガバイトのメモリがあることを確認します。

  1. MongoDB Ops Managerリソースと同じ名前空間に管理者ユーザーのKubernetesシークレットを作成します。MongoDB Ops Manager をマルチ Kubernetes クラスターMongoDBデプロイに配置する場合は、マルチ Kubernetes クラスターMongoDBデプロイスコープに設定した名前空間と同じ名前空間を使用します。

    HashiCorp Vault を シークレットストレージツール として使用している場合は、代わりに Vault シークレットを作成 できます。

    シークレット ストレージのオプションの詳細については、「シークレット ストレージの構成 」を参照してください。

    MongoDB Ops Managerリソースを配置すると、MongoDB MongoDB Ops Managerはこれらの認証情報を持つユーザーを作成し、そのユーザーにGlobal Ownerロールを付与します。 これらの認証情報を使用して、MongoDB Ops Manager に初めてログインします。 MongoDB Ops Manager を配置したら、パスワードを変更するか、このシークレットを削除します。

    注意

    管理者ユーザーのパスワードは、MongoDB Ops Manager のパスワードの複雑さの要件に準拠している必要があります。

    kubectl create secret generic <adminusercredentials> \
      --from-literal=Username="<username>" \
      --from-literal=Password="<password>" \
      --from-literal=FirstName="<firstname>" \
      --from-literal=LastName="<lastname>"

  1. （ 任意 ） MongoDB Ops Managerデータベースユーザーのパスワードを設定するには、 MongoDB Ops Managerリソースと同じ名前空間に シークレット を作成します。

    HashiCorp Vault を シークレットストレージツール として使用している場合は、代わりに Vault シークレットを作成 できます。

    Kubernetes Operator は、 MongoDB Ops ManagerがOps Manager Application Databaseに接続するために使用するデータベースユーザーを作成します。 次のコマンドを呼び出してシークレットを作成することで、このデータベースユーザーのパスワードを設定できます。

    kubectl create secret generic <om-db-user-secret-name> \
      --from-literal=password="<om-db-user-password>"

    注意

    MongoDB Ops Manager データベース ユーザーのシークレットを作成する場合は、MongoDB Ops Manager リソース定義でシークレットのnameを指定する必要があります。 デフォルトでは、Kubernetes Operator はpasswordキー内のパスワード値を検索します。 If you stored the password value in a different key, you must also specify that key name in the Ops Manager resource definition.

    シークレットを作成しない場合、Kubernetes Operator によってパスワードが自動的に生成され、それが内部的に保存されます。 詳細については、「認証 」を参照してください。

  2. （任意）。S3 読み取りへのバックアップを構成するには、 MongoDB Ops Managerリソースと同じ名前空間に シークレット を作成します。

    HashiCorp Vault を シークレットストレージツール として使用している場合は、代わりに Vault シークレットを作成 できます。

    このシークレットはS3認証情報を保存し、 Kubernetes Operator はMongoDB Ops ManagerをAmazon Web Services S3またはS3互換バケットに接続できます。 シークレットには、次のキーと値のペアが含まれている必要があります。

    キー

    値

    accessKey

    Amazon Web ServicesS3 または S3 互換バケットを所有する ユーザーの一意の識別子。

    secretKey

    Amazon Web ServicesS3 または S3 互換バケットを所有する ユーザーの秘密キー。

    シークレットを作成するには、次のコマンドを呼び出します。

    kubectl create secret generic <my-aws-s3-credentials> \
      --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
      --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"

    S 3スナップショット ストレージの管理の詳細については、前提条件 を参照してください。

項目一覧