ConfigMap を使用してMongoDB配置ごとに 1 つのプロジェクトを作成

MongoDB Controls for Kubernetes Operator は、 Kubernetes ConfigMap を使用して、単一かつ一意の Ops Manager プロジェクトにリンクします。参照されたプロジェクトが存在しない場合、 Kubernetes Operator はprojectName ConfigMap で指定されたに従ってそれを作成します。

Kubernetes Operator ConfigMap を作成するには、例ConfigMap YAMLファイルの数行を編集し、ConfigMap を適用します。完全な例を表示するには、プロジェクトの.YAMLファイルを参照してください。

あるいは、 MongoDB Cloud Manager UIまたはMongoDB Ops Manager UIを使用してプロジェクトを作成または選択し、ConfigMap YAML ファイルを自動的に生成し、 Kubernetes環境に適用できるようにすることもできます。

Considerations

配置できる MongoDB リソースはプロジェクトごとに 1 つだけです。この制限が適用されるのは、MongoDB Ops Manager がプロジェクトごとのデータベースユーザーのアクセスに対して 1 つの認証方法のみをサポートしているためです。詳しくは、「 MongoDB Database リソースの配置」を参照してください。
MongoDB Controls for Kubernetes Operator 配置を一意のMongoDB Ops Managerプロジェクトにペアにする必要があります。配置するMongoDB Controls for Kubernetes Operatorインスタンスごとに個別の ConfigMap を作成するか、ConfigMap から data.projectName を省略して、プロジェクト名が配置されたリソース名と一致するようにすることで、同じ ConfigMap を任意の数の配置で再利用することができます。コンフィギュレーションマップにプロジェクト名が指定されている場合、そのプロジェクトがまだ存在しない場合は作成されます。

重要

Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよびバージョン6.0 .x 以降でリソースを配置できます。
Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。

前提条件

Kubernetesバージョン 1.11 以降、またはOpenShiftバージョン 3.11 以降。
Kubernetes Operator 用のMongoDBドライバーがインストールされました。

コンフィギュレーションマップを使用して 1 つのプロジェクトを作成

`kubectl`をデフォルトで名前空間に設定します。

まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべての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>

以下のコマンドを呼び出して ConfigMap を作成します。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project
  namespace: mongodb
data:
  projectName: myProjectName # this is an optional parameter; when omitted, the Operator creates a project with the resource name
  orgId: 5b890e0feacf0b76ff3e7183 # this is a required parameter
  baseUrl: https://ops.example.com:8443
EOF

キー	タイプ	説明	例
`metadata.name`	string	Kubernetesオブジェクトの名前。リソース名は 44 文字以下にする必要があります。 1123この名前は、小文字の英数字文字または`-` のみを含み、英数字の開始と末尾を含む RFC の命名規則に従う必要があります。詳細については、名前に関するKubernetes のドキュメントを参照してください。	`my-project`
`metadata.namespace`	string	Kubernetes Operator がこの`MongoDB` リソースと他のオブジェクトを作成するKubernetes名前空間。	`mongodb`
`data.projectName`	string	MongoDB Ops Manager プロジェクトのラベル。 Kubernetes Operator は、 MongoDB Ops Managerプロジェクトが存在しない場合は、それを作成します。 `projectName`を省略すると、Kubernetes Operator は Kubernetes リソースと同じ名前のプロジェクトを作成します。または組織で既存のプロジェクトを使用するには、Cloud Manager MongoDB Ops Manager`projectName`All ClustersまたはCloud ManagerMongoDB Ops Manager ページの左上にあるSearch {1 リンクをクリックし、次で名前を検索して、を見つけます。ボックスまたはスクロールして、リスト内の名前を見つけます。このリストの各カードは、1 つのCloud ManagerまたはMongoDB Ops Managerの組織とプロジェクトの組み合わせを表します。	`myProjectName`
`data.orgId`	string	必須。または組織を一意に識別する24 文字の 16stringCloud Manager MongoDB Ops Manager進。 Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよびバージョン6.0 .x 以降でリソースを配置できます。 Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。既存の組織を指定します: 組織の ID を見つけます。左側のナビゲーションバーで [ Settingsをクリックします。 orgId をコピーして URL に貼り付けます。次のように、組織を選択し、ブラウザで現在のURLを表示し、 `<orgId>`プレースホルダーに表示される値をコピーします。 `https://ops.example.com:8443/` `v2#/org/<orgId>/projects` 既存の Cloud Managerまたは組織内に新しいプロジェクトを作成するには、組織プロジェクト作成者MongoDB Ops Manager ロールが必要です。 `orgId` として空のstringを指定すると、 Kubernetes Operator はプロジェクトと同じ名前の組織を作成します。	`5b890e0feacf0b76ff3e7183`
`data.baseUrl`	string	FQDN とポート番号を含む MongoDB Ops Manager アプリケーションへの URL 。重要: を Operator で配置し、 MongoDB Ops Managerが配置先のKubernetes クラスターのMongoDB Ops Manager MongoDB外部に配置されたデータベースリソースを管理する場合、Kubernetes`data.baseUrl` は`spec.configuration.mms.centralUrl` の設定と同じ値に設定する必要があります。のリソース仕様。MongoDB Ops Manager詳細については、「外部MongoDBデプロイの管理」を参照してください。 Cloud Manager を使用している場合は、 `data.baseUrl`の値を`https://cloud.mongodb.com`に設定します。	`https://ops.example.com:8443`

次のKubernetesコマンドを呼び出して、ConfigMap を確認します。

kubectl describe configmaps <configmap-name>

このコマンドは、shell に ConfigMap の説明を返します。

Name:           <configmap-name>
Namespace:      <namespace>
Labels:         <none>
Annotations:    <none>
Data
====
baseUrl:
----
<myOpsManagerURL>
Events:  <none>

カスタム CA を使用した HTTPS 対応のMongoDB Ops Managerへの接続

MongoDB Ops Manager インスタンスで HTTPS を有効にするために、独自の TLS 証明書を使用することを選択した場合があります。カスタム証明書を使用した場合は、そのカスタム証明書に署名した CA を Kubernetes Operator に追加する必要があります。カスタム CA を追加するには、次の手順を実行します。

証明機関（CA）証明書の ConfigMap を作成します。

Kubernetes Operator には、Ops Manager ホストの証明書を発行した CA のルート CA 証明書が必要です。次のコマンドを実行して、データベースポッドの同じ名前空間にルート CA を含む ConfigMap を作成します。

kubectl -n <metadata.namespace> create configmap <root-ca-configmap-name> \
  --from-file=mms-ca.crt

重要

Kubernetes Operator では、ConfigMap でMongoDB Ops Managerリソースの証明書 mms-ca.crt に名前を付ける必要があります。

次の例の強調表示されたセクションをコピーします`ConfigMap` 。

1 ---
2 apiVersion: v1
3 kind: ConfigMap
4 metadata:
5   name: <my-configmap>
6   namespace: <my-namespace>
7 data:
8   projectName: <my-ops-manager-project-name> # this is an optional parameter
9   orgId: <org-id> # this is a required parameter
10   baseUrl: https://<my-ops-manager-URL>

11   sslMMSCAConfigMap: <root-ca-configmap-name>
12   sslRequireValidMMSServerCertificates: ‘true’
13 ...

強調表示されたセクションをプロジェクトの ConfigMap に追加します。

次のコマンドを呼び出して、デフォルトの構成済みエディターでプロジェクトの ConfigMap を編集します。
```
kubectl edit configmaps <my-configmap> -n <metadata.namespace>
```
プロジェクトの ConfigMap の最後に、例のConfigMap でハイライトされているセクションを貼り付けます。

TLS 設定の指定

次のTLSキーを変更します。

キー	タイプ	説明	例
`sslMMSCAConfigMap`	string	Ops Manager ホストの証明書に署名するために使用されるルート CA 証明書を含む最初のステップで作成された ConfigMap の名前。これにより、CA 証明書がKubernetes Operator とデータベースリソースにマウントされます。	`my-root-ca`
`sslRequireValidMMSServerCertificates`	ブール値	からの有効な TLS MongoDB Ops Manager証明書を要求するように演算子を強制します。重要:値は一重引用符で囲む必要があります。そうしないと、演算子はエラーをスローします。	`'true'`

更新された ConfigMap を保存します。

Kubernetesコマンドを呼び出して、ConfigMap を検証します。

kubectl describe configmaps <my-configmap> -n <metadata.namespace>

重要

kubectl名前空間オプションは常に-n と含めてください。オプションを指定しない場合、kubernetes はデフォルトで空の名前空間になるため、デプロイは失敗します。<metadata.namespace> フィールドの値を指定する必要があります。 Kubernetes Operator、 secret 、およびMongoDB リソースは、同じ一意の名前空間で実行する必要があります。