既存の MongoDB プロセスを Cloud Manager に追加する
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
Cloud Manager では、既存の MongoDB 配置をモニタリングとマネジメントに追加するためのウィザードが提供されます。 ウィザードは を操作するプロンプトを表示します。
MongoDB Agent がインストールされていない場合は、インストールします
追加する シャーディングされたクラスター、レプリカセット、またはスタンドアロンを識別します。 配置をモニタリングに追加することも、モニタリングとオートメーションの両方に追加することもできます。
Atlas にライブ移行する配置を追加する場合は、モニタリングのみに配置(およびその認証情報)を追加する必要があります。
Considerations
一意の名前
配置にはプロジェクト内で一意の名前が必要です。
重要
同じプロジェクト内のレプリカセット、シャーディングされたクラスター、およびシャード名は一意である必要があります。 配置名を一意のものにしないと、バックアップ スナップショットが中断されます。
MongoDB 構成オプション
オートメーションはすべての MongoDB オプションをサポートしていないため、インポートが失敗する可能性があります。 詳しくは、「 MongoDB 設定とオートメーション サポート 」を参照してください。
TLS
TLS を有効にする場合、MongoDB プロセスを提供するホストの FQDN は、そのホスト上の TLS 証明書の SAN と一致する必要があります。
重要
中間者攻撃(man-in-the-middle attack)を防ぐには、 TLS証明書の範囲をできるだけ小さくします。 多数の SAN で 1 つの TLS 証明書を使用することも、各ホストでワイルドカード TLS 証明書を使用することもできますが、 は使用しないでください 。詳しくは、 RFC2818 のセクション3 を参照してください。1 。
ご希望のホスト名
次の場合は、優先ホスト名を設定します。
MongoDB プロセスにアクセスするには、特定のホスト名、 FQDN 、 IPv4アドレス、またはIPv6アドレスが必要です。または
複数のエイリアスを持つホストに使用するホスト名を指定する必要があります。
詳しくは、プロジェクト設定の Preferred Hostnames設定を参照してください。
Windows MongoDB Services の管理
Windows サービスとして実行される既存の MongoDB プロセスをオートメーションに追加する場合、オートメーションは次のようになります。
既存のサービスを停止して無効にします
新しいサービスを作成して開始します
ソースクラスターと宛先クラスターの認証情報
Cloud Manager プロジェクトで、その配置に対して MongoDB 認証設定が有効になっている場合、インポートする MongoDB 配置はプロジェクトの認証メカニズムをサポートしている必要があります。
実行中のプロセスがなく、認証が有効になっていない新しい宛先プロジェクトにインポートすることをお勧めします。
ソースクラスターが認証を使用しており、宛先の Cloud Manager プロジェクトに既存の管理対象プロセスがない場合、Cloud Manager は宛先プロジェクトで認証を有効にし、ソースクラスターから既存のキーファイルをインポートし、そのキーファイルを使用して実行するユーザーを認証します。インポート プロセス。
ソースクラスターと宛先 Cloud Manager プロジェクトの両方が認証を使用し、プロジェクトに プロセスがある場合、Cloud Manager はインポートプロセス中に宛先プロジェクトの既存の認証設定を使用しようとします。 インポート プロセスを成功させるには、ソースクラスターと Cloud Manager 宛先プロジェクトの認証情報が同じである必要があります。
インポートが成功するようにするには、インポートプロセスを開始する前に、ソースクラスターに Cloud Manager 宛先プロジェクトの認証情報を追加します。 詳しくは、「レプリカセットのキーのローテーション 」または「 シャーディングされたクラスターのキーのローテーション 」を参照してください。
認証のユースケース
MongoDB 配置で認証が必要な場合は、監視用に Cloud Manager に配置を追加するときに、必要な認証情報を提供する必要があります。
配置でオートメーションを使用せずに、バックアップ、モニタリング、またはその両方が使用されていた場合は、MongoDB Agent に更新する前に認証情報が であった、それらの認証情報を見つけることができます。
配置でオートメーションを使用せず、バックアップとモニタリングのいずれかを使用する場合、次のようにします。
MongoDB 配置の認証情報を作成します。 詳細については、「モニタリング用の MongoDB Agent に必要なアクセス権 」および「 バックアップ用の MongoDB Agent に必要なアクセス権 」を参照してください。
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
サービスが無効になっていることを確認します。mongod
サービスが有効になっているかどうかを確認します。sudo systemctl is-enabled mongod.service サービスが有効になっている場合は、無効にします。
sudo systemctl disable mongod.service
Cloud Manager プロジェクトで認証設定が有効になっていないが、MongoDB プロセスで認証が必要な場合は、適切なロールを持つ Cloud Manager プロジェクトの MongoDB Agent ユーザーを追加します。 インポート プロセスに、ユーザーに必要なロールが表示されます。 追加されたユーザーは、プロジェクトの MongoDB Agent ユーザーになります。
Cloud Manager プロジェクトで認証設定が有効になっている場合は、Cloud Manager プロジェクトの MongoDB Agent ユーザーを MongoDB プロセスに追加します。
MongoDB Agent ユーザーを見つけるには:
1MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
2Security ページに移動します。
配置の [ Security ] タブをクリックします。
[セキュリティ ]ページが表示されます。
Cloud Manager プロジェクトの MongoDB Agent ユーザーのパスワードを見つけるには、次のいずれかの方法を使用します。
「 MongoDB プロセスの追加 」手順の手順に従って、UI でウィザードを起動します。 Do you want to add automation to this deployment?と表示されるモーダルに到達したら以下の操作を行います。
Add Automation and Configure Authentication を選択します。
[Show Password] をクリックします。
Automation Configuration Resourceエンドポイントを使用します。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Accept: application/json" \ --include \ --request GET "<host>/api/public/v1.0/groups/<Group-ID>/automationConfig" テキスト エディターで
mmsConfigBackup
ファイルを開き、autoPwd
値を見つけます。例
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
構成と競合する可能性があります。 この衝突を防ぐには、次の操作を行います。インポートプロセスでは、ソースクラスターと宛先クラスターで認証情報とキーファイルが同じである必要があります。 詳細については、 「ソースクラスターと宛先クラスターの認証情報」 を参照してください。
既存のレプリカセットを Cloud Manager に正常にインポートするには、インスタンスが正常である必要があります。
手順
MongoDB プロセスの追加
既存の MongoDB プロセスを Cloud Manager に追加するには、次の手順に従います。
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
配置への認証資格情報の追加
配置をインポートしたプロジェクトで認証が有効になっている場合は、既存の MongoDB プロセスを Cloud Manager に追加した後、新しい配置の認証情報を追加する必要があります。 新しい配置にオートメーション、モニタリング、またはバックアップの認証情報を追加する必要がある状況については、「認証のユースケース」を参照してください。
Atlas にライブ移行する配置を追加する場合は、モニタリングのみに配置(およびその認証情報)を追加する必要があります。
使用する認証メカニズムを選択します。
オートメーションの認証情報の追加
オートメーションを使用するが、Cloud Manager にインポートする前には使用していなかった配置の認証情報を追加するには、次の手順に従います。
MongoDB Agent ユーザーをデータベースに追加します。
MongoDB Agent ユーザーは、MongoDB データベースの自動化タスクを実行します。 この MongoDB ユーザーに適切な特権があることを確認します。
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Security ページに移動します。
配置の [ Security ] タブをクリックします。
[セキュリティ ]ページが表示されます。
適切な認証情報を追加します。
設定 | 値 |
---|---|
MongoDB Agent Username | MongoDB Agent のユーザー名を入力します。 |
MongoDB Agent Password | MongoDB Agent ユーザー名 のパスワードを入力します。 |
設定 | 値 |
---|---|
MongoDB Agent LDAP Username | LDAPユーザー名を入力します。 |
MongoDB Agent LDAP Password | MongoDB Agent のLDAPユーザー名 のパスワードを入力します。 |
MongoDB Agent LDAP Group DN | MongoDB Agent のLDAPグループの識別名を入力します。 LDAP 認可を使用する場合にのみ、MongoDB Agent の LDAP グループ DN を指定します。各MongoDB Agentは を持ち、独自のLDAPグループDNを使用する必要があります。 |
必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。
設定 | 値 |
---|---|
Monitoring Kerberos Principal | Kerberos プリンシパル。 |
Monitoring Keytab Path | MongoDB Agent のキータブへの絶対ファイル Ppath |
Monitoring LDAP Group DN | MongoDB Agent のLDAPグループの識別名を入力します。 次に、 LDAPグループ DN が MongoDB でロールとして作成され、MongoDB Agent に適切な権限が付与されます。 LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。 |
設定 | 値 |
---|---|
MongoDB Agent Username | Active Directory ユーザー名。 |
MongoDB Agent Password | Active Directory のパスワード。 |
Domain | Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。 |
設定 | 値 |
---|---|
MongoDB Agent Username | MongoDB Agent の PEM キー ファイルから生成された LDAP v 識別名を入力します。3 |
TLS/SSL CA File Path | PEM形式の信頼できる認証局(CA)証明書を含むディスク上のパス。 これらの証明書は、 TLS / SSLを使用して実行されている MongoDB インスタンスから返されたサーバー証明書を検証します。 少なくとも 1 つのTLS / SSL CA ファイル パスを入力する必要があります。 |
MongoDB Agent PEM Key file | MongoDB 配置にクライアント証明書が必要な場合は、適切なオペレーティング システムの行で、サーバー上の MongoDB Agent のPEMキー ファイルで使用されるクライアント証明書のパスと |
MongoDB Agent PEM Key Password | PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。 |
MongoDB Agent LDAP Group DN | MongoDB Agent のLDAPグループの識別名を入力します。 MongoDB Agent の LDAP グループ DN を指定する必要があるのは、LDAP 認証を使用する場合のみです。 |
モニタリングの認証情報の追加
オートメーションを使用せず、モニタリングを使用する配置の認証情報を追加するには、次の手順に従います。
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
適切な認証情報を追加します。
設定 | 値 |
---|---|
Monitoring Username | 監視ユーザー名を入力します。 |
Monitoring Password | 監視ユーザー名用のパスワードを入力します。 |
設定 | 値 |
---|---|
Monitoring LDAP Username | LDAPユーザー名を入力します。 |
Monitoring LDAP Password | モニタリングのLDAPユーザー名 のパスワードを入力します。 |
Monitoring LDAP Group DN | モニタリングのLDAPグループの識別名を入力します。 LDAP 認可 を使用する場合にのみ、モニタリングの LDAP グループ DN を指定します。各モニタリングは を持ち、独自のLDAPグループDNを使用する必要があります。 |
必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。
設定 | 値 |
---|---|
Monitoring Kerberos Principal | Kerberos プリンシパル。 |
Monitoring Keytab Path | 監視のキータブへの絶対ファイル P パス。 |
Monitoring LDAP Group DN | モニタリングのLDAPグループの識別名を入力します。 次に、モニタリング に適切な特権を付与するために、 LDAPグループ DN は MongoDB でロールとして作成されます。 LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。 |
設定 | 値 |
---|---|
Monitoring Username | Active Directory ユーザー名。 |
Monitoring Password | Active Directory のパスワード。 |
Domain | Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。 |
設定 | 値 |
---|---|
Monitoring Username | モニタリングの PEM キー ファイルから生成された LDAP v 識別名を入力します。3 |
Monitoring PEM Key file | 適切なオペレーティング システムの行で、サーバー上のモニタリングのPEMキー ファイルのパスとファイル名を指定します。 |
Monitoring PEM Key Password | PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。 |
Monitoring LDAP Group DN | モニタリングのLDAPグループの識別名を入力します。 LDAP 認可 を使用する場合は、モニタリングの LDAP グループ DN のみを指定する必要があります。 |
バックアップの認証情報の追加
オートメーションを使用せず、バックアップを使用する配置の認証情報を追加するには、次の手順に従います。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
配置で [] をクリックし、次に Edit Credentials[] をクリックします。
適切な認証情報を追加します。
設定 | 値 |
---|---|
Backup Username | バックアップ ユーザー名を入力します。 |
Backup Password | バックアップ ユーザー名のパスワードを入力します。 |
設定 | 値 |
---|---|
Backup LDAP Username | LDAPユーザー名を入力します。 |
Backup LDAP Password | バックアップのLDAPユーザー名 のパスワードを入力します。 |
Backup LDAP Group DN | バックアップのLDAPグループの識別名を入力します。 LDAP 認可 を使用する場合にのみ、バックアップの LDAP グループ DN を指定します。各バックアップは を持ち、独自のLDAPグループDNを使用する必要があります。 |
必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。
設定 | 値 |
---|---|
Monitoring Kerberos Principal | Kerberos プリンシパル。 |
Monitoring Keytab Path | バックアップのキータブへの絶対ファイル P パス。 |
Monitoring LDAP Group DN | バックアップのLDAPグループの識別名を入力します。 次に、バックアップに適切な特権を付与するために、 LDAPグループ DN はロールとして MongoDB で作成されます。 LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。 |
設定 | 値 |
---|---|
Backup Username | Active Directory ユーザー名。 |
Backup Password | Active Directory のパスワード。 |
Domain | Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。 |
設定 | 値 |
---|---|
Backup Username | バックアップの PEM キー ファイルから生成された LDAP v3 識別名を入力します。 |
Backup PEM Key file | 適切なオペレーティング システムの行で、サーバー上のバックアップのPEMキー ファイルのパスとファイル名を指定します。 |
Backup PEM Key Password | PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。 |
Backup LDAP Group DN | バックアップのLDAPグループの識別名を入力します。 LDAP 認可を使用する場合は、バックアップの LDAP グループ DN を指定する必要があります。 |