AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

既存の MongoDB プロセスを Cloud Manager に追加する

Cloud Manager では、既存の MongoDB 配置をモニタリングとマネジメントに追加するためのウィザードが提供されます。 ウィザードは を操作するプロンプトを表示します。

配置にはプロジェクト内で一意の名前が必要です。

重要

同じプロジェクト内のレプリカセット、シャーディングされたクラスター、およびシャード名は一意である必要があります。 配置名を一意のものにしないと、バックアップ スナップショットが中断されます。

オートメーションはすべての MongoDB オプションをサポートしていないため、インポートが失敗する可能性があります。 詳しくは、「 MongoDB 設定とオートメーション サポート 」を参照してください。

TLS を有効にする場合、MongoDB プロセスを提供するホストの FQDN は、そのホスト上の TLS 証明書の SAN と一致する必要があります。

重要

中間者攻撃を防ぐため、TLS証明書のスコープは可能な限り狭くしてください。1つの TLS 証明書を多くの SAN で使用したり、各ホストでワイルドカード TLS 証明書を使用したりすることは可能ですが、推奨されません。詳細を学ぶには、RFC 2818、セクション 3.1。を参照してください。

次の場合は、優先ホスト名を設定します。

  • MongoDB プロセスにアクセスするために、特定のホスト名、FQDN、IPv4 アドレス、または IPv6 アドレスを要求します。

  • 複数のエイリアスを持つホストに使用するホスト名を指定する必要があります。

詳しくは、プロジェクト設定のPreferred Hostnames設定を参照してください。

Windows サービスとして実行される既存の MongoDB プロセスをオートメーションに追加する場合、オートメーションは次のようになります。

  • 既存のサービスを停止して無効にします

  • 新しいサービスを作成して開始します

Cloud Manager プロジェクトで、その配置に対して MongoDB 認証設定が有効になっている場合、インポートする MongoDB 配置はプロジェクトの認証メカニズムをサポートしている必要があります。

実行中のプロセスがなく、認証が有効になっていない新しい宛先プロジェクトにインポートすることをお勧めします。

ソースクラスターが認証を使用しており、宛先の Cloud Manager プロジェクトに既存の管理対象プロセスがない場合、Cloud Manager は宛先プロジェクトで認証を有効にし、ソースクラスターから既存のキーファイルをインポートし、そのキーファイルを使用して実行するユーザーを認証します。インポート プロセス。

ソースクラスターと宛先 Cloud Manager プロジェクトの両方が認証を使用し、プロジェクトに プロセスがある場合、Cloud Manager はインポートプロセス中に宛先プロジェクトの既存の認証設定を使用しようとします。 インポート プロセスを成功させるには、ソースクラスターと Cloud Manager 宛先プロジェクトの認証情報が同じである必要があります。

インポートが成功するようにするには、インポートプロセスを開始する前に、ソースクラスターに Cloud Manager 宛先プロジェクトの認証情報を追加します。 詳しくは、「レプリカセットのキーのローテーション 」または「 シャーディングされたクラスターのキーのローテーション 」を参照してください。

MongoDB 配置で認証が必要な場合は、監視用に Cloud Manager に配置を追加するときに、必要な認証情報を提供する必要があります。

  • 配置でオートメーションを使用せずに、バックアップ、モニタリング、またはその両方が使用されていた場合は、MongoDB Agent に更新する前に認証情報が であった、それらの認証情報を見つけることができます。

  • 配置でオートメーションを使用せず、バックアップとモニタリングのいずれかを使用する場合、次のようにします。

    1. MongoDB プロセスを追加した後、それらの関数に付与した認証情報を Cloud Manager に追加します。 詳細については、「モニタリング用の認証情報の追加 」および「 バックアップ用の認証情報の追加 」を参照してください。

  • 配置でオートメーションを使用する場合、Cloud Manager は MongoDB Agent の認証情報を使用します。 レガシーバックアップとモニタリング エージェントから認証情報を削除できます。 MongoDB Agent は、オートメーション、バックアップ、モニタリング機能にこれらの認証情報を使用します。

  • 配置でオートメーションが使用されるが、インポートする前にオートメーションが使用されなかった場合は、インポートしたデータベース プロセスにmms-automationユーザーを追加し、ユーザーの認証情報を Cloud Manager に追加します。

詳細については、「オートメーション用の認証情報の追加 」を参照してください。

MongoDB 配置をオートメーションに追加すると、Cloud Manager プロジェクトと MongoDB 配置のセキュリティ設定に影響する可能性があります。

  • オートメーションにより、 プロジェクト セキュリティ設定 が有効になります。 MongoDB 配置に認証が必要であるが、Cloud Manager プロジェクトで認証設定が有効になっていない場合、MongoDB 配置をオートメーションに追加すると、Cloud Manager はプロジェクトのセキュリティ設定を、新しくインポートされた配置のセキュリティ設定に更新します。

    インポート プロセスでは、プロジェクトのセキュリティ設定が現在無効になっている場合にのみ、Cloud Manager プロジェクトのセキュリティ設定がアップデートされます。 インポートプロセスによって、プロジェクトのセキュリティ設定が無効になったり、有効な認証メカニズムが変更されたりすることはありません。

  • オートメーションは MongoDB ユーザーとロール をインポートします。 次のステートメントは、MongoDB の配置に認証が必要な場合、または Cloud Manager プロジェクトで認証設定が有効になっている状況に適用されます。

    MongoDB 配置にユーザーまたはユーザー定義のロールが含まれている場合は、Cloud Manager がこれらのユーザーとロールをインポートして管理することを選択できます。 インポートされたユーザーとロールは、Cloud Manager プロジェクト内のすべての管理対象配置にSyncedです。

    • プロジェクトのEnforce Consistent Set値をYesに設定すると、Cloud Manager はインポートされていないユーザーとロールを MongoDB 配置から削除します。

    • プロジェクトのEnforce Consistent Set値をNoに設定すると、Cloud Manager はプロジェクトにインポートされていないユーザーとロールの管理を停止します。 これらのユーザーとロールは MongoDB 配置に残ります。 これらのユーザーとロールを管理するには、MongoDB 配置に直接接続する必要があります。

    Cloud Manager プロジェクトで特定のユーザーとロールを管理しない場合は、変更を確認して配置する前に、 Authentication & UsersページとAuthentication & Rolesページを使用してインポート中にこれらのユーザーとロールを削除してください。 詳細については、「 MongoDB ユーザーの管理または非管理 」を参照してください。

    インポートされた MongoDB 配置の データベースにすでにmms-backup-agent mms-monitoring-agentユーザーとadmin ユーザーがすでに存在する場合、インポートmms-backup-agent mms-monitoring-agentプロセスはこれらのユーザーのロールを、Cloud Manager プロジェクトで設定されている ユーザーと ユーザーのロールで上書きします。

  • オートメーションは、 プロジェクト 内のすべての配置に適用されます。 Cloud Manager プロジェクトによって管理されているすべてのユーザーとロールを含む、プロジェクトの更新されたセキュリティ設定は、インポートされた MongoDB 配置を含むプロジェクト内のすべての配置に適用されます。

    Cloud Manager が、インポートされた MongoDB 配置を含む、プロジェクト内のすべての配置を新しい設定で再起動します。 インポート後は、プロジェクト内のすべての配置で再起動時に Cloud Manager オートメーションキーファイルが使用されます。

    インポートする配置では、宛先プロジェクトの既存のプロセスと同じキーファイルを使用する必要があります。そうしないと、インポート プロセスが続行されない可能性があります。 詳細については、 「ソースクラスターと宛先クラスターの認証情報」 を参照してください。

    プロジェクト内の既存の配置でインポートされたプロセスとは異なるセキュリティ プロファイルが必要な場合は、ソース MongoDB 配置をインポートできる新しいプロジェクトを作成します。

次の例は、MongoDB の配置で認証が必要な場合、または Cloud Manager プロジェクトで認証設定が有効になっている状況に適用されます。

MongoDB ユーザーとカスタムロールをインポートした場合、Cloud Manager プロジェクトが MongoDB 配置の管理を開始すると、 Enforce Consistent Setの値に関係なく、次の状況が発生します。

  • Cloud Manager プロジェクトは、認証を有効化し、インポートされたユーザーとロールを管理し、新しいユーザーとロールをすべての管理対象配置に同期します。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。 MongoDB 配置には、Cloud Manager プロジェクトが管理するすべてのユーザーとロールがあります。 これらのユーザーとロールでは、Synced Yesは に設定されています。

MongoDB ユーザーとカスタムロールをインポートしない場合、Cloud Manager プロジェクトが MongoDB 配置の管理を開始すると、次の状況が発生します。

Enforce Consistent SetがYesに設定されている場合 :

  • Cloud Manager プロジェクトは認証を有効にし、管理されているユーザーとロールは変更されません。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。

  • Cloud Manager は、インポートされていない MongoDB ユーザーとロールを配置から削除します。

  • MongoDB 配置には、Cloud Manager プロジェクトが管理するすべてのユーザーとロールがあります。 これらのユーザーとロールでは、Synced Yesは に設定されています。

Enforce Consistent SetがNoに設定されている場合 :

  • Cloud Manager プロジェクトでは認証が有効になっており、ユーザーやロールなどのセキュリティ設定は変更されません。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。

  • インポートされていない MongoDB ユーザーとロールは、MongoDB 配置に残ります。

  • MongoDB 配置には、すべてのユーザーとロールが Cloud Manager プロジェクトによって管理されています。 これらのユーザーとロールでは、Synced Yesは に設定されています。

  • 配置でmongodがサービスとして有効になっている場合、オートメーションではなく、再起動時にsystemd がmongodを起動する競合状態が発生する可能性があります。この問題を防ぐには、配置をオートメーションに追加する前に、mongodサービスが無効になっていることを確認します。

    1. mongodサービスが有効になっているかどうかを確認します。

      sudo systemctl is-enabled mongod.service
    2. サービスが有効になっている場合は、無効にします。

      sudo systemctl disable mongod.service
  • Cloud Manager プロジェクトで認証設定が有効になっていないが、MongoDB プロセスで認証が必要な場合は、適切なロールを持つ Cloud Manager プロジェクトの MongoDB Agent ユーザーを追加します。 インポート プロセスに、ユーザーに必要なロールが表示されます。 追加されたユーザーは、プロジェクトの MongoDB Agent ユーザーになります。

  • Cloud Manager プロジェクトで認証設定が有効になっている場合は、Cloud Manager プロジェクトの MongoDB Agent ユーザーを MongoDB プロセスに追加します。

    • MongoDB Agent ユーザーを見つけるには:

      1
      1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

      2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

      3. サイドバーで、 Database見出しの下のSecurityをクリックします。

      [セキュリティ ]ページが表示されます。

      2
    • Cloud Manager プロジェクトの MongoDB Agent ユーザーのパスワードを見つけるには、次のいずれかの方法を使用します。

      「 MongoDB プロセスの追加 」手順の手順に従って、UI でウィザードを起動します。 Do you want to add automation to this deployment?と表示されるモーダルに到達したら以下の操作を行います。

      1. Add Automation and Configure Authentication を選択します。

      2. [Show Password] をクリックします。

      例

      Cloud Manager プロジェクトがユーザー名/パスワード認証を使用している場合は、プロジェクトの Cloud Manager MongoDB エージェント ユーザーmms-automationをインポートする MongoDB 配置のadminデータベースに追加します。

      db.getSiblingDB("admin").createUser( { user: "mms-automation", pwd: <password>, roles: [ 'clusterAdmin', 'dbAdminAnyDatabase', 'readWriteAnyDatabase', 'userAdminAnyDatabase', 'restore', 'backup' ] })
  • Cloud Manager の下にクラスターを追加すると、Cloud Manager は自動的に ログローテーションを有効にします。これにより、 mongodまたはmongosログの既存のlogRotate構成と競合する可能性があります。 この衝突を防ぐには、次の操作を行います。

    • mongodまたはmongosプロセスのlogRotate構成を無効にします。

    • Cloud Manager のデフォルトを使用するには、 または プロセス 構成 から systemLog.logRotateおよびsystemLog.logAppend オプション を削除します。mongodmongos

  • インポートプロセスでは、ソースクラスターと宛先クラスターで認証情報とキーファイルが同じである必要があります。 詳細については、 「ソースクラスターと宛先クラスターの認証情報」 を参照してください。

  • プライマリ・セカンダリ・アービタ(PSA)レプリカセットをインポートする場合、インポートするレプリカセットのキーファイルの内容は、Cloud Managerが宛先プロジェクトでマネージドしているキーファイルと一致している必要があります。一致していない場合、認証エラーが発生し、アービタノードのインポートプロセスは失敗します。

    この問題を回避するには、レプリカセットをインポートする前にアービタを除き、インポートが完了した後にアービタを再度追加します。

  • 既存のレプリカセットを Cloud Manager に正常にインポートするには、インスタンスが正常である必要があります。

重要

シャーディングされたクラスターを追加する場合は、 を使用して、すべてのシャードでこのユーザーを作成する必要があります。mongosつまり、mongosを使用してクラスター全体のユーザーとして、および各シャードのシャードローカルユーザーとして、両方のユーザーを作成します。

既存の MongoDB プロセスを Cloud Manager に追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のProcessesをクリックします。

[プロセス ]ページが表示されます。

2
3

配置をインポートしたプロジェクトで認証が有効になっている場合は、既存の MongoDB プロセスを Cloud Manager に追加した後、新しい配置の認証情報を追加する必要があります。 新しい配置にオートメーション、モニタリング、またはバックアップの認証情報を追加する必要がある状況については、「認証のユースケース」を参照してください。

Atlas にライブ移行する配置を追加する場合は、モニタリングのみに配置(およびその認証情報)を追加する必要があります。

使用する認証メカニズムを選択します。

オートメーションを使用するが、Cloud Manager にインポートする前には使用していなかった配置の認証情報を追加するには、次の手順に従います。

1

MongoDB Agent ユーザーは、MongoDB データベースの自動化タスクを実行します。 この MongoDB ユーザーに適切な特権があることを確認します。

2
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のSecurityをクリックします。

[セキュリティ ]ページが表示されます。

3

次のいずれかのアクションを実行します。

  • このプロジェクトで初めて TLS 、認証、または承認設定を構成する場合は、[ Get Started] をクリックします。

  • このプロジェクトの TLS 認証または承認設定をすでに構成している場合は、[Edit] をクリックします。

4
5
6
設定
値

MongoDB Agent Username

MongoDB Agent のユーザー名を入力します。

MongoDB Agent Password

MongoDB Agent ユーザー名 のパスワードを入力します。

オートメーションを使用せず、モニタリングを使用する配置の認証情報を追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のProcessesをクリックします。

[プロセス ]ページが表示されます。

2

をクリックしますをクリックし、モニタリング設定を表示する配置の横にある [ Monitoring Settings ] をクリックします。

3
4
設定
値

Monitoring Username

監視ユーザー名を入力します。

Monitoring Password

監視ユーザー名用のパスワードを入力します。

オートメーションを使用せず、バックアップを使用する配置の認証情報を追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のContinuous Backupをクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
設定
値

Backup Username

バックアップ ユーザー名を入力します。

Backup Password

バックアップ ユーザー名のパスワードを入力します。

このページを評価