このチュートリアルでは、 MongoDB Ops Manager Administration APIのオートメーション構成を操作して、別のユーザーが所有するシャーディングされたクラスターを配置します。 このチュートリアルでは、最初に新しいプロジェクトを作成し、次にプロジェクトの所有者として新しいユーザーを作成し、次に新しいユーザーが所有するシャーディングされたクラスターを作成します。 スクリプトを作成して、ルーチン操作で使用するこれらの手順を自動化できます。
これらの手順を実行するには、 MongoDB Ops Managerへの十分なアクセス権が必要です。 Global OwnerまたはProject Ownerロールを持つユーザーには十分なアクセス権があります。
手順では、2 つのシャードを持つクラスターをインストールします。 各シャードは 3 つのメンバーのレプリカセットで構成されています。 このチュートリアルでは、1 つのmongosと 3 つのコンフィギュレーションサーバーをインストールします。 クラスターの各コンポーネントは独自のサーバー上に存在するため、合計で10のホストが必要です。
チュートリアルでは、各ホストにMongoDB Agentをインストールします。
前提条件
MongoDB Ops Manager には既存のユーザーが必要です。 MongoDB Ops Managerの新規インストールにシャーディングされたクラスターを配置する場合は、最初のユーザーを登録する必要があります。
MongoDB Agent 構成ファイル の mmsbaseurl 設定で設定されている MongoDB Ops Manager ホストの URL が必要です。
シャーディングされたクラスターのコンポーネントを提供するために 10 個のホストをプロビジョニングします。 ホスト要件については、MongoDB マニュアルの 「プロダクション ノート」を参照してください。
各ホストは、そのMongoDB Agentが、他のすべてのホスト上のMongoDB Agent のホスト名とポートへの完全なネットワークアクセスを提供する必要があります。 各エージェントは コマンドhostname -fを実行して、ホスト名とポートを自己識別し、それらを MongoDB Ops Manager に報告します。
Tip
エージェントが相互にアクセスできるようにするには、 オートメーション を使用してホストをプロビジョニングします。 これにより、正しいネットワーク アクセス権を持つ MongoDB エージェントがインストールされます。 このチュートリアルを使用して、それらのマシンにオートメーションを再インストールします。
例
APIを使用している場合は、 Github例ページ で例を表示できます。
クラスター作成 API リソースの変数
API リソースは、これらの変数の 1 つ以上を使用します。 これらの API リソースを呼び出す前に、これらの変数を目的の値に置き換えます。
名前 | タイプ | 説明 |
|---|---|---|
| string | API認証情報の公開 API キー。 |
| string | API 認証情報の プライベート API キー 。 |
| string | MongoDB Ops Manager インスタンスのURL 。 |
| string | プロジェクト設定からのプロジェクトの一意の識別子。 |
前提条件
API を使用できるようにするには、 API アクセスを設定します。
手順
API 経由でグループとユーザーを作成
API を使用してプロジェクトを作成します。
MongoDB Ops Manager Administration APIを使用して、新しいプロジェクトを作成するためのプロジェクトドキュメントを送信します。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \--header "Content-Type: application/json" \--request POST "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups?pretty=true" \--data ' { "name": "{GROUP-NAME}", "orgId": "{ORG-ID}" }'APIは、プロジェクトのagentApiKeyとidを含むドキュメントを返します。
API を使用して、新しいプロジェクトにユーザーを作成します。
/usersエンドポイントを使用して、新しいプロジェクトにユーザーを追加します。
リクエストの本文には、ユーザーの情報を含むユーザーJSONドキュメントが含まれている必要があります。
ユーザーのroles.roleNameをGROUP_OWNERに設定し、ユーザーのroles.groupIdを新しいグループのidに設定します。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Content-Type: application/json" \ --request POST "https://<OpsManagerHost>:<Port>/api/public/v1.0/users?pretty=true" \ --data ' { "username": "<new_user@example.com>", "emailAddress": "<new_user@example.com>", "firstName": "<First>", "lastName": "<Last>", "password": "<password>", "roles": [{ "groupId": "{PROJECT-ID}", "roleName": "GROUP_OWNER" }] }'（任意）グローバル所有者ユーザーを使用してプロジェクトを作成した場合は、そのユーザーをプロジェクトから削除できます。
プロジェクトの作成に使用するユーザーは、自動的にプロジェクトに追加されます。 Global Ownerロールを持つユーザーを使用した場合は、将来プロジェクトに変更を加える能力を失うことなく、そのユーザーをプロジェクトから削除できます。 プロジェクトのagentApiKeyとidがある限り、グローバル所有者としてログインすると、プロジェクトにフルアクセスできます。
GET グローバル所有者の ID。 次のコマンドを発行して、プロジェクトのユーザーにリクエストを送信します。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/users?pretty=true"APIは、プロジェクトの全ユーザーをリストしたJSONドキュメントを返します。roles.roleNameがGLOBAL_OWNERに設定されているユーザーを見つけます。ユーザーのid値をコピーし、以下を実行してプロジェクトからユーザーを除きます。その際、{USER-ID}をユーザーのid値に置き換えてください。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/users/{USER-ID}?pretty=true"MongoDB Ops Managerがユーザーを正常に削除した場合、APIはHTTP 200 OKステータスコードを返します。
プロビジョニングされた各ホストへの MongoDB Agent のインストール
各ホストで MongoDB Agent のインストール手順を完了します。
MongoDB Agent をインストールする方法については、適切なプラットフォームの手順に従ってください。
自動化構成の初期状態を確認します。
MongoDB Agent が初めて実行されると、自動化構成の目的の状態を記述するmms-cluster-config-backup.jsonファイルがダウンロードされます。
のホストの 1 つで、 に移動し、/var/lib/mongodb-mms-automation/ mms-cluster-config-backup.jsonを開きます。ファイルのversionフィールドが1に設定されていることを確認します。 MongoDB Ops Manager は、変更が発生するとこのフィールドを自動的に増加させます。
新しいクラスターの配置
配置を追加または更新するには、構成を取得し、必要に応じて変更を加え、更新された構成をAPI経由でMongoDB Ops Managerに送信します。
次の手順では、 APIを介して更新されたオートメーション構成を配置します。
MongoDB Ops Managerからオートメーション構成を取得します。
構成を取得するには、 automationConfigリソースを使用します。 次のコマンドを実行して、プレースホルダーをクラスター作成 API リソースの変数に置き換えます。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \ --output currentAutomationConfig.jsonダウンロードしたオートメーション構成ファイルを検証します。
currentAutomationConfig.jsonファイルとmms-cluster-config-backup.jsonファイルの内容が最新であることを確認します。mms-cluster-config-backup.jsonファイルは、MongoDB Agent を実行している任意のホスト上の次の場所にあります。Linux と macOS:
/var/lib/mongodb-mms-automation/mms-cluster-config-backup.jsonWindows:
%SystemDrive%\MMSAutomation\versions\mms-cluster-config-backup.json
新しいオートメーション構成の最上位レベルを作成します。
次のフィールドを含むドキュメントを作成します。構成ドキュメントを構築する際には、設定の詳細については、オートメーション構成の説明を参照してください。例については、 MongoDB Labs ページ を参照してください。
{ "options": { "downloadBase": "/var/lib/mongodb-mms-automation", }, "mongoDbVersions": [], "monitoringVersions": [], "backupVersions": [], "processes": [], "replicaSets": [], "sharding": []}モニタリングをオートメーション構成に追加します。
monitoringVersions.hostname フィールドに、 MongoDB Ops Managerがモニタリングをインストールするサーバーのホスト名を入力します。 次のように、サーバー上でhostname -fを実行すると返される完全修飾ドメイン名を使用します。
"monitoringVersions": [ { "hostname": "<server_x.example.com>", "logPath": "/var/log/mongodb-mms-automation/monitoring-agent.log", "logRotate": { "sizeThresholdMB": 1000, "timeThresholdHrs": 24 } }]この構成例には、ログの場所を指定するlogPathフィールドと、ログしきい値を指定するlogRotateも含まれています。
サーバーをオートメーション構成に追加します。
このシャーディングされたクラスターには、 API 経由でクラスターを配置する で説明されているように、それぞれが独自のサーバー上で実行されている10の MongoDB インスタンスがあります。 したがって、オートメーション構成のprocesses配列には、MongoDB インスタンスごとに 1 つずつ、 10ドキュメントが含まれます。
次の例では、 最初の ドキュメントをprocesses配列に追加します。 <process_name_1>を選択した任意の名前に置き換え、 <server1.example.com>をホストのFQDNに置き換えます。
シャーディングされたクラスター内の各 MongoDB インスタンスに対して 1 つずつ、9 つのドキュメントを追加します。
processes.<args>フィールドにargs2_6構文を指定します。 processes.args2_6オブジェクトは、MongoDB バージョン 2.6 以降のほとんどの MongoDB 設定とパラメータを受け入れます。 詳しくは、「 MongoDB 設定とオートメーション サポート 」を参照してください。
"processes": [ { "version": "4.0.6", "name": "<process_name_1>", "hostname": "<server1.example.com>", "logRotate": { "sizeThresholdMB": 1000, "timeThresholdHrs": 24 }, "authSchemaVersion": 5, "featureCompatibilityVersion": "4.0", "processType": "mongod", "args2_6": { "net": { "port": 27017 }, "storage": { "dbPath": "/data/" }, "systemLog": { "path": "/data/mongodb.log", "destination": "file" }, "replication": { "replSetName": "rs1" }, "sharding": { "clusterRole": "shardsvr" } } },]シャーディングされたクラスターのトポロジーをオートメーション構成に追加します。
2 つのレプリカセット ドキュメントをreplicaSets配列に追加します。 各ドキュメントに 3 つのメンバーを追加します。
例
このセクションでは、最初のレプリカセット ドキュメントに 1 つのレプリカセット メンバーを追加します。
重要
各レプリカセットのルート ドキュメントに"protocolVersion": 1を含める必要があります。
"replicaSets": [ { "_id": "rs1", "members": [ { "_id": 0, "host": "<process_name_1>", "priority": 1, "votes": 1, "secondaryDelaySecs": 0, "hidden": false, "arbiterOnly": false } ], "protocolVersion": 1 }]sharding配列で、次のようにレプリカセットをシャードに追加し、コンフィギュレーションサーバーのレプリカセット名を追加します。
"sharding": [ { "shards": [ { "tags": [], "_id": "shard1", "rs": "rs1" }, { "tags": [], "_id": "shard2", "rs": "rs2" } ], "name": "sharded_cluster_via_api", "configServerReplica": "rs-config" }]更新された自動化構成を送信します。
更新されたオートメーション構成を送信するには、 automationConfigリソースを使用します。
更新された構成ドキュメントへのパスを指定して次のコマンドを実行し、プレースホルダーをクラスター作成 API リソースの変数に置き換えます。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Content-Type: application/json" \ --request PUT "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \ --data @currentAutomationConfig.json構成の更新に成功すると、API はリクエストが成功したことを示す HTTP 200 OKステータス コードを返します。
オートメーション構成の更新が成功したことを確認します。
MongoDB Ops Managerからオートメーション構成を取得し、変更が含まれていることを確認します。 構成を取得するには、次のコマンドを実行して、プレースホルダーをクラスター作成 API リソースの変数に置き換えます。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true"構成の更新が配置されたことを確認します。
AutomationStatusリソースを使用して、構成更新が完全に配置されたことを確認します。 次のコマンドを発行します:
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationStatus?pretty=true"curl コマンドは、processes 配列と goalVersion キーと値を含む JSON オブジェクトを返します。processes 配列には、MongoDB インスタンスをホストする各サーバーのドキュメントが含まれています。processes 配列内のすべての lastGoalVersionAchieved フィールドが goalVersion に指定された値と等しくなると、新しい構成が正常に配置されます。
例
この応答では、 processes[2].lastGoalVersionAchievedはgoalVersionより遅れています。 これは、 server3.example.comの MongoDB インスタンスがgoalVersionより 1 つ前のバージョンを実行していることを示します。 数秒待ってからcurlコマンドを再度発行します。
{ "goalVersion": 2, "processes": [{ "hostname": "server1.example.com", "lastGoalVersionAchieved": 2, "name": "ReplSet_0", "plan": [] }, { "hostname": "server2.example.com", "lastGoalVersionAchieved": 2, "name": "ReplSet_1", "plan": [] }, { "hostname": "server3.example.com", "lastGoalVersionAchieved": 1, "name": "ReplSet_2", "plan":[] }]}MongoDB Ops Manager コンソールで新しい構成を表示するには、 Deploymentをクリックします。
次のステップ
クラスターで追加のバージョンの MongoDB を使用できるようにするには、「配置の MongoDB バージョンの更新 」を参照してください。