Docs Menu
Docs Home
/
MongoDB Ops Manager
/ /

API 経由でクラスターを配置

項目一覧

  • 前提条件
  • クラスター作成 API リソースの変数
  • 前提条件
  • 手順
  • 次のステップ

このチュートリアルでは、 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 リソースは、これらの変数の 1 つ以上を使用します。 これらの API リソースを呼び出す前に、これらの変数を目的の値に置き換えます。

名前
タイプ
説明
PUBLIC-KEY
string
API認証情報の公開 API キー。
PRIVATE-KEY
string
API 認証情報の プライベート API キー 。
<OpsManagerHost>:<Port>
string
MongoDB Ops Manager インスタンスのURL
GROUP-ID
string
プロジェクト設定からのプロジェクトの一意の識別子。
1

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は、プロジェクトのagentApiKeyidを含むドキュメントを返します。

2

この手順やこのチュートリアルの他の手順で使用するためにこれらの値を記録します。

3

/usersエンドポイントを使用して、新しいプロジェクトにユーザーを追加します。

リクエストの本文には、ユーザーの情報を含むユーザーJSONドキュメントが含まれている必要があります。

ユーザーのroles.roleNameGROUP_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"
}]
}'
4

プロジェクトの作成に使用するユーザーは、自動的にプロジェクトに追加されます。 Global Ownerロールを持つユーザーを使用した場合は、将来プロジェクトに変更を加える能力を失うことなく、そのユーザーをプロジェクトから削除できます。 プロジェクトのagentApiKeyidがある限り、グローバル所有者としてログインすると、プロジェクトにフルアクセスできます。

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.roleNameGLOBAL_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がユーザーを正常に削除すると、 APIHTTP 200 OK ステータス コードを返します。

1

MongoDB Agent をインストールする方法については、適切なプラットフォームの手順に従ってください。

2

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を介して更新されたオートメーション構成を配置します。

1
  1. 構成を取得するには、 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
  2. ダウンロードしたオートメーション構成ファイルを検証します。

    versioncurrentAutomationConfig.json フィールドと Automation Configuration バックアップ ファイルのmms-cluster-config-backup.json フィールドを比較します。version値は両方のJSONドキュメントの最後の要素です。 このファイルは、MongoDB Agent を実行しているホスト上の次の場所にあります。

    • Linux と macOS: /var/lib/mongodb-mms-automation/mms-cluster-config-backup.json

    • Windows: %SystemDrive%\MMSAutomation\versions\mms-cluster-config-backup.json

    version値が一致する場合は、現在のバージョンの Automation 構成ファイルを操作します。

2

次のフィールドを含むドキュメントを作成します。 構成ドキュメントを作成する際には、設定の詳細な説明については、オートメーション構成の説明を参照してください。 例については、 MongoDB Lambs ページ を参照してください。

1{
2 "options": {
3 "downloadBase": "/var/lib/mongodb-mms-automation",
4 },
5 "mongoDbVersions": [],
6 "monitoringVersions": [],
7 "backupVersions": [],
8 "processes": [],
9 "replicaSets": [],
10 "sharding": []
11}
3

monitoringVersions.hostname フィールドに、 MongoDB Ops Managerがモニタリングをインストールするサーバーのホスト名を入力します。 次のように、サーバー上でhostname -fを実行すると返される完全修飾ドメイン名を使用します。

1"monitoringVersions": [
2 {
3 "hostname": "<server_x.example.com>",
4 "logPath": "/var/log/mongodb-mms-automation/monitoring-agent.log",
5 "logRotate": {
6 "sizeThresholdMB": 1000,
7 "timeThresholdHrs": 24
8 }
9 }
10]

この構成例には、ログの場所を指定するlogPathフィールドと、ログしきい値を指定するlogRotateも含まれています。

4

このシャーディングされたクラスターには、 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 設定とオートメーション サポート 」を参照してください。

1"processes": [
2 {
3 "version": "4.0.6",
4 "name": "<process_name_1>",
5 "hostname": "<server1.example.com>",
6 "logRotate": {
7 "sizeThresholdMB": 1000,
8 "timeThresholdHrs": 24
9 },
10 "authSchemaVersion": 5,
11 "featureCompatibilityVersion": "4.0",
12 "processType": "mongod",
13 "args2_6": {
14 "net": {
15 "port": 27017
16 },
17 "storage": {
18 "dbPath": "/data/"
19 },
20 "systemLog": {
21 "path": "/data/mongodb.log",
22 "destination": "file"
23 },
24 "replication": {
25 "replSetName": "rs1"
26 }
27 }
28 },
29]
5

2 つのレプリカセット ドキュメントをreplicaSets配列に追加します。 各ドキュメントに 3 つのメンバーを追加します。

このセクションでは、最初のレプリカセット ドキュメントに 1 つのレプリカセット メンバーを追加します。

重要

各レプリカセットのルート ドキュメントに"protocolVersion": 1を含める必要があります。

1"replicaSets": [
2 {
3 "_id": "rs1",
4 "members": [
5 {
6 "_id": 0,
7 "host": "<process_name_1>",
8 "priority": 1,
9 "votes": 1,
10 "secondaryDelaySecs": 0,
11 "hidden": false,
12 "arbiterOnly": false
13 }
14 ],
15 "protocolVersion": 1
16 }
17]

sharding配列で、次のようにレプリカセットをシャードに追加し、コンフィギュレーションサーバーのレプリカセット名を追加します。

1"sharding": [
2 {
3 "shards": [
4 {
5 "tags": [],
6 "_id": "shard1",
7 "rs": "rs1"
8 },
9 {
10 "tags": [],
11 "_id": "shard2",
12 "rs": "rs2"
13 }
14 ],
15 "name": "sharded_cluster_via_api",
16 "configServerReplica": "rs-config"
17 }
18]
6

更新されたオートメーション構成を送信するには、 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ステータス コードを返します。

7

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"
8

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].lastGoalVersionAchievedgoalVersionより遅れています。 これは、 server3.example.comの MongoDB インスタンスがgoalVersionより 1 つ前のバージョンを実行していることを示します。 数秒待ってからcurlコマンドを再度発行します。

1{
2 "goalVersion": 2,
3 "processes": [{
4 "hostname": "server1.example.com",
5 "lastGoalVersionAchieved": 2,
6 "name": "ReplSet_0",
7 "plan": []
8 }, {
9 "hostname": "server2.example.com",
10 "lastGoalVersionAchieved": 2,
11 "name": "ReplSet_1",
12 "plan": []
13 }, {
14 "hostname": "server3.example.com",
15 "lastGoalVersionAchieved": 1,
16 "name": "ReplSet_2",
17 "plan":[]
18 }]
19}

コンソールで新しい構成を表示するには、{0MongoDB Ops Manager Deploymentをクリックします。

クラスターで追加のバージョンの MongoDB を使用できるようにするには、「配置の MongoDB バージョンの更新 」を参照してください。

戻る

MongoDB Ops Manager Administration APIチュートリアル