Implementa un clúster a través de la API

Utiliza la API para crear un proyecto.

Utiliza la API de administración de Ops Manager para enviar un documento de proyectos y crear el nuevo proyecto.

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

La API devuelve un documento que incluye el agentApiKey y el id del proyecto.

Registre los valores de agentApiKey y id en el documento devuelto.

Tome nota de estos valores para utilizarlos en este procedimiento y en otros procedimientos de este tutorial.

Utilice la API para crear un usuario en el nuevo proyecto.

Utiliza el endpoint /users para agregar un usuario al nuevo proyecto.

El cuerpo de la solicitud debe contener un documento usuarios JSON con la información del usuario.

Configura el roles.roleName del usuario en GROUP_OWNER y configura el roles.groupId del usuario en el id del nuevo 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) Si utilizaste un usuario propietario global para crear el Proyecto, puedes remover a ese usuario del Proyecto.

El usuario que utiliza para crear el proyecto se añade automáticamente al proyecto. Si has utilizado un usuario con el rol Global Owner, puedes remover al usuario del proyecto sin perder la capacidad de realizar cambios en el proyecto en el futuro. Mientras tengas la agentApiKey y el id del proyecto, tendrás acceso completo al proyecto cuando inicies sesión como dueño global.

GET el ID del propietario global. Ejecuta el siguiente comando para solicitar los usuarios del Proyecto:

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

La API devuelve un documento JSON que enumera todos los usuarios del proyecto. Localice al usuario con roles.roleName configurado en GLOBAL_OWNER. Copie el valor del id del usuario y emita lo siguiente para remover al usuario del proyecto, reemplazando {USER-ID} con el valor del id del usuario:

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

Si Ops Manager remueve correctamente al usuario, la API devuelve el código de estado HTTP 200 OK.

Completa el procedimiento de instalación del MongoDB Agent en cada host.

Para aprender a instalar el MongoDB Agent, sigue el procedimiento para la plataforma adecuada.

Confirme el estado inicial de la configuración de automatización.

Cuando el MongoDB Agent se ejecuta por primera vez, descarga el archivo mms-cluster-config-backup.json, que describe el estado deseado de la configuración de automatización.

En uno de los hosts, navegue hasta /var/lib/mongodb-mms-automation/ y abra mms-cluster-config-backup.json. Confirma que el campo version del archivo esté configurado en 1. Ops Manager incrementa automáticamente este campo a medida que se realizan cambios.

Recupere la configuración de automatización de Ops Manager.

1. Utilice el recurso automationConfig para recuperar la configuración. Ejecute el siguiente comando, sustituyendo los marcadores de posición por las variables de los recursos de la API de creación de clústeres.

   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. Validar el archivo de Configuración de Automatización descargado.

   Compara el campo version del currentAutomationConfig.json con el del archivo de copia de seguridad de Configuración de Automatización, mms-cluster-config-backup.json. El valor version es el último elemento en ambos documentos JSON . Puedes encontrar este archivo en cualquier host que ejecute el MongoDB Agent en:

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

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

   Si los valores version coinciden, estás trabajando con la versión actual del archivo de configuración de Automatización.

Crea el nivel superior de la nueva configuración de automatización.

Cree un documento con los siguientes campos. Mientras compila el documento de configuración, consulte la descripción de una configuración de automatización para obtener explicaciones detalladas de las configuraciones. Para ejemplos, consulta la página de MongoDB Labs.

1
{
2
    "options": {
3
        "downloadBase": "/var/lib/mongodb-mms-automation",
4
    },
5
    "mongoDbVersions": [],
6
    "monitoringVersions": [],
7
    "backupVersions": [],
8
    "processes": [],
9
    "replicaSets": [],
10
    "sharding": []
11
}

Agregar la supervisión a la configuración de automatización.

En el campo monitoringVersions.hostname, ingresa el nombre del host del servidor donde Ops Manager debe instalar la supervisión. Utiliza el nombre de dominio completo que retorna la ejecución de hostname -f en el servidor, como en el siguiente ejemplo:

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 ejemplo de configuración también incluye el campo logPath, que indica la ubicación del registro, y logRotate, que indica los umbrales del registro.

Agregue los servidores a la configuración de automatización.

Este clúster tiene 10 instancias de MongoDB, como se describe en el Implementa un clúster a través de la API, cada una de ellas ejecutándose en su propio servidor. Por lo tanto, el arreglo processes de la configuración de automatización tendrá 10 documentos, uno para cada instancia de MongoDB.

El siguiente ejemplo agrega el primer documento a la arreglo processes. Reemplace <process_name_1> con cualquier nombre que elija y reemplace <server1.example.com> con el FQDN del host.

Agrega 9 documentos: uno para cada instancia de MongoDB en su clúster compartido.

Especifica la sintaxis args2_6 para el campo processes.<args>. El objeto processes.args2_6 acepta la mayoría de las configuraciones y parámetros de MongoDB para las versiones 2.6 y posteriores de MongoDB. Para obtener más información, consulta Configuración de MongoDB y soporte de automatización.

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
      "sharding": {
28
        "clusterRole": "shardsvr"
29
      }
30
    }
31
  },
32
]

Añade la topología del clúster sharded a la configuración de automatización.

Agrega dos documentos del set de réplicas al arreglo replicaSets. Agrega tres miembros 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
]

En el arreglo sharding, añade los sets de réplicas a las particiones y añade el nombre del set de réplicas del servidor de configuración, como en el siguiente ejemplo:

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
]

Enviar la configuración de automatización actualizada.

Utiliza el recurso automationConfig para enviar la configuración de automatización actualizada.

Emite el siguiente comando con la ruta al documento de configuración actualizado y reemplaza los campos por las variables para la API de creación de recursos de clústeres.

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

Tras la actualización exitosa de la configuración, la API devuelve el código de estado HTTP 200 OK para indicar que la solicitud se ha realizado correctamente.

Confirmar la actualización exitosa de la configuración de automatización.

Recupera la configuración de automatización desde Ops Manager y confirma que contenga los cambios. Para recuperar la configuración, ejecuta el siguiente command, sustituyendo los marcadores de posición por las Variables para Recursos de la API de Creación de Clúster.

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

Verifica que la actualización de la configuración esté implementada.

Utiliza el recurso automationStatus para verificar que la actualización de la configuración esté completamente implementada. Ejecuta el siguiente comando:

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

El comando curl devuelve un objeto JSON que contiene el arreglo processes y la clave y el valor goalVersion. El arreglo processes contiene un documento para cada servidor que alberga una instancia de MongoDB. La nueva configuración se implementa de forma exitosa cuando todos los campos lastGoalVersionAchieved en el arreglo processes son iguales al 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 ver la nueva configuración en la consola de Ops Manager, haga clic Deployment.