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 インスタンスを配置して、 リソースの単一の クラスター配置をサポートできます。

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

    Ops Manager リソース

    複数の Kubernetes クラスターでの MongoDB Ops Manager アプリケーションとアプリケーションデータベースの配置をサポートします。

Before you deploy an Ops Manager resource in either a single or multiple Kubernetes clusters, review Ops Manager Resource Architecture and considerations, and complete the prerequisites.

アーキテクチャ

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演算子をインストールするのと同じKubernetesクラスターにこれらのコンポーネントを配置します。このクラスターは、中央クラスターとして機能します。

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

    • 各コンポーネントを、ノードクラスターと呼ばれる異なるKubernetesクラスターに配置します。単一のノードKubernetesクラスターを使用して、簡略化されたマルチクラスター配置を配置することもできます。さらに学ぶには、「シングルクラスターとマルチクラスターのモード」を参照してください。

    • Kubernetes演算子を1つのKubernetesクラスター（中央クラスター）にインストールします。そこから、Kubernetes演算子が他のすべてのノードクラスターをマネージドします。中央クラスターもOps Managerコンポーネントをホストできるため、ノードクラスターと見なすことができます。「マルチクラスターアーキテクチャ図」を参照してください。

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 クラスターで実行されます。

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

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

If possible, use an odd number of member Kubernetes clusters and distribute your Application Database nodes across data centers, zones, or Kubernetes clusters. To learn more, see Replica Sets Distributed Across Two or More Data Centers.

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

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 つのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なノードがありません。

詳細については、「 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 は、Ops Manager Application Database 内の機密情報を保護するための暗号化のキーを生成します。 Kubernetes Operator は、このキーを 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

ロール

You can't modify the Ops Manager database user's name and roles. You create a secret to set the database user's password. You edit the secret to update the password. If you don't create a secret or delete an existing secret, the Kubernetes Operator generates a password and stores it.

シークレットストレージのその他のオプションについては、シークレット ストレージの構成を参照してください。マルチクラスター配置では、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 は、Ops Manager APIを使用してバックアップデーモンを有効にし、ヘッドデータベースを構成します。

重要

バックアップを構成するには、MongoDB リソースを作成するか、

MongoDBMultiCluster リソース

for the oplog store and for one of the following:

  • oplogストアまたは S3 oplogストア。 oplogストアと S3 oplogストアの両方を配置する場合、Ops Manager はバックアップに使用するものをランダムに選択します。

  • S3 読み取りまたはブロックストア。 S3 読み取りとブロックストア の両方を配置する場合、Ops Manager はバックアップに使用するものをランダムに選択します。

これらのバックアップ リソースを構成するまで、 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ストア

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

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

Blockstore

To configure a blockstore, you must deploy a replica set to store snapshots.

S3 Snapshot Store

S3 読み取りを構成するには、データベースバックアップ スナップショットを保存するためのAWS 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. Configure the KMIP settings for your project in Ops Manager following the procedure in Configure Your Project to Use KMIP.

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

    重要

    This includes the ConfigMaps referenced by the MongoDB database resources for the oplog and snapshot stores.

マルチクラスターでの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 シークレットを作成 できます。

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

    When you deploy the Ops Manager resource, Ops Manager creates a user with these credentials and grants it the Global Owner role. Use these credentials to log in to Ops Manager for the first time. Once you deploy Ops Manager, change the password or remove this secret.

    注意

    The admin user's password must adhere to the Ops Manager password complexity requirements.

    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 演算子は MongoDB Ops Manager をユーザーの AWS S3 または S3 互換バケットに接続できます。シークレットには次のキーバリューペアが含まれている必要があります。

    キー

    値

    accessKey

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

    secretKey

    S3 または S3 互換バケットを所有する Amazon Web Services ユーザーのシークレット キー。

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

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

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

このページを評価

項目一覧