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

Utilice la API para crear un proyecto.

Utilice la API de administración de Ops Manager para enviar un documento de proyectos para 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.

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

Utilice el punto final /users para agregar un usuario al nuevo proyecto.

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

Establezca el roles.roleName del usuario en GROUP_OWNER y 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 utilizó un usuario propietario global para crear el proyecto, puede eliminar 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. Ejecute 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.

Complete el procedimiento de instalación del Agente MongoDB 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 Agente MongoDB se ejecuta por primera vez, descarga el mms-cluster-config-backup.json archivo, que describe el estado deseado de la configuración de automatización.

En uno de los hosts, navegue a /var/lib/mongodb-mms-automation/ y abra mms-cluster-config-backup.json. Confirme que el campo version del archivo esté configurado como 1. Ops Manager incrementa automáticamente este campo a medida que se producen 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.

   Compare el version campo de con currentAutomationConfig.json el del archivo de copia de seguridad de configuración de automatización. mms-cluster-config-backup.json version El valor es el último elemento en ambos documentos JSON. Puede encontrar este archivo en cualquier host que ejecute el Agente de MongoDB 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á trabajando con la versión actual del archivo de configuración de automatización.

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

Cree un documento con los siguientes campos. Al crear el documento de configuración, consulte la descripción de una configuración de automatización para obtener explicaciones detalladas de los ajustes. Para ver ejemplos, consulte 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
}

Añade el Monitoreo 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 fragmentado tiene 10 instancias de MongoDB, como se describe en la sección "Implementar un clúster mediante la API", cada una ejecutándose en su propio servidor. Por lo tanto, la processes matriz de la configuración de automatización tendrá 10 documentos, uno por cada instancia de MongoDB.

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

Agregue 9 documentos: uno para cada instancia de MongoDB en su clúster fragmentado.

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

Agregue dos documentos del conjunto de réplicas a la matriz replicaSets. Agregue 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 la matriz sharding, agregue los conjuntos de réplicas a los fragmentos y agregue el nombre del conjunto de réplicas del servidor de configuración, como se muestra a continuación:

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
]

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

Utilice 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 una actualización exitosa de la configuración, la API devuelve el código de estado HTTP 200 OK para indicar que la solicitud se realizó correctamente.

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

Recupere la configuración de automatización de Ops Manager y confirme que contenga los cambios. Para recuperarla, 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"

Verifique que la actualización de 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 curl comando devuelve un objeto JSON que contiene la processes matriz y la clave y el goalVersion valor. La processes matriz contiene un documento por cada servidor que aloja una instancia de MongoDB. La nueva configuración se implementa correctamente cuando todos los lastGoalVersionAchieved campos de la processes matriz son iguales al valor especificado goalVersion para.

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 en Deployment.