Distribuir um cluster por meio da API

Use a API para criar um projeto.

Use a API de administração do Ops Manager para enviar um documento de projetos para criar o novo projeto.

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}"
  }'

A API retorna um documento que inclui o agentApiKey e o id do projeto.

Registre os valores de agentApiKey e id no documento retornado.

Registre esses valores para uso neste procedimento e em outros procedimentos deste tutorial.

Use a API para criar um usuário no novo projeto.

Use o endpoint /users para adicionar um usuário ao novo projeto.

O corpo da solicitação deve conter um documento JSON do usuário com as informações do usuário.

Defina o do usuário roles.roleName como GROUP_OWNER e o do usuário roles.groupId como o do novoid grupo.

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

(Opcional) Se você usou um usuário proprietário global para criar o projeto, poderá remover esse usuário do projeto.

O usuário que você utiliza para criar o projeto é automaticamente adicionado ao projeto. Se você utilizou um usuário com a função Global Owner , poderá removê-lo do projeto sem perder a capacidade de fazer alterações no projeto no futuro. Desde que você tenha os agentApiKey e id do projeto, você terá acesso total ao projeto quando estiver conectado como o proprietário global.

GET o ID do proprietário global. Emitir o seguinte comando para solicitar aos usuários do projeto:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/users?pretty=true"

A API retorna um documento JSON que lista todos os usuários do projeto. Localize o usuário com roles.roleName definido como GLOBAL_OWNER. Copie o valor id do usuário e emita o seguinte para remover o usuário do projeto, substituindo {USER-ID} pelo valor id do usuário:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/users/{USER-ID}?pretty=true"

Se o Ops Manager remover o usuário com sucesso, a API retornará o código de status HTTP 200 OK .

Conclua o procedimento de instalação do MongoDB Agent em cada host.

Para aprender como instalar o MongoDB Agent, siga o procedimento para a plataforma apropriada.

Confirme o estado inicial da configuração da automação.

Quando o MongoDB Agent é executado pela primeira vez, ele baixa o arquivo mms-cluster-config-backup.json , que descreve o estado desejado da configuração de automação.

Em um dos hosts, navegue até /var/lib/mongodb-mms-automation/ e abra mms-cluster-config-backup.json. Confirme se o campo version do arquivo está definido como 1. O Ops Manager incrementa automaticamente este campo à medida que as alterações ocorrem.

Recupere a configuração de automação do Ops Manager.

1. Use o recurso automationConfig para recuperar a configuração. Emita o seguinte comando, substituindo os espaços reservados pelos variáveis para recursos de API de criação de cluster.

   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. Valide o arquivo de configuração de automação baixado.

   Compare o campo version do currentAutomationConfig.json com o do arquivo de backup da Configuração de Automação, mms-cluster-config-backup.json. O valor version é o último elemento em ambos os documentos JSON . Você pode encontrar este arquivo em qualquer host que execute o MongoDB agente em:

   • Linux e macOS: /var/lib/mongodb-mms-automation/mms-cluster-config-backup.json

   • Windows: %SystemDrive%\MMSAutomation\versions\mms-cluster-config-backup.json

   Se os valores version corresponderem, você estará trabalhando com a versão atual do arquivo de configuração de automação.

Crie o nível superior da nova configuração de automação.

Crie um documento com os seguintes campos. Ao criar o documento de configuração, consulte a descrição de uma configuração de automação para obter explicações detalhadas das configurações. Para obter exemplos, consulte a página Laboratórios do 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
}

Adicione o Monitoramento à configuração de automação.

No campo monitoringVersions.hostname , insira o nome do host do servidor onde o Ops Manager deve instalar o monitoramento. Use o nome de domínio totalmente qualificado que a execução hostname -f no servidor retorna, como a seguir:

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
]

Este exemplo de configuração também inclui o campo logPath , que especifica o local do registro, e logRotate, que especifica os limites do registro.

Adicione os servidores à configuração de automação.

Esse cluster fragmentado tem 10 instâncias do MongoDB, conforme descrito em Implementar um cluster por meio da API, cada uma executada em seu próprio servidor. Assim, a matriz processes da configuração de automação terá 10 documentos, um para cada instância do MongoDB.

O exemplo a seguir adiciona o primeiro documento à array processes . Substitua <process_name_1> por qualquer nome que você escolher e substitua <server1.example.com> pelo FQDN do host.

Adicione 9 documentos: um para cada instância do MongoDB em seu cluster fragmentado.

Especifique a sintaxe args2_6 para o campo processes.<args> . O objeto processes.args2_6 aceita a maioria das configurações e parâmetros do MongoDB para as versões 2.6 e posterior do MongoDB. Para saber mais, consulte Configurações do MongoDB e suporte de automação.

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
]

Adicione a topologia do cluster fragmentado à configuração de automação.

Adicione dois documentos de conjunto de réplicas à array replicaSets . Adicione três membros a cada documento.

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
]

Na array sharding , adicione os conjuntos de réplicas aos shards e adicione o nome do conjunto de réplicas do servidor de configuração, como no exemplo a seguir:

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
]

Envie a configuração de automação atualizada.

Use o recurso automationConfig para enviar a configuração de automação atualizada.

Emita o comando a seguir pelo caminho para o documento de configuração atualizado e substitua os espaços reservados pelas variáveis para recursos de API de criação de cluster.

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

Após a atualização bem-sucedida da configuração, a API retorna o código de status HTTP 200 OK para indicar que a solicitação foi bem-sucedida.

Confirme a atualização bem-sucedida da configuração de automação.

Recupere a configuração de automação do Ops Manager e confirme se ela contém as alterações. Para recuperar a configuração, emita o seguinte comando, substituindo os espaços reservados pelas variáveis para recursos de API de criação de cluster.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true"

Verifique se a atualização de configuração foi distribuída.

Use o recurso automationStatus para verificar se a atualização de configuração está totalmente distribuída. Emitir o seguinte comando:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/groups/{PROJECT-ID}/automationStatus?pretty=true"

O comando curl retorna um objeto JSON contendo a array processes e a chave goalVersion e o valor. A matriz processes contém um documento para cada servidor que hospeda uma instância MongoDB. A nova configuração é implantada com êxito quando todos os campos lastGoalVersionAchieved na matriz processes são iguais ao valor especificado para 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
}

Para visualizar a nova configuração no console do Ops Manager, clique em Deployment.