Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/

MongoDB Ops Managerのリソースの配置

項目一覧

  • Considerations
  • 手順

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 前提条件を完了します。

  • 考慮事項 」をお読みください。

  • アプリケーション データベースの レプリカセット に対して 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 演算子は kubernetes.io/tls を使用しますMongoDB Ops Manager と MongoDB リソースのTLS証明書と秘密キーを保存するためのシークレット。 Kubernetes Operator バージョン1 以降。17 。0 、Kubernetes Operator は Opaque シークレット として保存される連結 PEM ファイルをサポートしていません。

MongoDB Ops Manager リソースを配置する前に、 MongoDB Ops ManagerリソースのMongoDB Ops Managerを立ててください。

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

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

1

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

注意

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

  • contextを中央クラスターの名前に設定します(例: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"

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

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

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

重要

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

  1. MongoDB Ops Manager のTLS証明書チェーン全体をdownloads.mongodb.comから取得します。 次の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. CA MongoDB Ops Managerの証明書ファイルと、前のステップで取得した からの TLS 証明書チェーン全体を連結します。downloads.mongodb.com

    cat cert2.crt cert3.crt cert4.crt >> mms-ca.crt
  3. ConfigMap を 作成するMongoDB Ops Manager の場合

    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: "6.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...
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: MultiCluster
27 clusterSpecList:
28 - clusterName: cluster1.example.com
29 members: 4
30 - clusterName: cluster2.example.com
31 members: 3
32 - clusterName: cluster3.example.com
33 members: 2
34 version: "6.0.0-ubi8"
35 security:
36 certsSecretPrefix: <prefix> # Required. Text to prefix to the
37 # name of the secret that contains the Application
38 # Database's TLS certificate. Name the secret
39 # <prefix>-<metadata.name>-db-cert.
40 tls:
41 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
42 # Name of the ConfigMap file
43 # containing the certicate authority that
44 # signs the certificates used by the
45 # application database.
46
47...
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 のバージョンを表示するには、 コンテナ レジストリを表示します。

6.0.0
string
シークレット の名前 管理ユーザー用に 作成 したMongoDB Ops Manager同じ 名前空間 を使用するようにシークレットを構成する MongoDB Ops Manager リソースとして。
om-admin-secret
spec
.security
string

必須

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

om-prod
spec
.security
.tls
string
ConfigMap の名前 は、カスタム CA を使用して署名された MongoDB Ops Manager TLS 証明書を検証するために作成されました。このフィールドは、カスタム CA を使用して MongoDB Ops Manager TLS 証明書に署名した場合に必要です。
om-http-cert-ca
spec
.externalConnectivity
string
Kubernetesサービス ServiceType MongoDB Ops ManagerKubernetesこれは を の外部で公開します。spec.externalConnectivityKubernetesOperatorKubernetes で外部トラフィックを アプリケーションにルーティングするための サービスを作成したくない場合は、MongoDB Ops Manager 設定とその子を除外します。
LoadBalancer
spec
.applicationDatabase
integer
MongoDB Ops Manager Application Databaseレプリカセットのノードの数。
3
spec
.applicationDatabase
string

必須

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

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

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

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

最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。

spec
.applicationDatabase
string

任意

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

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

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

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

MultiCluster
spec
.applicationDatabase
.security
string

必須

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

appdb-prod
spec
.applicationDatabase
.security
.tls
string
ConfigMap の名前 は、カスタム CA を使用して署名されたアプリケーション データベース TLS 証明書を検証するために作成されました。このフィールドは、カスタム CA を使用してアプリケーションデータベース TLS 証明書に署名している場合は必須です。

ca

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

7

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

  • S 3スナップショット ストアまたはブロックストア を構成するには、 を選択します。 S3スナップショット ストアブロックストア の両方を配置する場合、 MongoDB Ops Managerはバックアップに使用するものをランダムに選択します。

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

キー
タイプ
説明
spec
.backup
ブール値
Flag that indicates that Backup is enabled. ヘッドデータベース、oplog ストア、スナップショット ストアの設定を構成するには、 spec.backup.enabled: trueを指定する必要があります。
true
spec
.backup
.headDB
コレクション
ヘッドデータベースの構成設定のコレクション。 コレクションの個々の設定の説明については、 spec.backup.headDBを参照してください。
spec
.backup
.opLogStores
string
oplog ストアの名前。
oplog1
spec
.backup
.s3OpLogStores
string
S3 oplog ストアの名前。
my-s3-oplog-store
spec
.backup
.opLogStores
.mongodbResourceRef
string
oplog ストアのMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 リソースのmetadata.nameはこの名前と一致する必要があります。
my-oplog-db
spec
.backup
.s3OpLogStores
.mongodbResourceRef
string
S 3 oplog ストアのMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 リソースのmetadata.nameはこの名前と一致する必要があります。
my-s3-oplog-db

S 3スナップショット ストアまたはブロックストア も構成する必要があります。

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

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

キー
タイプ
説明
spec
.backup
.s3Stores
string
S3スナップショットストアの名前。
s3store1
spec
.backup
.s3Stores
.s3SecretRef
string
シークレット の名前accessKey secretKeyフィールドと フィールドを含む。バックアップデーモン サービスは、これらのフィールドの値を認証情報として使用して、 S 3またはS 3互換性のあるバケットにアクセスします。
my-s3-credentials
spec
.backup
.s3Stores
string
データベース バックアップ スナップショットを 保存 する S3 または S 互換バケットの3 URL 。
s3.us-east-1.amazonaws.com
spec
.backup
.s3Stores
string
データベースのバックアップ スナップショットを保存するS 3またはS 3互換バケットの名前。
my-bucket

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

キー
タイプ
説明
spec
.backup
.blockStores
string
ブロックストアの名前。
blockStore1
spec
.backup
.blockStores
.mongodbResourceRef
string
ブロックストア用に作成するMongoDBリソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。
my-mongodb-blockstore
8

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

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-enterprise-kubernetes/master/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: "6.0.5-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: "6.0.17"

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

Tip

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

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

status:
applicationDatabase:
lastTransition: "2022-12-06T18:23:22Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-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が記載されます。 URLMongoDB Ops Managerこの を使用すると、Kubernetes クラスター内から にアクセスしたり 、ConfigMap を使用してプロジェクトを作成したりできます。

13

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

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

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

    https://ops.example.com:8443
  3. 管理者ユーザー認証情報を使用して MongoDB Ops Manager にログインします。

  1. Kubernetes クラスターが実行されているホストで、インターネットからspec.externalConnectivity. portへのアクセスを許可するようにファイアウォール ルールを設定します。

  2. ブラウザ ウィンドウを開き、MongoDB Ops Manager FQDN と を使用してspec.externalConnectivity.port アプリケーションに移動します。

    https://ops.example.com:30036
  3. 管理者ユーザー認証情報を使用して MongoDB Ops Manager にログインします。

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

14

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

15

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

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

  • ConfigMap で MongoDB Ops Manager アプリケーションのURLdata.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: "6.0.5-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 デプロイの管理 」を参照してください。

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

16

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

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

    注意

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

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

  2. リソースと同じ名前空間に S3 スナップショット ストアのMongoDB データベース リソースMongoDB Ops Manager を配置します。

    注意

    S 3スナップショット ストアをレプリカセットとして作成します。

    リソースの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: "6.0.5-ubi8"
opsManager:
lastTransition: "2022-12-06T17:46:32Z"
phase: Running
replicas: 1
url: https://om-backup-svc.dev.svc.cluster.local:8443
version: "6.0.17"

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

MongoDB Ops ManagerリソースをHTTP経由で実行するように配置するには、次の手順に従います。

1

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

注意

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

  • contextを中央クラスターの名前に設定します(例: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"

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

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

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 secret
11 # for the admin user
12 externalConnectivity:
13 type: LoadBalancer
14
15 applicationDatabase:
16 topology: SingleCluster
17 members: 3
18 version: <mongodbversion>
19...
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
16 applicationDatabase:
17 topology: MultiCluster
18 clusterSpecList:
19 - clusterName: cluster1.example.com
20 members: 4
21 - clusterName: cluster2.example.com
22 members: 3
23 - clusterName: cluster3.example.com
24 members: 2
25 version: "6.0.5-ubi8"
26
27...
3
4
キー
タイプ
説明
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利用可能な のバージョンのリストについては、 コンテナ レジストリを表示します。

6.0.0
string

MongoDB Ops Manager 管理者ユーザー用に作成したシークレットの名前。

同じ 名前空間 を使用するようにシークレットを構成する MongoDB Ops Manager リソースとして。

om-admin-secret
spec
.externalConnectivity
string

任意

Kubernetesサービス ServiceType MongoDB Ops ManagerKubernetesこれは を の外部で公開します。

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

LoadBalancer
spec
.applicationDatabase
integer
MongoDB Ops Manager Application Databaseレプリカセットのノードの数。
3
spec
.applicationDatabase
string

必須

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

形式は、 MongoDB Community Editionでは X.Y.ZEnterprise エディションでは X.Y.Z-ubi8 です。

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

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

最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。

spec
.applicationDatabase
string

任意

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

MultiClusterを指定すると、Kubernetes Operator は、 spec.applicationDatabase.membersフィールドに設定した値(指定されている場合)を無視します。

代わりに、 clusterSpecListを指定し、アプリケーション データベースを配置する選択した各 Kubernetes ノード クラスターのclusterNameと、各 Kubernetes クラスター内のmembers (MongoDB ノード)の数を含める必要があります。

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

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

MultiCluster
5

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

  • S 3スナップショット ストアまたはブロックストア を構成するには、 を選択します。 S3スナップショット ストアブロックストア の両方を配置する場合、 MongoDB Ops Managerはバックアップに使用するものをランダムに選択します。

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

キー
タイプ
説明
spec
.backup
ブール値
バックアップが有効になっていることを示すフラグ。 ヘッドデータベース、oplog ストア、 S 3 oplog ストア、スナップショット ストアの設定を構成するには、 spec.backup.enabled: trueを指定する必要があります。
true
spec
.backup
.headDB
コレクション
ヘッドデータベースの構成設定のコレクション。 コレクションの個々の設定の説明については、 spec.backup.headDBを参照してください。
spec
.backup
.opLogStores
string
oplog ストアの名前。
oplog1
spec
.backup
.s3OpLogStores
string
S3 oplog ストアの名前。
my-s3-oplog-store
spec
.backup
.opLogStores
.mongodbResourceRef
string
oplog ストアのMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 リソースのmetadata.nameはこの名前と一致する必要があります。
my-oplog-db
spec
.backup
.s3OpLogStores
.mongodbResourceRef
string
S 3 oplog ストアの MongoDB データベース リソースの名前。
my-s3-oplog-db

S 3スナップショット ストアまたはブロックストア も構成する必要があります。 S3スナップショット ストアブロックストア の両方を配置する場合、 MongoDB Ops Managerはバックアップに使用するものをランダムに選択します。

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

キー
タイプ
説明
spec
.backup
.s3Stores
string
S3スナップショットストアの名前。
s3store1
spec
.backup
.s3Stores
.s3SecretRef
string
accessKeyフィールドとsecretKey フィールドを含むシークレットの名前。バックアップデーモン サービスは、これらのフィールドの値を認証情報として使用して、 S 3またはS 3互換性のあるバケットにアクセスします。
my-s3-credentials
spec
.backup
.s3Stores
string
データベースのバックアップ スナップショットを 保存 する S3 または S 互換バケットの3 URL 。
s3.us-east-1.amazonaws.com
spec
.backup
.s3Stores
string
データベースのバックアップ スナップショットを保存するS 3またはS 3互換バケットの名前。
my-bucket
spec
.backup
.s3Stores
string
S 3互換バケットが存在するリージョン。 このフィールドは、 S 3ストアのs3BucketEndpointURLにリージョンが含まれていない場合にのみ使用します。 このフィールドはAmazon Web Services S3バケットでは使用しないでください。
us-east-1

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

キー
タイプ
説明
spec
.backup
.blockStores
string
ブロックストアの名前。
blockStore1
spec
.backup
.blockStores
.mongodbResourceRef
string
ブロックストア用に作成するMongoDBリソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。 リソースのmetadata.nameはこの名前と一致する必要があります。
my-mongodb-blockstore
6

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

7

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

8
9

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-enterprise-kubernetes/master/samples/ops-manager/ops-manager-external.yaml
10

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

kubectl get om -o yaml -w

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

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

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

Tip

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

11

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

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

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

    http://ops.example.com:8080
  3. 管理者ユーザー認証情報を使用して MongoDB Ops Manager にログインします。

  1. Kubernetes クラスターが実行されているホストで、インターネットからspec.externalConnectivity. portへのアクセスを許可するようにファイアウォール ルールを設定します。

  2. ブラウザ ウィンドウを開き、MongoDB Ops Manager FQDN と を使用してspec.externalConnectivity.port アプリケーションに移動します。

    http://ops.example.com:30036
  3. 管理者ユーザー認証情報を使用して MongoDB Ops Manager にログインします。

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

12

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

13

バックアップを有効にした場合は、「 ConfigMap を使用してMongoDBデプロイごとに 1 つのプロジェクトを作成 」ページの前提条件と手順に従ってプロジェクトを作成します。

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

kubectl get om -o yaml -w

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

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "6.0.17"

重要

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

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

14

バックアップを有効にした場合は、oplog およびスナップショット ストア用の MongoDB データベース リソースを作成して構成を完了します。

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

    注意

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

  2. 次のいずれかを選択します。

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

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

    2. S3 3スナップショット ストアとして使用する S バケットを構成します。

      のリソース定義で指定した詳細を使用して、 S3 バケットにアクセスできることを確認します。MongoDB Ops Manager

15

バックアップを有効にした場合は、次のコマンドを呼び出して、 MongoDB Ops Managerリソースのステータスを確認します。

kubectl get om -o yaml -w

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

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T10:00:53Z"
phase: Running
version: "6.0.5-ubi8"
opsManager:
lastTransition: "2022-04-01T10:00:34Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "6.0.17"

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