API를 통한 cluster 배포

API를 사용하여 프로젝트를 만듭니다.

Ops Manager 관리 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"

Ops Manager가 사용자를 성공적으로 제거하면 API 는 HTTP 200 OK 상태 코드를 반환합니다.

각 호스트에서 MongoDB Agent 설치 절차를 완료합니다.

MongoDB 에이전트 설치 방법을 알아보려면 해당 플랫폼에 대한 절차를 따르세요.

자동화 구성의 초기 상태를 확인합니다.

MongoDB Agent가 처음 실행되면 원하는 자동화 구성상태를 설명하는 mms-cluster-config-backup.json 파일을 다운로드합니다.

호스트 중 하나에서 /var/lib/mongodb-mms-automation/ 을(를) 엽니다.mms-cluster-config-backup.json 파일의 version 필드가 1 으로 설정되어 있는지 확인합니다. Ops Manager는 변경 사항이 발생하면 이 필드를 자동으로 증가시킵니다.

Ops Manager에서 자동화 구성을 조회합니다.

1. AutomationConfig 리소스를 사용하여 구성을 검색합니다. 다음 명령을 실행하여 자리 표시자를 cluster 생성 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. 다운로드한 자동화 구성 파일의 유효성을 검사합니다.

   currentAutomationConfig.json 의 version 필드와 자동화 구성 백업 파일 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 값이 일치하면 자동화 구성 파일의 현재 버전으로 작업하고 있는 것입니다.

새 자동화 구성의 최상위 수준을 만듭니다.

다음 필드가 있는 문서를 만듭니다. 구성 문서를 작성할 때 설정에 대한 자세한 설명은 자동화 구성 설명 을 참조하세요. 예시는 MongoDB 랩 페이지를 참조하세요.

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 필드에 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 인스턴스당 하나씩 10 개의 문서가 있습니다.

다음 예제에서는 첫 번째 문서를 processes 배열에 추가합니다. <process_name_1> 을 선택한 이름으로 바꾸고 <server1.example.com> 를 호스트의 FQDN 으로 바꿉니다.

9개의 문서를 추가합니다(샤드 클러스터의 각 MongoDB 인스턴스당 하나씩).

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
]

자동화 구성에 샤드 cluster 토폴로지를 추가합니다.

두 개의 복제본 세트 문서를 replicaSets 배열에 추가합니다. 각 문서에 세 명의 멤버를 추가합니다.

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 배열에서 샤드에 복제본 세트를 추가하고 config 서버 복제본 세트 이름을 추가합니다.

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
    "collections": []
18
  }
19
]

업데이트된 자동화 구성을 보냅니다.

AutomationConfig 리소스를 사용하여 업데이트된 자동화 구성을 보냅니다.

업데이트된 구성 문서의 경로와 함께 다음 명령을 실행하고 자리 표시자를 cluster 생성 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 상태 코드를 반환합니다.

자동화 구성이 성공적으로 업데이트되었는지 확인합니다.

Ops Manager에서 자동화 구성을 검색하고 변경 사항이 포함되어 있는지 확인합니다. 구성을 검색하려면 다음 명령을 실행하여 자리 표시자를 cluster 생성 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
}

Ops Manager 콘솔에서 새 구성을 보려면 Deployment 을(를) 클릭합니다.