MongoDB

Un rol de Ansible que instala, configura y gestiona MongoDB para Ubuntu 22.04.

MongoDB para versiones similares a RHEL se puede encontrar aquí.

Por favor, lee este archivo con cuidado antes de desplegar este rol de Ansible

Funcionalidades

• Aplica notas de producción recomendadas, por ejemplo, numa y desactiva hugepages transparentes
• Inicializa un clúster en una arquitectura PSA (primaria, secundaria, árbitro)
  • incluye verificación de clúster
• Asegura la conexión encriptando el tráfico mediante un archivo clave, generado automáticamente
• Instala ya sea la edición Comunidad o la edición Empresarial
• Fácil de configurar, con un método de configuración a prueba de futuro
• Actualiza el playbook, soporta lanzamientos de parches
• Agrega usuarios definidos por el usuario
• Agrega bases de datos definidas por el usuario
• Respaldo con mongodump
• Rotación de logs, configurada desde dentro de Mongo

Este rol es idempotente y pasa las comprobaciones de ansible-lint.
Se puede usar con Ansible versión 2.9 hasta la última. También puede soportar versiones anteriores.

Requisitos

• Cerebro
• En el nodo controlador, asegúrate de que la colección mongodb esté instalada
• Los hosts deben poder conectarse entre sí, preferiblemente usando nombres de host y el puerto establecido, por defecto 27017
• Ten en cuenta que hay suficiente espacio en disco para el disco de datos y la copia de seguridad si está configurada

Aserciones

Existen varias aserciones para garantizar una configuración mínima válida. Por supuesto, no cubre todos los casos de uso, pero sí la mayoría. Por favor, sigue este README con atención. Como pista, para una configuración válida, consulta los archivos de variables en la carpeta de moléculas.

Versionado y edición

La versión y la edición se pueden establecer. Por defecto, se añaden el repositorio oficial de mongodb y la clave gpg.

mongo_repo: true
mongo_version: 6.0
mongo_edition: org  # o enterprise

Hasta ahora, Ubuntu 22.04 solo soporta MongoDB 6.0 y no versiones anteriores.

Sin registro

Por defecto, por razones de seguridad, el registro de varias tareas está desactivado. Para activarlo:

mongo_no_log: true

Recomendaciones

Esta sección se refiere a las notas de producción oficiales de MongoDB.

Este rol incluye varias recomendaciones de configuración, pero no todas. Por ejemplo: "Desactivar atime para el volumen de almacenamiento que contiene los archivos de la base de datos". Tales tareas están fuera del alcance de este rol.

Existen tareas las cuales este rol aplica si se establece, estas son:

• Iniciar MongoDB con numactl, configurado en el archivo systemd
• Desactivar reclamación de zonas
• Desactivar hugepages transparentes
• Configurar perfil ajustado

Consulta tasks/thp.yml y tasks/numa.yml para los cambios reales en el sistema.

Estas recomendaciones de configuración se aplican por defecto.

mongo_thp: true
mongo_numa: true

Variables de configuración

Primero, consulta defaults/main.yml.

El archivo de configuración se coloca en /etc/mongod.conf.

Los valores establecidos en la configuración de Ansible se configuran exactamente en el archivo de configuración en el host. Solo las claves están predefinidas. Ejemplo:

# Variable configurada en la configuración de Ansible
mongo_operationprofiling:
  my_Value:
    anotherValue: something

Resultará en el archivo de configuración en disco:

operationProfiling:
  my_Value:
    anotherValue: something

Si la clave se establece como una cadena vacía, se comentará en el archivo de configuración en disco.

Las claves posibles a establecer son:

mongo_systemlog
mongo_storage
mongo_processmanagement
mongo_security
mongo_operationprofiling
mongo_replication
mongo_sharding
mongo_auditlog
mongo_snmp

Existen valores predefinidos, que son los predeterminados para Mongo. Si por alguna razón se desea establecer claves/valores personalizados, usa:

mongo_custom_cnf:
  my_key:
    my_value: true

Autorización

Por diseño se crean 3 usuarios: admin, backup y adminuser. El admin tiene el rol raíz, el usuario de respaldo tiene el rol de respaldo y el adminuser tiene el rol de userAdminAnyDatabase.

mongo_admin_pass: 'cámbialo'
mongo_adminuser_name: adminuser
mongo_adminuser_pass: 'cámbialo'

Bases de datos y usuarios

Tomado de la documentación, define tu propio conjunto de usuarios/bases de datos.

Consulta la documentación para los roles posibles.

Los usuarios y bases de datos siempre se configuran a través de localhost, utilizando user admin y database admin. Cuando un clúster está configurado, la configuración de bases de datos y usuarios se ejecuta desde el host primario.

Configúralo con:

mongo_user:
# en su forma más simple
  - database: my_db
    name: my_user

# valores estándar
  - database: another_db
    name: another_user
    update_password: on_create
    password: "123ABC!PASSWORD_XYZ"
    roles: 'readWrite,dbAdmin,userAdmin'
    state: present

# todas las variables posibles
  - database: my_db
    name: someone
    password: my_password
    update_password: on_create             # predeterminado siempre
    roles: 'readWrite,dbAdmin,userAdmin'   # predeterminado omitido
    state: absent                          # predeterminado presente
    ssl: true                              # predeterminado omitido
    ssl_ca_certs: /ruta/a/ca_certs        # predeterminado omitido
    ssl_cert_reqs: CERT_REQUIRED           # predeterminado omitido
    ssl_certfile: /ruta/a/ssl_certfile    # predeterminado omitido
    ssl_crlfile: /ruta/a/ssl_crlfile      # predeterminado omitido
    ssl_keyfile: /ruta/a/ssl_keyfile      # predeterminado omitido
    ssl_pem_passphrase: 'algo'            # predeterminado omitido
    auth_mechanism: PLAIN                  # predeterminado omitido
    connection_options: my_conn_options    # predeterminado omitido
    create_for_localhost_exception: valor  # predeterminado omitido

Para mantener el rol idempotente, deberías establecer el valor de update_password a on_create. Solo al actualizar realmente una contraseña, configúralo a always, luego regresa a on_create.

Clustering

Cuando hay múltiples hosts en el play, Ansible asume que el clustering está configurado.

El clustering en una arquitectura PSA (primario/secundario/árbitro) es posible, o una configuración primaria/secundaria/secundaria.

Por razones de seguridad, la conexión entre los hosts se asegura mediante un archivo clave.

El archivo clave se genera automáticamente y se considera seguro.

mongo_security:
  keyFile: /etc/keyfile_mongo

Un clúster de 2 hosts es un diseño fundamentalmente roto, ya que no puede mantener el tiempo de actividad sin un quórum y la capacidad de un nodo de apagarse para ayudar a la recuperación. Cuando hay exactamente 2 hosts en el play, no es posible formar un clúster. Mongo no se agrupará porque debe haber un número válido de miembros en el conjunto de réplicas.

Hay aserciones en su lugar para verificar si hay una cantidad impar de hosts en el juego.

Configura con:

# establece el rol por host. en los host_vars
mongo_replication_role: primary # o secondary, o arbiter

# en group_vars/all.yml
mongo_replication:
  replSetName: algo
mongo_security:
  keyFile: /etc/keyfile_mongo

Solo se puede establecer 1 primario y 1 árbitro.

No deberías cambiar el diseño del clúster una vez que ha sido desplegado, por ejemplo, cambiar un secundario a árbitro.

Árbitro

Según la documentación, evita desplegar más de un árbitro por conjunto de réplicas.

Ansible se encargará de agregar el árbitro correctamente al clúster.

mongo_replication_role: arbiter

Respaldo

La copia de seguridad está configurada para establecerse en un solo host sin replicación, o en el primer host secundario en el play. Se realiza con mongodump, configurado en cron.

Los scripts de copia de seguridad se colocan solo en el primer nodo secundario aplicable:

- host1 [primario]   <-- scripts de respaldo ausentes aquí
- host2 [secundario] <-- scripts de respaldo colocados aquí
- host3 [secundario] <-- scripts de respaldo ausentes aquí

mongo_backup:
  enabled: true
  dbs:
    - admin
    - config
    - local
  user: backup
  pass: cámbialo
  path: /var/lib/mongo_backups
  owner: mongodb
  group: mongodb
  mode: '0660'
  hour: 2
  minute: 5
  day: "*"
  retention: 46  # en horas

Asegúrate de cambiar la contraseña del usuario de respaldo y permitir que el usuario de respaldo respalde una base de datos determinada.

En disco, el resultado será:

[root@test-multi-03 mongo_backups]# pwd ; ls -larth
/var/lib/mongo_backups
total 4.0K
drwxr-xr-x. 36 root   root   4.0K Jan 20 12:33 ..
lrwxrwxrwx   1 root   root     46 Nov 20 12:37 latest -> /var/lib/mongo_backups/mongo_backup_2021-11-20
drw-rw----   3 mongod mongod   51 Nov 20 12:37 .
drwxr-xr-x   5 root   root     77 Nov 20 12:38 mongo_backup_2021-11-20

Rotación de logs

Por favor lee la documentación. Asegúrate de que las configuraciones estén configuradas correctamente.

Actualización

Antes de actualizar, asegúrate de realizar pruebas adecuadas. Comienza leyendo los últimos cambios en la documentación oficial.

Hay un playbook de actualización separado, consulta playbooks/update.yml. Establece el nombre de host correcto y simplemente ejecuta el playbook.

La actualización se puede realizar fácilmente para versiones de parches, por ejemplo, de 6.0.1 a 6.0.2. Este rol no incluye actualizaciones de versiones principales debido a los cambios importantes en cada lanzamiento y otras razones obvias.

Si esto es deseado, la lógica está en su lugar en el playbook de actualización para realizar una actualización mayor.

Nuevas variables se pueden establecer al actualizar mongo. Para actualizar:

mongo_state: latest

# es posible establecer nuevas variables al actualizar mongo
mongo_net:
  new_variable: true

Al actualizar, asegúrate de que las aplicaciones no escriban en mongo. Además, asegúrate de que se cree una copia de seguridad de antemano.

Actualización de un conjunto de réplicas

Si un conjunto de replicación está activo, el clúster debe mantenerse después de la actualización. Como se indica en la documentación, se ejecutan los siguientes pasos:

 - verificar la salud del clúster, si está bien, continuar

 - apagar la aplicación mongo en el árbitro, si está presente
 - actualizar mongo en el árbitro
 - colocar la configuración en el árbitro
 - iniciar mongo en el árbitro

 - esperar hasta que la salud del clúster esté bien

 - apagar la aplicación mongo en un secundario
 - actualizar mongo en el secundario
 - colocar la configuración en el secundario
 - iniciar mongo en el secundario

 - esperar hasta que la salud del clúster esté bien

 - repetir para los restantes secundarios

 - reducir el primario
 - actualizar mongo en el primario original
 - colocar la configuración en el primario original
 - iniciar mongo en el primario original

 - esperar hasta que la salud del clúster esté bien

Actualización de un entorno fragmentado

En desarrollo.

Desarrollo

• Hay un playbook de reinicio para eliminar todos los archivos de mongo. Esto es útil para fines de desarrollo, consulta tasks/reset.yml. Está comentado por diseño.

Escalado

Aún en desarrollo... No estoy seguro si alguna vez necesitaré esta funcionalidad, ya que actualmente ni siquiera es posible con mongo 5.0. No es fácil configurar el escalado en mongo con Ansible, ya que el método no es directo.

Hasta ahora, he visto que los pasos deberían ser:

• Si el árbitro está presente en la configuración y en el sistema
  • eliminar el árbitro del clúster
• Agregar un nuevo secundario o secundarios
• Agregar árbitro si está configurado

He intentado configurar esto innumerables veces, pero siempre he fallado debido a un error del sistema. He decidido no incluir el escalado por ahora.

Ejemplo de playbook

- hosts:
    - mongo_primary
    - mongo_secondary
    - mongo_arbiter
  roles:
    - ansible_role_mongodb_ubuntu
  any_error_true: true
  vars:
    mongo_restart_config: true
    mongo_restart_seconds: 8
    mongo_thp: true
    mongo_numa: true
    mongo_replication:
      replSetName: replicaset1
    mongo_security:
      authorization: enabled
      keyFile: /etc/keyfile_mongo
    mongo_admin_pass: algo
    mongo_adminuser_pass: algo
    mongo_net:
      bindIp: 0.0.0.0
      port: 27017
    mongo_systemlog:
      destination: file
      logAppend: true
      path: /opt/algunlugar/mongod.log
    mongo_storage:
      dbPath: /opt/mongo/
      journal:
        enabled: true
    mongo_user:
      - database: burgers
        name: bob
        password: 12345
        state: present
        update_password: on_create    
  pre_tasks:
    # asegúrate de que esto se haga
    # - name: asegurar que los hosts puedan conectarse entre sí a través de nombres de host
    #   template:
    #     src: hosts.j2
    #     dest: /etc/hosts