オートメーション
項目一覧
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
Cloud Manager Automation を使用すると、Cloud Manager UI を使用して MongoDB 配置を配置、構成、および管理できます。 Cloud Manager Automation は MongoDB Agent に依存します。このエージェントは、配置内のすべてのサーバーにインストールする必要があります。 MongoDB エージェントは定期的に Cloud Manager サービスをポーリングして現在のターゲットを決定し、そのステータスを Cloud Manager に継続的に報告します。
オートメーションは 64 ビットのアーキテクチャでのみ実行
Cloud Manager では、MongoDB Agent の 64 ビットのダウンロードのみを提供します。
独自のハードウェアの使用
オートメーションを手動で配置する場合は、すべてのサーバー上に 1 つの MongoDB Agent があることを確認してください。
エージェントを手動で配置する場合は、MongoDB の
dbPathと MongoDB バイナリのディレクトリを作成し、 エージェントを実行するユーザーがこれらのディレクトリを所有するようにする必要があります。rpmパッケージを使用してインストールすると、エージェントはmongodユーザーとして実行されます。debパッケージを使用する場合、エージェントはmongodbユーザーとして実行されます。tar.gzアーカイブ ファイルを使用してインストールする場合は、任意のユーザーとしてエージェントを実行できます。
ネットワーキング
MongoDB ポートへの接続
すべてのホストは MongoDB ポート間の通信を許可できる必要があります。 デフォルトは27017ですが、Cloud Manager インターフェースで代替のポート範囲を構成できます。
MongoDB Agent はポート443上のcloud.mongodb.comに接続できる必要があります（ HTTPS ）。 ポートと IP アドレスへのアクセスの詳細については、「セキュリティの概要 」を参照してください。
クラスター内接続の問題
ローリング更新を実行する場合、MongoDB Agent はダウンタイムを回避しようとします。 クラスターの他のノードから状態を収集する必要があります。 ホスト名の解決やファイアウォールの設定の誤りなど、接続の問題（ mongodからmongosの間）により、MongoDB Agent がリモート プロセスの状態を決定し、変更を完了できない可能性があります。
クラスターのすべてのノードが相互に通信できるようにするには、次の操作を実行します。
頻繁にオートメーション接続を行う
MongoDB Agent は、クラスターの各ノードから 10 秒ごとに状態を収集し、環境が期待どおりの状態になることを確認します。 この評価の一部として、MongoDB Agent は接続を作成し、特定のファイルをチェックして状態を判断し、接続を閉じます。 このような頻繁で短時間の接続は MongoDB Agent のルーチン アクティビティの一部であり、パフォーマンスには影響しません。
オートメーション構成
自動化構成が完了したら、配置プランが配置のニーズを満たしていることを確認します。 配置を確認する前に、ホスト名とポートを確認してください。
サイズ設定
MongoDB を実行し、データセットの要件をサポートするのに十分なスペースのあるホストをプロビジョニングすることを確認します。
配置を実行するのに十分な数のホストをプロビジョニングしたことを確認します。 各
mongodは独自のホスト上で実行する必要があります。
頻繁に接続タイムアウトを行う
MongoDB Agent は、次の 1 つ以上の理由で、接続を頻繁にタイムアウトすることがあります。
接続タイムアウト
高ネットワーク レイテンシ
高負荷
大きな SSL キー
CPU 速度が不十分
デフォルトでは、接続は 40 秒後にタイムアウトします。 MongoDB では、接続タイムアウトが頻繁に発生するのを防ぐために、 dialTimeoutSeconds MongoDB Agent の構成設定の値を徐々に増やしていくことをお勧めします。 ただし、この値を増やすと、将来の構成変更の配置に必要な時間も長くなります。 配置に最適な値を決定するまで、小さなインクリメンタル 増加 を試してください。
詳しくは、MongoDB Agent 接続設定のdialTimeoutSecondsを参照してください。
配置
特定の条件が適用されると、 We have detected a potential problem while deploying...を表示するバナーが表示されます。 以下はその例です。
配置の変更が完了できない、または進行しない
配置を追加または再起動し、配置が数分間In Progress状態のままの場合、バナーが表示されます。
この時点で、次の 4 つのオプションがあります。
[View Diagnostics] をクリックします。
View Diagnosticsモーダルには、デプロイ中に発生した可能性のあるエラーが表示されます。
[View Status] をクリックします。
Automation Statusモーダルには、配置プロセス、配置ステータス、完了しようとするタスク、配置ステータスが最後に報告された日時の配置プロセスが表示されます。 次の方法で結果をフィルタリングできます。
Filter processes検索バーにホスト名を入力します。
Process Typeドロップダウンから 1 つ以上のプロセスタイプを選択します。
Automation Stateドロップダウンから 1 つ以上のオートメーション状態を選択します。
個々のプロセスのステータスの詳細については、省略記号アイコンをクリックし、 View DetailsまたはView Agent Logsのいずれかを選択します。
View Details は、プロセスのどの配置プランであり、MongoDB Agent が現在そのプランのどのステージにあるかを示します。
View Agent Logs 新しいブラウザ ウィンドウが開きますDeployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。
[View Agent Logs] をクリックします。
新しいブラウザ ウィンドウが開き、 Deployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。
[Allow Override & Edit Configuration] をクリックします。
エラーを診断し、配置構成を修正する必要がある場合は、配置を編集する手順に従ってください。
配置をシャットダウンしても解決策が見つからない場合は、Cloud Manager から配置を削除してください。
MongoDB エージェントがダウンしているか通信していない
If Automation Module of MongoDB Agent can't communicate with the Cloud Manager API endpoint or the MongoDB Server processes, Cloud Manager displays a warning banner in the Project. これは、MongoDB エージェントが通信することが予想されているかどうかに応じて、2 つの方法のいずれかで解決できます。
MongoDB エージェントは通信する必要があります
MongoDB Agent が Cloud Manager ホストまたは MongoDB インスタンスと通信する必要がある場合は、各 MongoDB Agent について次の点を確認してください。
エージェントが各ホスト上で稼働中であること。
エージェントと Cloud Manager API エンドポイントは通信できます。
MongoDB エージェントは通信する必要はありません
MongoDB Agentのオートメーション モジュールがCloud Manager API endpointまたはMongoDB Serverプロセスと通信する必要がある場合は、 MongoDB Serverの自動配置ごとに次の点を確認します。
MongoDB Agent の権限
権限の問題により、オートメーションによる変更が完了しない可能性があります。 または View StatusView Diagnosticsが権限関連のエラー（open /data/db/mongod.lock:
permission denied など）を報告した場合は、MongoDB Agent ユーザーが ファイルとdbpathlogpath ファイルを所有し、読み取りおよび書込み権限があることを確認します。
問題のある MongoDB ホストの排除
コンソールまたはAPIを使用して、古くなった、壊れた、または問題のあるホストをオートメーションから排除できます。 これには、 MongoDB Agent にアクセスできない環境が含まれる場合があります。
コンソールを使用して問題のあるホストを削除するには、以下の手順に従います。
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processesページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
ホストを削除します。
問題が発生しているホストを見つけます。
をクリックします、次にRemove Server 。
Cloud Manager にAre you sure you want to remove this server>モーダルが表示されます。
このサーバーを削除する場合は、指定されたホスト名をEnter the host nameフィールドに入力し、 Removeをクリックします。
警告
Removeをクリックすると、Cloud Manager はこのホストのすべてのモニタリング データを削除します。 Cloud Manager は、このアクションの確認またはキャンセルを提供しません。
サーバーを削除しない場合は、 Cancelをクリックします。
変更内容を確認するには、 Review & Deployをクリックします。
Cloud Manager に推奨される変更が表示されます。
問題がなければ、[ Confirm & Deploy ] をクリックします。
Cloud Manager はこの時点ですべてのプロセスとエージェントを削除します。
さらに設定変更を行う場合は、[ Cancel ] をクリックします。
APIを使用して問題のあるホストを削除するには、次の手順に従います。
オートメーション構成のJSONファイルを編集します。
数分間待ちます。
MongoDB Cloud Managerで、プロジェクトの Deployment ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
配置の [ Agents ] タブをクリックします。
[エージェント ]ページが表示されます。
ホストがエージェントのリストに表示されなくなったことを確認します。
TLS 証明書にサブジェクト代替名が含まれていることを確認する
警告
バージョン 11.11.0.7349-1からの MongoDB Agent では、 サブジェクト代替名 フィールドに値を含めるためにTLS証明書が必要です。 MongoDB Agent 11.11.0.7355以降にアップグレードする前に、MongoDB 配置で使用されているすべてのTLS証明書にSANが含まれていることを確認してください。 [1]
| [1] | MongoDB は MongoDB Agent を Go 言語で記述しました。 Go1.17 で X509 を使用する機能が削除されました。 CommonName フィールドがホスト名 として SAN が存在しない場合。クライアントが TLS 証明書を検証するときに、クライアントは、証明書の SAN またはサブジェクト識別名（DN）フィールドの値から証明書が適用されるホスト名を確認します。TLS証明書を作成するときに、ホスト名を保存するために CN（サブジェクトコモンネーム）フィールドを使用する人もあります。 CN には制限があるため、ホスト名を保存するには適していません。 これらの制限には、 64文字の最大長と 名前制約 のサポートがないことが含まれます。 RFC2818 は CN を使用してホスト名を保存することで非2000 になりました。この RFC では、証明書のSANフィールドに値がない場合、クライアントは CN にフォールバックする必要があります。 RFC6125 は2011 .Go1 で要件を削除しました。15RFC2818 への準拠を無効にします であり、 6125RFC を使用しています。 CN を任意にする仕組みです。実際には、この変更にはSAN値を追加するか、 CNs.Go 1の使用を有効にする必要があります。 17 SAN が存在しない場合に CN を使用する回避策を廃止します。MongoDB Agent の現在のバージョンでは、 SAN を使用する 必要 があります。詳細については 、このトピックに関する Fluser Twift のブログ記事 を 参照してください。 |
既存のクラスターのメモリに構成ファイルを保存する
Cloud Manager バージョン 4.2 またはバージョン 4.4.0 - 4.4.6 を使用する場合、 enableLocalConfigurationServerをtrueに設定して MongoDB Agent を再起動すると、 エラーが発生する可能性があります。
この問題は、クラスターの作成後にenableLocalConfigurationServerがtrueに設定されている既存のクラスターにのみ影響します。 クラスターを作成する前にこの値を設定しても、この問題はtriggerされません。
既存のクラスターのこの設定を安全に変更するには、次の手順に従います。
MongoDB Agent の構成ファイルの末尾に、次のコマンドを追加します。
enableLocalConfigurationServer=true MongoDB Agent によって管理されている各プロセスをシャットダウンします。
次のコマンドを実行して MongoDB Agent を再起動します。
service mongodb-mms-automation-agent restart シャットダウンした MongoDB プロセスを再起動します。
automation-mongod.confファイルに__rest展開ディレクティブがあることを確認します。
メモリに構成ファイルを保存する方法の詳細については、「 MongoDB Agent が構成ファイルとパスワードを管理する方法を構成する 」を参照してください。