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

MongoDB Ops Managerのリソースの配置

Operator を使用して、 MongoDB Ops Managerを コンテナのリソースとして配置できます。KubernetesKubernetes

次の考慮事項が適用されます。

Ops Manager の配置を構成するときは、 HTTPS 経由で接続を実行するか、 HTTP経由で接続を実行するかを選択する必要があります。

次の HTTPS 手順を参照してください。

  • アプリケーションとの間で、 TLSMongoDB Ops Manager で暗号化された接続を確立します。

  • アプリケーションデータベースのレプリカセットメンバー間で TLS 暗号化された接続を確立します。

  • TLS暗号化の有効な証明書が必要です。

次のHTTP手順を参照してください。

  • MongoDB Ops Managerアプリケーションとの間の接続を暗号化しません。

  • アプリケーション データベースのレプリカセット ノード間の接続を暗号化しません。

  • セットアップ必要なセットアップの数が少なくなります。

HTTPS 経由で実行中場合、Ops Manager はデフォルトでポート8443 で実行されます。

MongoDB Ops Manager とアプリケーションデータベースの接続を TLS で暗号化するかどうかに応じて、適切なタブを選択します。

  • アプリケーション データベースのレプリカセットに対して 1 つの TLS 証明書を作成します。

    この TLS 証明書には次の属性が必要です。

    DNS 名

    アプリケーション データベースレプリカセットのノードをホストする各ポッドに SAN またはサブジェクト名を追加していることを確認します。各ポッドの SAN は、次の形式を使用する必要があります。

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local

    キーの用途

    TLS 証明書に次のキー使用状況が含まれていることを確認します(5280 )。

    • "server auth"

    • "client auth"

重要

Kubernetes Operator は kubernetes.io/tls シークレット を使用して、Ops Manager およびMongoDBリソースの TLS 証明書と秘密キーを保存します。 Kubernetes Operator1 17バージョン..0 以降、 Kubernetes Operator は Opaque シークレットとして保存される連結 PEM ファイルをサポートしていません。

この手順は、単一のKubernetesクラスターに Ops Managerインスタンスを配置する場合と、マルチクラスター配置の中央クラスターに Ops Manager を配置する場合に適用されます。複数のKubernetesクラスターに Ops Manager の複数のインスタンスを配置する場合は、「 複数のKubernetesクラスターに Ops Manager リソースを配置する 」を参照してください。

次の手順に従って、Ops ManagerリソースをHTTPS 経由で実行し、TLS を使用してアプリケーションデータベースを保護します。

1

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

注意

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

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

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

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

  1. TLS 証明書と秘密キーが用意できたら、次のコマンドを実行して シークレット を作成します MongoDB Ops Manager の TLS 証明書を保存する MongoDB Ops Manager の

    kubectl create secret tls <prefix>-<metadata.name>-cert \
    --cert=<om-tls-cert> \
    --key=<om-tls-key>
  2. 次のコマンドを実行して、アプリケーションデータベースの TLS 証明書を保存する新しいシークレットを作成します。

    kubectl create secret tls <prefix>-<metadata.name>-db-cert \
    --cert=<appdb-tls-cert> \
    --key=<appdb-tls-key>
3

Ops Manager TLS 証明書がカスタム CA によって署名されている場合、CA 証明書には、Ops ManagerバックアップデーモンがMongoDBバイナリをインターネットからダウンロードできるようにする追加の証明書も含まれている必要があります。 TLS 証明書を作成するには、CA 証明書を保持するための ConfigMap を作成します。

重要

Kubernetes Operator では、ConfigMap 内のMongoDB Ops Manager証明書の名前が mms-ca.crt である必要があります。

  1. MongoDB Ops Managerdownloads.mongodb.com の TLS 証明書チェーン全体を から取得します。次のopenssl コマンドは、現在の作業ディレクトリへのチェーン内の証明書を 形式で出力します。.crt

    openssl s_client -showcerts -verify 2 \
    -connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \
    | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'
  2. Ops Manager の CA の証明書ファイルと、前のステップで取得した からの TLS 証明書チェーン全体を連結します。downloads.mongodb.com

    cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt >> mms-ca.crt

    注意

    • プレースホルダー <custom_ca_cert.pem> を カスタム CA 証明書 PEMファイルに置き換えます。

    • MongoDBのサーバー証明書は含めることができないため、cert1.crtファイルを含めないでください。

  3. Ops Manager の ConfigMap を作成します。

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
4

MongoDB Ops Managerとアプリケーション データベースの構成に合わせて設定を変更します。

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: SingleCluster
27 members: 3
28 version: "8.0.0-ubi8"
29 security:
30 certsSecretPrefix: <prefix> # Required. Text to prefix to the
31 # name of the secret that contains the Application
32 # Database's TLS certificate. Name the secret
33 # <prefix>-<metadata.name>-db-cert.
34 tls:
35 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
36 # Name of the ConfigMap file
37 # containing the certicate authority that
38 # signs the certificates used by the
39 # application database.
40
41...
5
6
キー
タイプ
説明
例

string

このKubernetesMongoDB Ops Manager オブジェクト の名前 。

リソース名は 44 文字以下にする必要があります。

metadata.name名前については、 とKubernetes のドキュメントも参照してください。

om

数値

並行して実行するMongoDB Ops Managerインスタンスの数。

有効な最小値は1です。 spec.topology設定でMultiClusterを指定している場合、このフィールドは無視されます。

1

string

インストールするMongoDB Ops Managerのバージョン。

形式はXYZです。 使用可能なMongoDB Ops Manager のバージョンを表示するには、 コンテナ レジストリを表示します。

8.0.0

string

MongoDB Ops Manager 管理者ユーザー用に作成したシークレットの名前。 Ops Managerリソースと同じ名前空間を使用するようにシークレットを構成します。

om-admin-secret

spec
.security
.certsSecretPrefix

string

必須。

MongoDB Ops Manager TLS 証明書を含むシークレットの名前のプレフィックスに渡すテキスト。

om-prod

spec
.security
.tls
.ca

string

カスタム CA を使用して署名された Ops Manager TLS 証明書を検証するために作成した ConfigMap の名前。このフィールドは、カスタム CA を使用して MongoDB Ops Manager TLS 証明書に署名した場合に必要です。

om-http-cert-ca

spec
.externalConnectivity
.type

string

Ops Manager をKubernetesの外部で公開するKubernetesサービス ServiceType 。spec.externalConnectivity Kubernetes Operator で外部トラフィックを Ops ManagerアプリケーションにルーティングするためのKubernetesサービスを作成したくない場合は、 設定とその子を除外します。

LoadBalancer

spec
.applicationDatabase
.members

integer

MongoDB Ops Manager Application Databaseレプリカセットのノードの数。

3

spec
.applicationDatabase
.version

string

必須。

Ops Manager Application Database が実行するMongoDBのバージョン。

形式は、エンタープライズX.Y.Z-ubi8 エディションでは X.Y.Z、Community エディションでは です。-ubi8 Kubernetes Operator がタグサフィックスを自動的に追加するため、Community エディションのイメージに タグサフィックスを追加しないでください。

重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。 互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。

MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。

spec
.applicationDatabase
.topology

string

任意。

アプリケーション データベースの Kubernetes 配置のタイプ。 省略した場合、デフォルトはSingleClusterです。

MultiClusterを指定すると、 Kubernetes Operator は、spec.applicationDatabase.members フィールドに設定した値(指定されている場合)を無視します。代わりに、 を指定し、アプリケーションclusterSpecList clusterNameデータベースを配置する選択した各Kubernetesノード クラスターの membersと、各Kubernetesクラスター内の ( MongoDBノード)の数を含める必要があります。

CRDclusterSpecList のtopology と の設定を変更して、単一の インスタンスを複数のMongoDB Ops Manager Kubernetes クラスターの 配置インスタンスに変換することはできません。MongoDB

リソース仕様の例も参照してください。

MultiCluster

spec
.applicationDatabase
.security
.certsSecretPrefix

string

必須。

アプリケーション データベースのTLS証明書を含むシークレットの名前のプレフィックスに設定するテキスト。

appdb-prod

spec
.applicationDatabase
.security
.tls
.ca

string

カスタム CA を使用して署名されたアプリケーションデータベースTLS 証明書を検証するために作成した ConfigMap の名前。このフィールドは、カスタム CA を使用してアプリケーションデータベースTLS 証明書に署名した場合に必要です。

ca

Kubernetes Operator は、 設定を使用して追加した CA spec.applicationDatabase.security.tls.caを Ops Manager とアプリケーション データベース ポッドの両方にマウントします。

7

バックアップを構成するには、バックアップを有効にしてから次の操作を行う必要があります。

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

  • oplogストア または S3 oplogストアを構成するには、 を選択します。 oplogストアと S3 oplogストアの両方を配置する場合、Ops Manager はどちらか 1 つをoplogバックアップに使用するためにランダムに選択します。

キー
タイプ
説明
例

spec
.backup
.enabled

ブール値

Flag that indicates that Backup is enabled. ヘッドデータベース、oplog ストア、スナップショット ストアの設定を構成するには、 spec.backup.enabled: trueを指定する必要があります。

true

spec
.backup
.headDB

コレクション

ヘッドデータベースの構成設定のコレクション。コレクション内の個々の設定の説明については、spec.backup.headDB を参照してください。

spec
.backup
.opLogStores
.name

string

oplog ストアの名前。

oplog1

spec
.backup
.s3OpLogStores
.name

string

S3 oplogストアの名前。

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

oplog ストアのMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 リソースのmetadata.nameはこの名前と一致する必要があります。

フィールドが明示的に設定されていない場合、Ops mongodbResourceRefManager はデフォルトでアプリケーション データベースを使用します。アプリケーション データベースはスケーラビリティが限定されており、大規模な環境には適していない可能性があります。

このデフォルト構成は、重大なパフォーマンス低下、アプリケーション データベースの不安定、およびバックアップの失敗につながる可能性があるため、本番環境または大規模な配置には推奨されません。本番環境では、バックアップとoplogストアのメタデータごとに常に mongodbResourceRef を使用して個別のMongoDBインスタンスを構成します。

配置後は、選択した構成を変更したり、バックアップを別の場所に移行したりすることはできません。唯一の代替策は、バックアップを完全に停止して再起動することです。これにより、以前のバックアップはすべて使用できなくなります。

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

S3 oplogストアの リソースまたは リソースの名前。リソースのMongoDBMongoDBMultiClustermetadata.name はこの名前と一致する必要があります。

my-s3-oplog-db

S3 読み取りまたはブロックストアも構成する必要があります。

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

スナップショット保存を構成するには、次の設定を構成します。

キー
タイプ
説明
例

spec
.backup
.s3Stores
.name

string

S3 読み取りの名前。

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

accessKeyフィールドとsecretKey フィールドを含むシークレットの名前。バックアップデーモンサービスは、これらのフィールドの値を認証情報として使用して、 S3 または S3 と互換性のあるバケットにアクセスします。

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

データベースのバックアップ スナップショットを保存する S3 または S3 と互換性のあるバケットのURL 。

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

データベースのバックアップ スナップショットを保存する S3 または S 互換バケットの名前。3

my-bucket

ブロックストアを構成するには、次の設定を構成します。

キー
タイプ
説明
例

spec
.backup
.blockStores
.name

string

ブロックストアの名前。

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

ブロックストア用に作成するMongoDBリソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。

フィールドが明示的に設定されていない場合、Ops mongodbResourceRefManager はデフォルトでアプリケーション データベースを使用します。アプリケーション データベースはスケーラビリティが限定されており、大規模な環境には適していない可能性があります。

このデフォルト構成は、重大なパフォーマンス低下、アプリケーション データベースの不安定、およびバックアップの失敗につながる可能性があるため、本番環境または大規模な配置には推奨されません。本番環境では、バックアップとoplogストアのメタデータごとに常に mongodbResourceRef を使用して個別のMongoDBインスタンスを構成します。

配置後は、選択した構成を変更したり、バックアップを別の場所に移行したりすることはできません。唯一の代替策は、バックアップを完全に停止して再起動することです。これにより、以前のバックアップはすべて使用できなくなります。

my-mongodb-blockstore

8

配置に適用するバックアップのオプション設定をオブジェクト仕様ファイルに追加します。例、各タイプのバックアップストアのタイプと Ops Managerバックアップデーモンプロセスの場合、特定のバックアップストアまたはバックアップデーモンプロセスを特定のプロジェクトに関連付けるためにラベルを割り当てることができます。spec.backup.[*].assignmentLabels Ops Manager リソースの 要素を使用します。

9

配置に適用する オプションの設定 を オブジェクト に追加します 仕様ファイル

10
11

MongoDB Ops Managerのリソース定義のファイル名に対して次の kubectl コマンドを実行します。

kubectl apply -f <opsmgr-resource>.yaml

注意

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

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/1.1.0/public/samples/ops-manager/ops-manager-external.yaml
12

MongoDB Ops Manager リソースのステータスを確認するには、次のコマンドを呼び出します。

kubectl get om -o yaml -w

このコマンドは、リソースの配置中にstatusフィールドの下に次のような出力を返します。

status:
applicationDatabase:
lastTransition: "2022-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

Kubernetes Operator は、次の順序でリソースを調整します。

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

  2. Ops Manager:

  3. バックアップ。

Kubernetes 演算子 は、前のリソースがRunningフェーズに入るまで、リソースを調整 しません 。

MongoDB Ops Managerリソースが Pending フェーズを完了すると、バックアップを有効にしている場合、コマンドは status フィールドの下に次のような出力を返します。

status:
applicationDatabase:
lastTransition: "2022-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2023-04-01T09:57:40Z"
phase: Running
replicas: 1
url: https://om-svc.cloudqa.svc.cluster.local:8443
version: "8.0.0"

バックアップ データベースを構成するまで、バックアップはPending状態のままになります。

Tip

[status.opsManager.url フィールドにはリソースの 接続URL が記載されます。このURLを使用すると、 Kubernetesクラスター内から Ops Manager にアクセスしたり、ConfigMap を使用してプロジェクトを作成したりできます。

リソースがPendingフェーズを完了すると、コマンドはstatusフィールドの下に次のような出力を返します。

status:
applicationDatabase:
lastTransition: "2022-12-06T18:23:22Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T18:23:26Z"
message: The MongoDB object namespace/oplogdbname doesn't exist
phase: Pending
url: https://om-svc.dev.svc.cluster.local:8443
version: ""

バックアップ データベースを構成するまで、バックアップはPending状態のままになります。

Tip

[status.opsManager.url フィールドにはリソースの 接続URL が記載されます。このURLを使用すると、 Kubernetesクラスター内から Ops Manager にアクセスしたり、ConfigMap を使用してプロジェクトを作成したりできます。

13

MongoDB Ops ManagerKubernetes実行する手順は、 の アプリケーションへのトラフィックをルーティングする方法によって異なります。Kubernetes Operator を構成してKubernetesサービスを作成した場合、またはKubernetesサービスを手動で作成した場合は、次のいずれかの方法を使用してMongoDB Ops Managerアプリケーションにアクセスします。

  1. クラウドプロバイダーにクエリを実行して、ロード バランサー サービスのFQDNを取得します。 詳しくは、クラウドプロバイダーのドキュメントを参照してください。

  2. ブラウザウィンドウを開き、ロードバランサーサービスの FQDN とポート番号を使用して MongoDB Ops Managerアプリケーションに移動します。

    https://ops.example.com:8443

サードパーティのサービスを使用してMongoDB Ops Managerアプリケーションにアクセスする方法については、ソリューションのドキュメントを参照してください。

14

認証情報を構成するには、 MongoDB Ops Manager組織を作成 し、 プログラムAPIキーを生成 して、 シークレット を作成する必要があります。これらのアクティビティは、Kubernetes Operator の認証情報の作成 ページの前提条件と手順に従います。

15

プロジェクトを作成するには、「 ConfigMap を使用してMongoDBデプロイごとに 1 つのプロジェクトを作成 」ページの前提条件と手順に従います。

プロジェクト ConfigMap で次のフィールドを設定します。

  • ConfigMap で MongoDB Ops Manager アプリケーションのURLにdata.baseUrlを設定します。 このURLを見つけるには、次のコマンドを呼び出します。

    kubectl get om -o yaml -w

    このコマンドは、次の例のように、 status.opsManager.urlフィールドに MongoDB Ops Manager アプリケーションの URL を返します。

    status:
    applicationDatabase:
    lastTransition: "2022-12-06T18:23:22Z"
    members: 3
    phase: Running
    type: ReplicaSet
    version: "8.0.0-ubi8"
    opsManager:
    lastTransition: "2022-12-06T18:23:26Z"
    message: The MongoDB object namespace/oplogdbname doesn't exist
    phase: Pending
    url: https://om-svc.dev.svc.cluster.local:8443
    version: ""

    重要

    MongoDB Ops ManagerKubernetesOperatorMongoDB Ops Manager MongoDBを使用してKubernetes を配置し、data.baseUrl spec.configuration.mms.centralUrlが配置先のMongoDB Ops Manager クラスターの 外部 に配置された データベース リソースを管理する場合、 の 設定と同じ値に設定する必要があります。リソース仕様。

    詳細については、「外部 MongoDB デプロイの管理 」を参照してください。

  • MongoDB Ops Manager data.sslMMSCAConfigMapホストの証明書に署名するために使用されるルート CA 証明書を含む ConfigMap の名前に を設定します。 Kubernetes Operator では、ConfigMap でこの Ops Manager リソースの証明書mms-ca.crt に名前を付ける必要があります。

16

デフォルトでは 、Ops Manager はバックアップを有効にします。 oplogおよびスナップショット ストア用のMongoDBデータベースリソースを作成し、構成を完了します。

  1. リソースと同じ名前空間に ストア用のMongoDB database リソースoplogMongoDB Ops Manager を配置します。

    注意

    このデータベースを 3 ノードのレプリカセットとして作成します。

    リソースのmetadata.nameと MongoDB Ops Manager リソース定義で指定したspec.backup.opLogStores.mongodbResourceRef.nameを照合します。

  2. Ops Managerリソースと同じ名前空間に S3 読み取りのMongoDBデータベースリソースを配置します。

    注意

    S3 読み取りをレプリカセットとして作成します。

    リソースのmetadata.nameを MongoDB Ops Manager リソース定義で指定したspec.backup.s3Stores.mongodbResourceRef.nameと照合します。

17

MongoDB Ops Manager リソースのステータスを確認するには、次のコマンドを呼び出します。

kubectl get om -o yaml -w

MongoDB Ops Managerが実行されている場合、コマンドは status フィールドの下に次のような出力を返します。

status:
applicationDatabase:
lastTransition: "2022-12-06T17:46:15Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T17:46:32Z"
phase: Running
replicas: 1
url: https://om-backup-svc.dev.svc.cluster.local:8443
version: "8.0.0"

リソースの配置ステータスの詳細については、「 Kubernetes 演算子のトラブルシューティング 」を参照してください。

このページを評価