Docs Menu
Docs Home
/
MongoDB Cloud Manager
/ /

API를 통한 cluster 배포

이 페이지의 내용

  • 전제 조건
  • 예제
  • cluster 생성 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 예제 페이지에서예제를 볼 수 있습니다.

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

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

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

2

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

3

/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"
}]
}'
1

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

2

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

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

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

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

1
  1. 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
  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 필드에 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 도 포함됩니다.

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

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

7

Cloud Manager에서 자동화 구성을 조회하고 변경 사항이 포함되어 있는지 확인합니다. 구성을 검색하려면 다음 명령을 실행하여 자리 표시자를 클러스터 생성 API 리소스용 변수로 바꿉니다.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true"
8

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].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}

Cloud Manager 콘솔에서 새 구성을 보려면 다음을 수행합니다.

  1. MongoDB Cloud Manager에서 프로젝트의 Deployment 페이지로 이동합니다.

    1. 이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.

    2. 아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.

    3. Deployment 페이지가 아직 표시되지 않은 경우 사이드바에서 Deployment를 클릭합니다.

      배포 페이지가 표시됩니다.

  2. 새 구성을 검토합니다.

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

돌아가기

Cloud Manager 관리 API 튜토리얼