Menu Docs
Página inicial do Docs
/
MongoDB Ops Manager
/ /

Distribuir um cluster por meio da API

Nesta página

  • Pré-requisitos
  • Exemplos
  • Variáveis para recursos de API de criação de cluster
  • Pré-requisitos
  • Procedimentos
  • Próximos passos

Este tutorial manipula a configuração de automação dadeMongoDB Ops Manager administração para implantar um API cluster fragmentado que pertence a outro usuário. O tutorial primeiro cria um novo projeto, depois um novo usuário como proprietário do projeto e, em seguida, um cluster fragmentado de propriedade do novo usuário. Você pode criar um script para automatizar esses procedimentos para uso em operações de rotina.

Para executar estas etapas, você deve ter acesso suficiente ao Ops Manager. Um usuário com a função Global Owner ou Project Owner tem acesso suficiente.

Os procedimentos instalam um cluster com dois fragmentos. Cada shard compreende um conjunto de réplicas de três membros. O tutorial instala um mongos e três servidores de configuração. Cada componente do cluster reside em seu próprio servidor, exigindo um total de 10 hosts.

O tutorial instala o MongoDB Agent em cada host.

O Ops Manager deve ter um usuário existente. Se você estiver implantando o cluster fragmentado em uma nova instalação do Ops Manager, deverá registrar o primeiro usuário.

Você deve ter aURL do host do Ops Manager, conforme definido na configuração mmsbaseurl do arquivo de configuração do MongoDB Agent.

Provisione dez hosts para atender aos componentes do cluster fragmentado. Para obter os requisitos de host, consulte as Notas de produção no manual do MongoDB.

Cada host deve fornecer a seu MongoDB Agent acesso total de rede aos nomes de host e portas dos MongoDB Agent em todos os outros hosts. Cada agente executa o comando hostname -f para auto-identificar seu nome de host e porta e comunicá-los ao Ops Manager.

Dica

Para garantir que os agentes possam entrar em contato uns com os outros, provisione os hosts usando a Automação . Isso instala os MongoDB Agents com o acesso correto à rede. Use este tutorial para reinstalar as automações nessas máquinas.

Conforme você trabalha com a API, você pode visualizar exemplos na Github página de exemplo do .

Os recursos da API usam uma ou mais dessas variáveis. Substitua essas variáveis pelos valores desejados antes de chamar esses recursos da API.

Nome
Tipo
Descrição
PUBLIC-KEY
string
Sua chave de API pública para suas credenciais de API.
PRIVATE-KEY
string
Sua chave de API privada para suas credenciais de API .
<OpsManagerHost>:<Port>
string
URL da sua instância do Ops Manager.
GROUP-ID
string
Identificador único do seu projeto a partir das configurações do projeto.
1

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.

2

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

3

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

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 .

1

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

2

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.

Para adicionar ou atualizar um sistema, recupere a configuração, faça as alterações conforme necessário e envie a configuração atualizada pela API para o Ops Manager.

O procedimento a seguir implementa uma configuração de automação atualizada por meio da API:

1
  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.

2

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}
3

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.

4

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]
5

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

Exemplo

Esta seção adiciona um membro do conjunto de réplicas ao primeiro documento do conjunto de réplicas:

Importante

Você deve incluir "protocolVersion": 1 no documento raiz para cada conjunto de réplicas.

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 }
18]
6

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.

7

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"
8

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.

Exemplo

Nesta resposta, processes[2].lastGoalVersionAchieved está atrás goalVersion. Isso indica que a instância do MongoDB em server3.example.com está sendo executada uma versão atrás do goalVersion . Aguarde alguns segundos e emita o comando curl novamente.

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.

Para disponibilizar uma versão adicional do MongoDB no cluster, consulte Atualizar a versão do MongoDB de um sistema.

Voltar

Tutoriais da API de administração do Ops Manager