Docs Menu
Docs Home
/
MongoDB 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のバージョン管理 」を参照してください。

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

spec.opsManager
.configMapRef.name

string

ConfigMap MongoDB Ops Managerの名前 接続構成の場合spec.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 演算子は、 securityContextでfsGroup = 2000 、 runAsUser = 2000 、 runAsNonRoot = trueを設定します。 Kubernetes Operator は、 fsgroupをrunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。 詳細については、「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」を参照してください および関連する ディスカッション （Kubernetes ドキュメント）。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDB サポートにお問い合わせください。

永続的なボリューム を使用しない場合 Disk UsageDisk IOPSProcesses、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 演算子のトラブルシューティング 」を参照してください。

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

戻る

配置

次へ

レプリカセット

項目一覧