Docs Menu
Docs Home
/
MongoDB Ops Manager
/ /

API를 통한 cluster 배포

이 페이지의 내용

  • 전제 조건
  • 예시
  • cluster 생성 API 리소스용 변수
  • 전제 조건
  • 절차
  • 다음 단계

이 튜토리얼에서는 MongoDB Ops Manager 관리 API 의 자동화 구성을 조작하여 다른 사용자가 소유한 샤딩된 클러스터 를 배포 합니다. 이 튜토리얼에서는 먼저 새 프로젝트 를 만든 다음 프로젝트 의 소유자인 새 사용자를 만든 다음 새 사용자가 소유한 샤딩된 클러스터 를 만듭니다. 스크립트 를 생성하여 일상적인 작업에서 사용할 수 있도록 이러한 절차를 자동화할 수 있습니다.

이 단계를 수행하려면 Ops Manager에 대한 충분한 액세스 권한이 있어야 합니다. Global Owner 또는 Project Owner 역할을 가진 사용자에게 충분한 액세스 권한이 있습니다.

이 절차에서는 두 개의 샤드 가 있는 클러스터를 설치합니다. 각 샤드는 3명의 멤버로 구성된 복제본 세트 로 구성됩니다. 이 튜토리얼에서는 mongos 1개와 config 서버 3개를 설치합니다. 클러스터의 각 구성 요소는 자체 서버에 상주하므로 총 10 호스트가 필요합니다.

이 튜토리얼에서는 각 호스트에 MongoDB Agent 를 설치합니다.

Ops Manager에는 기존 사용자가 있어야 합니다. Ops Manager를 새로 설치하는 경우 샤드 클러스터를 배포하는 경우 첫 번째 사용자를 등록해야 합니다.

MongoDB 에이전트 구성 파일의 mmsbaseURL 설정에 설정된 Ops Manager 호스트의 URL 이 있어야 합니다.

샤드 클러스터 의 구성 요소를 제공하기 위해 10개의 호스트를 프로비저닝합니다. 호스트 요구 사항은 MongoDB 매뉴얼의 프로덕션 노트 를 참조하세요.

각 호스트는 다른 모든 호스트에 있는 MongoDB Agent의 호스트 이름 및 포트에 대한 전체 네트워킹 액세스 권한을 해당 MongoDB Agent 에 제공해야 합니다. 각 에이전트는 hostname -f 명령을 실행하여 호스트 이름과 포트를 자체 식별하고 Ops Manager에 보고합니다.

에이전트가 서로 연결할 수 있도록 하려면 Automation 을 사용하여 호스트를 프로비저닝합니다. 이렇게 하면 올바른 네트워크 액세스로 MongoDB 에이전트가 설치됩니다. 이 튜토리얼을 사용하여 해당 머신에 Automation을 다시 설치하세요.

로 작업할 때 Github 예제 API페이지에서 예제를 볼 수 있습니다.

API 리소스는 이러한 변수 중 하나 이상을 사용합니다. 이러한 API 리소스를 호출하기 전에 이러한 변수를 원하는 값으로 바꿉니다.

이름
유형
설명
PUBLIC-KEY
문자열
API 자격 증명에 대한 공개 API 키입니다.
PRIVATE-KEY
문자열
API 자격 증명에 대한 비공개 API 키 입니다.
<OpsManagerHost>:<Port>
문자열
Ops Manager 인스턴스의 URL 입니다.
GROUP-ID
문자열
프로젝트 설정에 있는 프로젝트의 고유 식별자입니다.
1

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 는 프로젝트의 agentApiKeyid 를 포함하는 문서를 반환합니다.

2

이 절차와 이 튜토리얼의 다른 절차에서 사용할 수 있도록 이 값을 기록해 둡니다.

3

/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"
}]
}'
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.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가 사용자를 성공적으로 제거하면 APIHTTP 200 OK 상태 코드를 반환합니다.

1

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

2

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

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

배포를 추가하거나 업데이트하려면 구성 을 검색하고 필요에 따라 변경하고 업데이트된 구성을 API 를 통해 Ops Manager로 보냅니다.

다음 절차는 API 를 통해 업데이트된 자동화 구성을 배포합니다.

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

2

다음 필드가 있는 문서를 만듭니다. 구성 문서를 작성할 때 설정에 대한 자세한 설명은 자동화 구성 설명 을 참조하세요. 예시는 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}
3

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 도 포함됩니다.

4

이 샤드 클러스터에는 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]
5

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

예시

이 섹션은 첫 번째 복제본 세트 문서에 하나의 복제본 세트 멤버를 추가합니다.

중요

각 복제본 세트의 루트 문서에 "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 배열에서 샤드에 복제본 세트를 추가하고 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 }
18]
6

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 상태 코드를 반환합니다.

7

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"
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 이전의 한 버전을 실행 중임을 나타냅니다. 몇 초 정도 기다린 후 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}

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

cluster에서 MongoDB의 추가 버전을 사용할 수 있도록 하려면 배포의 MongoDB 버전 업데이트를 참조하세요.

돌아가기

Ops Manager 관리 API 튜토리얼