API를 통한 cluster 배포
- Cloud Manager 에 대한 프로그래밍 방식의 액세스 를 위한 OAuth 2.0 인증 은 Preview 기능 으로 제공됩니다.
- 기능 및 해당 설명서는 미리 보기 기간에 언제든지 변경될 수 있습니다. OAuth 2.0 인증 을 사용하려면 Cloud Manager 공개 API 에 대한 요청에 사용할서비스 계정을 만듭니다.
이 튜토리얼에서는 Cloud Manager 관리 API의 자동화 구성을 조작하여 다른 사용자가 소유한 샤딩된 클러스터 를 배포 합니다. 이 튜토리얼에서는 먼저 새 프로젝트 를 만든 다음 프로젝트 의 소유자인 새 사용자를 만든 다음 새 사용자가 소유한 샤딩된 클러스터 를 만듭니다. 스크립트 를 생성하여 일상적인 작업에서 사용할 수 있도록 이러한 절차를 자동화할 수 있습니다.
이 단계를 수행하려면 Cloud Manager에 대한 충분한 액세스 권한이 있어야 합니다. Project Owner
역할을 가진 사용자에게 충분한 액세스 권한이 있습니다.
이 절차에서는 두 개의 샤드 가 있는 클러스터를 설치합니다. 각 샤드는 3명의 멤버로 구성된 복제본 세트 로 구성됩니다. 이 튜토리얼에서는 mongos
1개와 config 서버 3개를 설치합니다. 클러스터의 각 구성 요소는 자체 서버에 상주하므로 총 10 호스트가 필요합니다.
이 튜토리얼에서는 각 호스트에 MongoDB Agent 를 설치합니다.
전제 조건
샤드 클러스터 의 구성 요소를 제공하기 위해 10개의 호스트를 프로비저닝합니다. 호스트 요구 사항은 MongoDB 매뉴얼의 프로덕션 노트 를 참조하세요.
각 호스트는 다른 모든 호스트에 있는 MongoDB Agent의 호스트 이름 및 포트에 대한 전체 네트워킹 액세스 권한을 해당 MongoDB Agent 에 제공해야 합니다. 각 에이전트는 hostname -f
명령을 실행하여 호스트 이름과 포트를 자체 식별하고 Cloud Manager에 보고합니다.
팁
에이전트가 서로 연결할 수 있도록 하려면 Automation 을 사용하여 호스트를 프로비저닝합니다. 이렇게 하면 올바른 네트워크 액세스로 MongoDB 에이전트가 설치됩니다. 이 튜토리얼을 사용하여 해당 머신에 Automation을 다시 설치하세요.
예시
로 작업할 때 API Github 예제 페이지에서예제를 볼 수 있습니다.
cluster 생성 API 리소스용 변수
API 리소스는 이러한 변수 중 하나 이상을 사용합니다. 이러한 API 리소스를 호출하기 전에 이러한 변수를 원하는 값으로 바꿉니다.
이름 | 유형 | 설명 |
---|---|---|
| 문자열 | API 자격 증명에 대한 공개 API 키입니다. |
| 문자열 | API 자격 증명에 대한 비공개 API 키 입니다. |
| 문자열 | Cloud Manager 인스턴스의 URL 입니다. |
| 문자열 | 프로젝트 설정에 있는 프로젝트의 고유 식별자입니다. |
전제 조건
API를 사용할 수 있도록 API 액세스를 구성합니다 .
절차
API를 통해 그룹 및 사용자 생성
API를 사용하여 프로젝트를 만듭니다.
Cloud Manager 관리 API를 사용하여 프로젝트 문서를 전송하여 새 프로젝트를 생성합니다.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Content-Type: application/json" \ --request POST "https://cloud.mongodb.com/api/public/v1.0/groups?pretty=true" \ --data ' { "name": "{GROUP-NAME}" }'
API 는 프로젝트의 agentApiKey
및 id
를 포함하는 문서를 반환합니다.
반환 문서 agentApiKey
에 및 id
값을 기록합니다.
이 절차와 이 튜토리얼의 다른 절차에서 사용할 수 있도록 이 값을 기록해 둡니다.
API를 사용하여 새 프로젝트에서 사용자를 만듭니다.
/users
엔드포인트를 사용하여 새 프로젝트에 사용자를 추가합니다.
요청 본문에는 사용자 정보가 포함된 사용자 JSON 문서가 포함되어야 합니다.
사용자의 roles.roleName
을(를) GROUP_OWNER
(으)로 설정하고, 사용자의 roles.groupId
을(를) 새 그룹의 id
으)로 설정합니다.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header 'Accept: application/json' \ --header "Content-Type: application/json" \ --request POST "https://cloud.mongodb.com/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" }] }'
프로비저닝된 각 호스트에 MongoDB Agent 설치
각 호스트에서 MongoDB Agent 설치 절차를 완료합니다.
MongoDB 에이전트 설치 방법을 알아보려면 해당 플랫폼에 대한 절차를 따르세요.
자동화 구성의 초기 상태를 확인합니다.
MongoDB Agent가 처음 실행되면 원하는 자동화 구성상태를 설명하는 mms-cluster-config-backup.json
파일을 다운로드합니다.
호스트 중 하나에서 /var/lib/mongodb-mms-automation/
을(를) 엽니다.mms-cluster-config-backup.json
파일의 version
필드가 1
으로 설정되어 있는지 확인합니다. Cloud Manager는 변경 사항이 발생하면 이 필드를 자동으로 증가시킵니다.
새 cluster 배포
배포를 추가하거나 업데이트하려면 구성 을 검색하고 필요에 따라 변경하고 업데이트된 구성을 API 를 통해 Cloud Manager로 보냅니다.
다음 절차는 API 를 통해 업데이트된 자동화 구성을 배포합니다.
Cloud Manager에서 자동화 구성을 조회하고 유효성을 검사합니다.
AutomationConfig 리소스를 사용하여 구성을 검색합니다. 다음 명령을 실행하여 자리 표시자를 cluster 생성 API 리소스용 변수로 바꿉니다.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \ --output currentAutomationConfig.json 다운로드한 자동화 구성 파일의 유효성을 검사합니다.
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
필드에 Cloud 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
배열에 추가합니다. 각 문서에 세 명의 멤버를 추가합니다.
예시
이 섹션은 첫 번째 복제본 세트 문서에 하나의 복제본 세트 멤버를 추가합니다.
중요
각 복제본 세트의 루트 문서에 "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 "collections": [] 18 } 19 ]
업데이트된 자동화 구성을 보냅니다.
AutomationConfig 리소스를 사용하여 업데이트된 자동화 구성을 보냅니다.
업데이트된 구성 문서의 경로와 함께 다음 명령을 실행하고 자리 표시자를 cluster 생성 API 리소스에 대한 변수로 바꿉니다.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Content-Type: application/json" --request PUT "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \ --data @currentAutomationConfig.json
구성이 성공적으로 업데이트되면 API는 요청이 성공했음을 나타내는 HTTP 200 OK
상태 코드를 반환합니다.
구성 업데이트가 배포되었는지 확인합니다.
AutomationStatus 리소스를 사용하여 구성 업데이트가 완전히 배포되었는지 확인합니다. 다음 명령을 실행합니다.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --request GET "https://cloud.mongodb.com/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
이전의 한 버전을 실행 중임을 나타냅니다. 몇 초 정도 기다린 후 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 }
Cloud Manager 콘솔에서 새 구성을 보려면 다음을 수행합니다.
MongoDB Cloud Manager 에서 프로젝트 의 Deployment 페이지로 Go 합니다.
이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.
아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.
Deployment 페이지가 아직 표시되지 않은 경우 사이드바에서 Deployment를 클릭합니다.
배포 페이지가 표시됩니다.
새 구성을 검토합니다.
다음 단계
cluster에서 MongoDB의 추가 버전을 사용할 수 있도록 하려면 배포의 MongoDB 버전 업데이트를 참조하세요.