Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/
Enterprise Kubernetes 演算子
/
データベース リソースの配置
/
配置

スタンドアロンの MongoDB インスタンスの配置

注意

このページのMongoDB Ops Managerが表示されている場所では、 Cloud Managerを置き換えることができます。

重要

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

  • Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。

用に スタンドアロン のMongoDB MongoDB Ops Managerインスタンスを配置して管理できます。テストと開発にはスタンドアロン インスタンスを使用します。 これらの配置は、レプリケーションが機能せず、可用性が低いため、実稼働システムでは使用しないでください。 すべての配置ではレプリカセットを使用します。 レプリカセットの詳細については、「 レプリカセットを配置する 」を参照してください。

前提条件

オブジェクトを使用してスタンドアロンを配置するには、以下を行う必要があります。

注意

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

手順

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>
2

次の例のスタンドアロンKubernetesオブジェクトをコピーします。

これは、必要な構成に合わせて変更できる YAMLファイルです。 強調表示された設定を、必要なスタンドアロン構成に合わせて変更します。

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
spec:
  version: "4.2.2-ent"
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true
...
3

任意のテキストエディタを開き、オブジェクト仕様を新しい テキストファイルに貼り付けます。

4

前の手順で強調表示されている設定を次のように構成します。

キー
タイプ
説明
例

metadata.name

string

このKubernetesスタンドアロンオブジェクトのラベル。

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

metadata.name詳しくは、名前に関する とKubernetes のドキュメントを参照してください。

my-project

spec.version

string

このスタンドアロンにインストールされている MongoDB のバージョン。

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

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

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

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

spec.opsManager
.configMapRef.name

string

Ops Manager 接続構成を含む ConfigMapspec.cloudManager.configMapRef.name の名前。 設定はこの設定のエイリアスであり、代わりに使用できます。

この値は、作成するリソースと同じ名前空間に存在する必要があります。

<myproject>

spec.credentials

string

Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。

認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。

重要: Kubernetes Operator は、シークレットへの変更を追跡し、MongoDB リソースの状態を調整します。

<mycredentials>

spec.type

string

作成するMongoDBリソースのタイプ。

Standalone

spec.persistent

string

任意。

この値がtrueの場合、 spec.podSpec.persistence.singleはデフォルト値の16Giに設定されます。

永続ボリューム要求の構成を変更するには、配置要件を満たすように次のコレクションを構成します。

警告: コンテナに 永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、fsGroup = 2000 runAsUser = 2000で 、 、 を設定します。 Kubernetes Operator は、 をrunAsNonRoot = true securityContextfsgrouprunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。詳細については、 Kubernetesドキュメントの「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」および関連するディスカッションを参照してください。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDBサポート にお問い合わせください。

永続ボリューム Disk UsageDisk IOPSを使用しない場合、この配置のデータを確認するときに、Processes ページまたはDeployment Metricsページの タブには、 チャートと チャートは表示されません。

true

5

スタンドアロン配置に許容されている設定を追加します。

また、スタンドアロン配置のオブジェクト仕様ファイルに次の任意設定のいずれかを追加することもできます。

6

このファイルを .yaml という拡張子で保存します。

7

スタンドアロン配置を開始します。

次の Kubernetes コマンドを呼び出して、スタンドアロンを作成します。

kubectl apply -f <standalone-conf>.yaml
8

スタンドアロン配置のステータスを追跡します。

MongoDBリソースのステータスを確認するには、次のコマンドを使用します。

kubectl get mdb <resource-name> -o yaml -w

-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。 リソース配置ステータスの詳細については、 「 Kubernetes 演算子のトラブルシューティング 」を参照してください。

シャーディングされたクラスターのトラブルシューティングを行うには、以下を参照してください。

戻る

配置

次へ

レプリカセット

項目一覧