配置環境の選択

MongoDB Atlas は、Docker または Podman コンテナ内で実行される単一ノード Atlas インスタンスを介してローカル マシンで利用できます。

リモート クラスターのコストを発生させることなくAtlas機能を使用してアプリケーションをビルドおよびテストする場合は、ローカル配置を選択します。

本番環境で使用できるインフラストラクチャが必要な場合は、あまり適していません。ローカル配置では単一のノードしか実行されないため、本番のワークロードには適していません。

MongoDB Atlas は、Web UI、CLI、API を介して、MongoDB マネージド クラウド インフラストラクチャでクラウド配置に利用できます。これらのインターフェースにより、チームはクラスターのプロビジョニング、構成、マネジメントを直接オンデマンドで制御できます。

チームが既存の Infrastructure as Code パイプラインを使用していない場合、または一時的また特殊なユースケースのクラスターをプロビジョニングする必要がある場合は、クラウド配置を選択します。

複数の環境でコンシステントで再現可能なインフラストラクチャ構成が必要な場合は、あまり理想的ではありません。

MongoDB Atlas は、クラスターの構成、アクセス制御、および拡大ポリシーがコードで定義され、既存の CI/CD パイプラインを介して配置される Infrastructure as Code (IaC) プラットフォームで利用できます。

開発環境、ステージング環境、プロダクション環境で同一のバージョン管理された構成が必要な場合は、Infrastructure as Code 配置を選択します。

チームがIaCパイプラインを維持していない場合や、一時的またはアドホックなユースケースのクラスターをプロビジョニングする必要がある場合は、あまり理想的ではありません。

MongoDB Atlas は、Atlas クラスターとデータベースユーザーを Kubernetes カスタムリソースとして管理する Atlas Kubernetes Operator (AKO) を通じて Kubernetes で利用できます。

チームがすでに Kubernetes クラスターを運用しており、他のワークロードと一緒に Atlas リソースを管理したい場合は、Kubernetes 配置を選択します。

チームが Kubernetes を使用していない場合や、より簡単なプロビジョニング インターフェースを好む場合は、あまり適していません。

MongoDB Enterprise は、ローカル開発とテスト用の Docker または Podman コンテナイメージとして利用できます。

フルサーバー環境をプロビジョニングせずに、ローカル配置を選択してエンタープライズ固有の機能に対するアプリケーションを開発およびテストします。

本番環境で使用できるインフラストラクチャや自動バックアップ、モニタリング、拡大のための MongoDB Ops Manager 統合が必要な場合は、あまり適していません。

MongoDB Enterprise は、MongoDB トポロジーを Kubernetes カスタムリソースとしてマネージドする MongoDB Controllers for Kubernetes (MCK) 演算子を介して Kubernetes 上で利用できます。

チームがすでにKubernetesクラスターを運用しており、別のオートメーションレイヤーを維持せずにMongoDBを統合したい場合は、 Kubernetes配置を選択します。

チームが Kubernetes を使用していない場合や、伝統的なサーバーインフラで MongoDB を管理することを好む場合は、あまり理想的ではありません。

MongoDB Enterprise は、クラスター間のプロビジョニング、アップグレード、バックアップ、構成マネジメントのコントロールプレーンとして機能する MongoDB Ops Manager を通じて利用できます。

MongoDB Enterprise クラスターの大規模なフリートを管理する場合、規制された環境で操作する場合、または既存のVMベースの操作を使用する場合は、MongoDB Ops Manager の配置を選択します。

小規模な配置を管理する場合や、集中マネジメントインターフェースよりもインフラストラクチャーアスコード ツーリングを優先する場合は、あまり理想的ではありません。

MongoDB Enterprise は、プラットフォームネイティブパッケージまたはバイナリアーカイブを通じてサーバーに手動でインストールでき、構成と操作を完全に制御できます。

MongoDB の構成を完全に制御する必要がある場合、エアギャップ環境で操作する場合、または Ansible や Puppet などの既存のツールを使用してインフラを操作する場合は、手動インストールを選択します。

複数のサーバーでプロビジョニング、アップグレード、モニタリング、またはバックアップの集中化されたオートメーションが必要な場合は、あまり適していません。

MongoDB Community は、ローカル開発、テスト、CI パイプラインの Docker または Podman コンテナ イメージとして利用できます。

MongoDB Community インスタンスに対してアプリケーションを開発およびテストする場合、または軽量で分離された MongoDB インスタンスが必要な CI パイプラインの場合は、ローカル配置を選択します。

ローカル配置にはモニタリング、バックアップ、拡大のツールがないため、本番環境に対応したインフラストラクチャが必要な場合にはあまり理想的ではありません。

MongoDB Communityは、プラットフォームネイティブパッケージまたはバイナリアーカイブを介してサーバーに手動でインストールでき、構成と操作を完全に制御できます。

従来のインフラストラクチャ上に自己管理型のMongoDBサーバーが必要な場合、または Onsible や Pupet などの既存のツールを使用して配置を構築する場合は、 手動インストールを選択します 。

自分で管理することなく自動プロビジョニング、モニタリング、バックアップが必要な場合は、あまり適していません。