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 los y del proyecto.agentApiKey id

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 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 uses para crear el proyecto se añadirá automáticamente. Si usaste un usuario con el rol, puedes eliminarlo del proyecto sin perder la posibilidad de realizar cambios en él en el futuro. Mientras tengas los Global Owner roles agentApiKey y del id proyecto, tendrás acceso completo al proyecto al iniciar sesión como propietario 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 lista todos los usuarios del proyecto. Localice el usuario con roles.roleName establecido GLOBAL_OWNER en. Copie el valor del usuario id y ejecute lo siguiente para eliminarlo del proyecto, reemplazando {USER-ID} con su id valor:

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 cómo instalar el Agente MongoDB, siga el procedimiento para la plataforma apropiada.

Confirmar el estado inicial de la configuración de la 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, reemplazando los marcadores de posición con las variables para 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, introduzca el nombre de host del servidor donde Ops Manager debe instalar la monitorización. Utilice el nombre de dominio completo que devuelve la ejecución de hostname -f en el servidor, como se muestra a continuación:

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.

Especifique la args2_6 sintaxis para el processes.<args> campo. El processes.args2_6 objeto acepta la mayoría de las configuraciones y parámetros de MongoDB para las versiones 2.6 y posteriores. Para obtener más información, consulte Configuración y compatibilidad con automatización de 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
]

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
]

Envíe la configuración de automatización actualizada.

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

Emita el siguiente comando con la ruta al documento de configuración actualizado y reemplace los marcadores de posición con las variables para los recursos de la API de creación de clúster.

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.

Utilice el recurso automationStatus para verificar que la actualización de configuración se haya implementado completamente. Ejecute 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.