このページを参照して、エンタープライズのコスト管理とアクセス ニーズに合わせて、可用性とパフォーマンスを最適化するための適切なクラスター構成を計画しましょう。
Atlas の高可用性に関する機能
Atlas で新しいクラスターを起動すると、Atlas は最小の 3 ノードレプリカセットを自動的に構成し、それを配置するリージョンに分散します。プライマリ ノードで停止時が発生すると、 MongoDBデータベース は自動的にこの障害を検出し、セカンダリ ノードを代替ノードとして選択し、このセカンダリ ノードを新しいプライマリ ノードに昇格させます。その後、Atlas は障害ノードを復元または置換して、クラスターができるだけ早くターゲット構成に戻るようにします。MongoDBクライアントドライバーも、すべてのクライアント接続を自動的に切り替えます。選択とフェイルオーバーのプロセス全体は 秒以内に発生し、手動による介入はありません。MongoDB は、障害を検出し、新しいプライマリを選択するために使用されるアルゴリズムを最適化し、フェイルオーバー間隔を短縮します。
単一のリージョン内に配置するクラスターは、そのリージョン内のアベイラビリティーゾーン全体に分散されるため、読み取りや書き込みの可用性を中断することなく、リージョンの部分的な停止時に耐えられます。
希望リージョンで常に書込み操作を維持することが優先順位が高い 場合は、少なくとも 2 つの選出可能なMongoDBが希望リージョン内の少なくとも 2 つのアベイラビリティーゾーンに含まれるようにクラスターを配置することをお勧めします。
グローバル配置で最高のデータベース パフォーマンスを得るため、ユーザーはロケーション認識型シャーディングを使用して読み取りと書込みのレイテンシを最小限に抑えるグローバルクラスターを構成できます。地理的ストレージ要件がある場合は、Atlas が特定の地理的領域にデータを保存するようにすることもできます。
Atlas の高可用性に関する推奨事項
単一リージョン向けの推奨配置トポロジー
単一リージョン、3 ノード レプリカセット / シャード(プライマリ セカンダリ セカンダリ)
このトポロジーは、低レイテンシが必要であるが、高可用性の要件が単一リージョンに限定されている場合に適しています。このトポロジーは、1 ノードのあらゆる障害に耐え、リージョン内のセカンダリの過半数の書込み保証 (write concern) を容易に満たすことができます。これにより、ノードに障害が発生した場合でも、優先リージョンにプライマリが維持され、コストが抑えられ、アプリケーション アーキテクチャの観点から最も簡単です。このトポロジーのセカンダリからの読み取りと書き込みは、希望するリージョンで低レイテンシを実現します。
しかし、このトポロジーはリージョンの停止時を許容できません。
高可用性とリカバリのための推奨構成
次の推奨事項を使用して、Atlas の配置とバックアップを高可用性し、障害からの回復を迅速化します。
災害への計画と対応方法に関する詳細は、Atlas 障害復旧ガイダンスをご覧ください。
配置の目的に合わせて配置タイプとクラスター階層を選択する
クラスターを新規作成する場合、専用、フレックス、または無料の配置タイプで利用可能なクラスター階層範囲から選択できます。
アプリケーションサイズに推奨されるクラスター層を決定するには、 「Atlas クラスター サイズ ガイド」 を参照してください。
奇数のレプリカセット メンバーとテスト フェイルオーバーの使用
プライマリを選出するには、利用可能な投票レプリカセット ノードの過半数が必要です。投票権のあるレプリカセット ノードの数が奇数のレプリカセットを作成することをお勧めします。投票権のあるレプリカセット ノードの数を偶数にしても利点はありません。Atlasには 3、5、7 ノードが必要なため、Atlas はデフォルトでこの要件を満たしています。
フォールト トレランスとは、プライマリ選挙に十分な数のノードが参加できる状態にもかかわらず、使用できなくなるレプリカセット ノードの数です。4 ノードのレプリカセットのフォールト トレランスは、3 ノードのレプリカセットのフォールト トレランスと同じです。どちらも単一ノードの停止時に耐えられるからです。
アプリケーションがレプリカセット プライマリの障害を処理できるかどうかをテストするには、プライマリ フェイルオーバーをテストのリクエストを送信します。Atlasがフェイルオーバー イベントをシミュレートする場合、Atlasは現在のプライマリをシャットダウンし、新しいプライマリを選出するための選挙を実施します。
レプリカセット ノードの詳細については、「レプリカセット ノード」を参照してください。レプリカセットの選挙と投票の詳細については、「レプリカセットの選挙」を参照してください。
異なるアベイラビリティーゾーンの少なくとも 3 つのデータセンターにデータを分散
MongoDBは、レプリカセット全体にデータの複数のコピーを保存することで、高可用性を提供します。同じレプリカセットのメンバーが同じリソースを共有しないように、また、データセンターが利用できなくなった場合にレプリカセットがプライマリを選出できるようにするには、少なくとも3つのデータセンターにノードを分散する必要がありますが、少なくとも5つのデータセンターを使用することをおすすめします。
複数のアベイラビリティゾーンをサポートするリージョンにクラスターを展開することで、複数のデータセンターにデータを分散できます。通常、各アベイラビリティーゾーンは1つ以上の個別のデータセンターで構成されており、それぞれが冗長電源、ネットワーキング、接続性を備え、しばしば別々の施設に収容されています。アベイラビリティーゾーンをサポートするリージョンに専有クラスターを配置すると、Atlasは自動的にクラスターのノードをアベイラビリティーゾーンに分割します。たとえば、3つのアベイラビリティーゾーンを持つリージョンにデプロイされた3ノードのレプリカセットクラスターの場合、Atlasは各ゾーンに1つのノードを配置します。これは、同じレプリカセットのメンバーによってリソースが共有されないことを確実にするため、1つのゾーンで停止が発生してもデータベースは引き続き使用できます。
使用データセンターの数を 2 つ以下に絞ることに伴うリスクについて、次の図を用いて説明します。この例ではデータは 2 つのデータセンターに分散されています。

前の図では、データセンター 2 が利用できなくなっても、レプリカセットの過半数のノードが引き続き利用可能で、Atlas はプライマリを選出できます。しかし、データセンター 1 が失われると、3 つのレプリカセット ノードのうち 1 つしか利用できず、過半数ではなくなり、システムは読み取り専用モードに移行します。
以下の図では、3 つのアベイラビリティーゾーンのあるリージョンに配置された 5 ノードのレプリカセットクラスターが示されています。
前の図の 2-2-1 のトポロジーは、複数のリージョンにわたって高可用性、パフォーマンス、コストを取るための推奨トポロジーです。このトポロジーでは、いずれかのデータセンターに障害が発生しても、レプリカセットの過半数は引き続き使用可能であり、Atlas は自動フェイルオーバーを実行できます。3 ノード、3 リージョンのトポロジーは1 つのリージョン障害にも許容できますが、1-1-1トポロジーでフェイルオーバーイベントが発生すると、異なるリージョンで新しいプライマリが選出されます。2-2-1トポロジーは、プライマリノードの障害を許容しながら、新しいプライマリを 希望リージョン に維持できます。
次のリージョンは少なくとも 3 つのアベイラビリティーゾーンをサポートしているため、レプリカセットを配置することをお勧めします。
推奨される Amazon Web Services リージョン
AWS リージョン | ロケーション | Atlas リージョン |
---|---|---|
| 米国バージニア州北部 |
|
| 米国ワシントン州 |
|
| カナダ・ケベック州・モントリオール |
|
| カナダ(カルガリー) |
|
| Ohio, USA |
|
| サンパウロ(ブラジル) |
|
AWS リージョン | ロケーション | Atlas リージョン |
---|---|---|
| 香港 |
|
| オーストラリア・ニューウェールズ州シドニー |
|
| Jakarta, Indonesia |
|
| ムバイ(インド) |
|
| 中国(香港) |
|
| Tokyo, Japan |
|
| 韓国(ソウル) |
|
| 大阪(日本) |
|
| Hyderabad, India |
|
| オーストラリア(ビクトリア州メルボルン) |
|
AWS リージョン | ロケーション | Atlas リージョン |
---|---|---|
| アイルランド |
|
| フランクフルト(ドイツ) |
|
| スウェーデンのストックホルム |
|
| London, England, UK |
|
| フランス・パリ |
|
| ミラノ(イタリア) |
|
| チューリッヒ(スイス) |
|
| スペイン |
|
AWS リージョン | ロケーション | Atlas リージョン |
---|---|---|
| バーレーン |
|
| ケープタウン(南アフリカ) |
|
| Tel Aviv, Israel |
|
| UAE |
|
推奨Azureリージョン
Azure リージョン | ロケーション | Atlas リージョン |
---|---|---|
| Iowa, USA |
|
| バージニア州(米国東部) |
|
| Virginia, USA |
|
| Illinois, USA |
|
| 米国カリフォルニア州 |
|
| 米国ワシントン州 |
|
| Arizona, USA |
|
| Texas, USA |
|
| サンパウロ(ブラジル) |
|
| Rio de Janeiro, Brazil |
|
| トロント(カナダ、オンタリオ州) |
|
Azure リージョン | ロケーション | Atlas リージョン |
---|---|---|
| アイルランド |
|
| オランダ語 |
|
| London, England, UK |
|
| フランス・パリ |
|
| ミラノ(イタリア) |
|
| フランクフルト(ドイツ) |
|
| ワルシャワ(ポーランド) |
|
| チューリッヒ(スイス) |
|
| オスロ(ノルウェー) |
|
| スウェーデン・イェブレ |
|
Azure リージョン | ロケーション | Atlas リージョン |
---|---|---|
| 中国(香港) |
|
| 香港 |
|
| オーストラリア・ニューサウスウェールズ州 |
|
| プネ(インド中部) |
|
| Tokyo, Japan |
|
| 韓国(ソウル) |
|
Azure リージョン | ロケーション | Atlas リージョン |
---|---|---|
| ヨハネスブルグ(南アフリカ) |
|
Azure リージョン | ロケーション | Atlas リージョン |
---|---|---|
| Dubai, UAE |
|
| Qatar |
|
| イスラエル |
|
Google Cloud Platform の推奨リージョン
GCPリージョン | ロケーション | Atlas リージョン |
---|---|---|
| Iowa, USA |
|
| ノースバージニア州(米国) |
|
| オハイオ州コロンバス(米国) |
|
| モントリオール(カナダ) |
|
| トロント(カナダ) |
|
| サンパウロ(ブラジル) |
|
| サンティアゴ(チリ) |
|
| 米国ワシントン州 |
|
| Los Angeles, CA, USA |
|
| ユタ州ソルトレイクシティ(米国) |
|
| Las Vegas, NV, USA |
|
| Dallas, TX, USA |
|
GCPリージョン | ロケーション | Atlas リージョン |
---|---|---|
| 台湾 |
|
| 中国(香港) |
|
| Tokyo, Japan |
|
| 大阪(日本) |
|
| Seoul, Korea |
|
| 香港 |
|
| ムバイ(インド) |
|
| デリー(インド) |
|
| オーストラリア、シドニー |
|
| メルボルン(オーストラリア) |
|
| Jakarta, Indonesia |
|
GCPリージョン | ロケーション | Atlas リージョン |
---|---|---|
| ベルギー |
|
| フィンランド |
|
| London, UK |
|
| フランクフルト(ドイツ) |
|
| オランダ語 |
|
| チューリッヒ(スイス) |
|
| ベルリン(ドイツ) |
|
| ワルシャワ(ポーランド) |
|
| ミラノ(イタリア) |
|
| フランス・パリ |
|
| トリノ(イタリア) |
|
| スペイン、マドリード |
|
GCPリージョン | ロケーション | Atlas リージョン |
---|---|---|
| Tel Aviv, Israel |
|
| Doha, Qatar |
|
| サウジアラビア、ダンマーム |
|
シャーディングされたクラスターに mongos
の冗長性を使用
クライアントがシャーディングされたクラスターに接続する場合は、接続 URI に複数の mongos プロセスを、カンマで区切って含めることをお勧めします。詳細については、「MongoDB 接続文字列の例」を参照してください。この設定により、負荷分散のために操作を異なる mongos
インスタンスにルーティングできますが、障害復旧にも重要です。
以下の図では、シャーディングされたクラスターが3 つのデータセンターに分散されていることが示されています。アプリケーションはリモート ロケーションからクラスターに接続します。データセンター 3 が利用できなくなった場合でも、アプリケーションは他のデータセンターの mongos
プロセスに引き続き接続できます。

再試行可能な読み取りと再試行可能な書き込みを使用すると、mongos
構成に必要なエラー処理を簡素化できます。
majority
書込み保証 (write concern) を使用
MongoDBは、書込み保証 (write concern) を使用して、書き込み操作に要求される確認応答のレベルを指定できます。たとえば、書込み保証 (write concern)がmajority
の3ノードのレプリカセットがある場合、書き込み (write) 操作を実行したドライバに完了の確認が送信される前に、すべての書き込み (write) 操作を2つのノードに永続化する必要があります。地域ノードの停止を保護するための最善の方法として、書込み保証をmajority
に設定することをお勧めします。
majority
書込み保証 (write concern)を使用すると、書込み保証 (write concern)1
と比較して書込みレイテンシが増加しますが、レプリカセットがプライマリを失った場合でもデータセンターは書込み操作を実行し続けることができるため、majority
書込み保証 (write concern)を使用することを推奨します。
数値書込み書込み保証 (write concern)(書込み保証 (write concern)よりも majority
書込み保証 (write concern)を使用する利点を理解するには、2-2-1トポロジー( 4
2 つのノードがあるリージョンのいずれかが使用できなくなった場合、4 つのノードでデータを保持できないため、書込み操作を完了できません。majority
を使用すると、少なくとも 2 つのノードにデータを保持する場合に書込み操作を継続でき、データの冗長性と書込み継続性を維持できます。
バックアップ構成の検討
頻繁にデータをバックアップすることは、ビジネスの継続と障害復旧のために重要です。頻繁にバックアップを行うことで、災害やサイバー攻撃によって通常の運用が中断された場合でも、データ損失やダウンタイムを最小限に抑えることができます。
次のことを推奨します。
貴社のビジネス継続性の目標に合わせてバックアップ頻度を設定してください。継続的なバックアップが必要なシステムもあれば、スナップショットの頻度が少ない方が望ましいシステムもあります。
バックアップは、ソース データとは異なる物理的なロケーションに保存してください。
バックアップ復元プロセスをテストして、バックアップが再現性のある、時間制限のある方法で復元できることを確認してください。
復元時の互換性を確保するために、クラスターが同じ MongoDB バージョンを実行することを確認してください。
バックアップコンプライアンスポリシーを設定して、バックアップスナップショットの削除、スナップショット保持期間の短縮などを防ぎます。
詳細なバックアップの推奨事項については、Atlas のバックアップに関するガイダンスを参照してください。
リソース使用の計画
リソースキャパシティーの問題を回避するには、リソースの使用率をモニターし、定期的にキャパシティープランニング セッションを保持することをお勧めします。MongoDBプロフェッショナル サービスはこれらのセッションを提供します。
過剰使用されたクラスターは失敗し、障害が発生する可能性があります。システム CPU とシステム メモリの使用率が 60%+ を超える場合は、使用率が定期的に定常状態でアラートを発行している場合は、クラスターをより高い階層にスケールアップします。
リソース使用率を表示するには、「 リアルタイム パフォーマンスのモニタリング 」を参照してください。Atlas Administration APIを使用してメトリクスを表示するには、「 モニタリングとログ 」を参照してください。
リソース使用率に関するアラートとモニタリングのベストプラクティスについては、Atlas のモニタリングとアラートのガイダンスを参照してください。
リソース キャパシティーの問題が発生した場合は、「リソース キャパシティーの問題」を参照してください。
MongoDB のバージョン変更とメンテナンスの計画
最新のMongoDBバージョンを実行することをお勧めします。これにより、新機能を活用し、以前のバージョンと比較してセキュリティ保証が強化されます。
MongoDB のメジャー バージョン アップグレードは、現在のバージョンのサポートが終了する前に実行するようにしてください。
Atlas UIを使用してMongoDBのバージョンをダウングレードすることはできません。このため、メジャー バージョン アップグレードを計画して実行するときは、アップグレード プロセス中に発生する可能性のある問題を回避するために、 MongoDBプロフェッショナルまたはテクニカル サービスと直接連携することをお勧めします。
メンテナンスウィンドウの構成
MongoDBでは、クラスターのメンテナンスウィンドウを構成することができ、Atlasがクラスターで週次メンテナンスを開始する時刻を設定できます。カスタムメンテナンスウィンドウを設定すると、ビジネスクリティカルな時間外に、レプリカセットごとに少なくとも1つのレプリカセットの選挙を必要とするメンテナンスをスケジュールできます。
また、プロジェクトに保護時間を設定することもできます。これは、標準更新では開始できない日次の時間枠を定義します。標準更新には、クラスターの再起動や再同期は含まれません。
オートメーションの例:Atlas の高可用性
次の例では、Atlas のオートメーション用ツールを使用して、単一リージョン、3 ノード レプリカセット / シャード配置トポロジーを構成します。
これらの例では、次のようなその他の推奨される構成も適用されます。
開発およびテスト環境用にクラスター階層が
M10
に設定されました。クラスター サイズ ガイドを使用して、アプリケーションのサイズに合った推奨クラスター階層を確認してください。単一リージョン、3 ノード レプリカ セットまたはシャード配置トポロジー。
当社の例では、AWS、Azure、および Google Cloud を互換的に使用します。これら 3 つのクラウド プロバイダーのいずれかを使用できますが、クラウド プロバイダーに一致するようにリージョン名を変更する必要があります。クラウドプロバイダーとそのリージョンに関する詳細は、「クラウドプロバイダー」をご覧ください。
中規模アプリケーション用のクラスター階層が
M30
に設定されました。クラスター サイズ ガイドを使用して、アプリケーションのサイズに合った推奨クラスター階層を確認してください。単一リージョン、3 ノード レプリカ セットまたはシャード配置トポロジー。
当社の例では、AWS、Azure、および Google Cloud を互換的に使用します。これら 3 つのクラウド プロバイダーのいずれかを使用できますが、クラウド プロバイダーに一致するようにリージョン名を変更する必要があります。クラウドプロバイダーとそのリージョンに関する詳細は、「クラウドプロバイダー」をご覧ください。
注意
Atlas CLI を使用してリソースを作成する前に、次の手順を実行する必要があります。
Programmatic Useの手順に従って Atlas CLI から接続します。
プロジェクトごとに 1 つのデプロイメントを作成
開発環境およびテスト環境では、プロジェクトごとに次のコマンドを実行します。ID と名前を変更して、 値を使用します。
atlas clusters create CustomerPortalDev \ --projectId 56fd11f25f23b33ef4c2a331 \ --region EASTERN_US \ --members 3 \ --tier M10 \ --provider GCP \ --mdbVersion 8.0 \ --diskSizeGB 30 \ --tag bu=ConsumerProducts \ --tag teamName=TeamA \ --tag appName=ProductManagementApp \ --tag env=Production \ --tag version=8.0 \ --tag [email protected] \ --watch
ステージング環境と本番環境において、各プロジェクトごとに次の cluster.json
ファイルを作成します。ID と名前を変更して、自分の値を使用します。
{ "clusterType": "REPLICASET", "links": [], "name": "CustomerPortalProd", "mongoDBMajorVersion": "8.0", "replicationSpecs": [ { "numShards": 1, "regionConfigs": [ { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 7, "providerName": "GCP", "regionName": "EASTERN_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": false, "scaleDownEnabled": false }, "diskGB": { "enabled": false } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } } ], "zoneName": "Zone 1" } ], "tag" : [{ "bu": "ConsumerProducts", "teamName": "TeamA", "appName": "ProductManagementApp", "env": "Production", "version": "8.0", "email": "[email protected]" }] }
cluster.json
ファイルを作成した後、各プロジェクトで次のコマンドを実行します。このコマンドは、cluster.json
ファイルを使用してクラスターを作成します。
atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json
その他の構成オプションとこの例に関する情報については「atlas clusters create」を参照してください。
注意
プロジェクトとデプロイメントを作成する
開発環境およびテスト環境では、アプリケーションと環境のペアごとに次のファイルを作成します。各アプリケーションと環境ペアのファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。
main.tf
# Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalDev" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version replication_specs { region_configs { electable_specs { instance_size = var.cluster_instance_size_name node_count = 3 } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } } tags { key = "BU" value = "ConsumerProducts" } tags { key = "TeamName" value = "TeamA" } tags { key = "AppName" value = "ProductManagementApp" } tags { key = "Env" value = "Test" } tags { key = "Version" value = "8.0" } tags { key = "Email" value = "[email protected]" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
variables.tf
# Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Dev" environment = "dev" cluster_instance_size_name = "M10" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" } } required_version = ">= 0.13" }
ファイルを作成した後、各アプリケーションと環境ペアのディレクトリに移動し、次のコマンドを実行して Terraform を初期化します。
terraform init
Terraform プランを表示するには、次のコマンドを実行します。
terraform plan
次のコマンドを実行して、アプリケーションと環境のペアに対して 1 つのプロジェクトと 1 つのデプロイメントを作成します。コマンドは、ファイルと MongoDB & HashiCorp Terraform を使用して、プロジェクトとクラスターを作成します。
terraform apply
プロンプトが表示されたら、yes
を入力し、Enter
を押して設定を適用します。
ステージング環境と本番環境において、各アプリケーションと環境のペアごとに以下のファイルを作成します。各アプリケーションと環境のペアごとに、それぞれのディレクトリ内でファイルを配置します。ID と名前を変更して、自分の値を使用します。
main.tf
# Create a Group to Assign to Project resource "mongodbatlas_team" "project_group" { org_id = var.atlas_org_id name = var.atlas_group_name usernames = [ "[email protected]", "[email protected]" ] } # Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name # Assign the Project the Group with Specific Roles team_id = mongodbatlas_team.project_group.team_id role_names = ["GROUP_READ_ONLY", "GROUP_CLUSTER_MANAGER"] } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalProd" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version replication_specs { region_configs { electable_specs { instance_size = var.cluster_instance_size_name node_count = 3 } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } } tags { key = "BU" value = "ConsumerProducts" } tags { key = "TeamName" value = "TeamA" } tags { key = "AppName" value = "ProductManagementApp" } tags { key = "Env" value = "Production" } tags { key = "Version" value = "8.0" } tags { key = "Email" value = "[email protected]" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
variables.tf
# Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Prod" environment = "prod" cluster_instance_size_name = "M30" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0" atlas_group_name = "Atlas Group"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" } } required_version = ">= 0.13" }
ファイルを作成した後、各アプリケーションと環境ペアのディレクトリに移動し、次のコマンドを実行して Terraform を初期化します。
terraform init
Terraform プランを表示するには、次のコマンドを実行します。
terraform plan
次のコマンドを実行して、アプリケーションと環境のペアに対して 1 つのプロジェクトと 1 つのデプロイメントを作成します。コマンドは、ファイルと MongoDB & HashiCorp Terraform を使用して、プロジェクトとクラスターを作成します。
terraform apply
プロンプトが表示されたら、yes
と入力し、Enter
を押して設定を適用してください。
この例に関するその他の設定オプションや情報については、「MongoDB & HashiCorp Terraform」およびMongoDB Terraform のブログ記事をご覧ください。