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を含むドキュメントを返します。

返されたドキュメントに 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 が初めて実行されると、自動化構成の目的の状態を記述するmms-cluster-config-backup.jsonファイルがダウンロードされます。

のホストの 1 つで、 に移動し、/var/lib/mongodb-mms-automation/ mms-cluster-config-backup.jsonを開きます。ファイルのversionフィールドが1に設定されていることを確認します。 MongoDB Ops Manager は、変更が発生するとこのフィールドを自動的に増加させます。

MongoDB Ops Managerからオートメーション構成を取得します。

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

   versionのcurrentAutomationConfig.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 構成ファイルを操作します。

新しいオートメーション構成の最上位レベルを作成します。

次のフィールドを含むドキュメントを作成します。 構成ドキュメントを作成する際には、設定の詳細な説明については、オートメーション構成の説明を参照してください。 例については、 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
}

モニタリングをオートメーション構成に追加します。

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も含まれています。

サーバーをオートメーション構成に追加します。

このシャーディングされたクラスターには、 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
]

シャーディングされたクラスターのトポロジーをオートメーション構成に追加します。

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

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
]

更新された自動化構成を送信します。

更新されたオートメーション構成を送信するには、 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に指定された値と等しい場合、新しい構成は正常に配置されます。

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をクリックします。