MongoDB

Un rôle Ansible qui installe, configure et gère MongoDB pour Ubuntu 22.04.

MongoDB pour les distributions de type RHEL peut être trouvé ici.

Veuillez lire ce fichier attentivement avant de déployer ce rôle Ansible.

Fonctionnalités

• Applique des notes de production recommandées, par exemple numa et désactive les transparent hugepages
• Initialisation d'un cluster dans une architecture PSA (primaire, secondaire, arbitre)
  • inclut la vérification du cluster
• Sécurise la connexion en chiffrant le trafic via un fichier clé, généré automatiquement
• Installe soit l'édition Community, soit l'édition Enterprise
• Facile à configurer, avec une méthode de configuration pérenne
• Mise à jour du playbook, prend en charge les versions de correctifs
• Ajoute des utilisateurs définis par l'utilisateur
• Ajoute des bases de données définies par l'utilisateur
• Sauvegarde avec mongodump
• Gestion des journaux, réglée depuis Mongo

Ce rôle est idempotent et passe les vérifications ansible-lint.
Peut être utilisé avec Ansible version 2.9 et supérieure. Peut également supporter des versions antérieures.

Exigences

• Un cerveau
• Sur le nœud de contrôle, assurez-vous que la collection mongodb est installée
• Les hôtes doivent pouvoir se connecter les uns aux autres, de préférence avec des noms d'hôtes, et sur le port défini, par défaut 27017
• Gardez à l'esprit qu'il y a suffisamment d'espace disque pour le disque de données et la sauvegarde, si configurée

Assertions

Il existe plusieurs assertions pour garantir une configuration minimale valide. Bien sûr, cela ne couvre pas tous les cas d'utilisation, mais la plupart d'entre eux.
Veuillez suivre ce fichier README avec soin. Comme indice, pour une configuration valide, consultez les fichiers de variables dans le dossier moleculaire.

Versionnage et édition

La version et l'édition peuvent être définies. Par défaut, le dépôt officiel de MongoDB et la clé gpg sont ajoutés.

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

Jusqu'à présent, Ubuntu 22.04 ne prend en charge que MongoDB 6.0 et ne prend pas en charge les versions antérieures.

Pas de journal

Par défaut, pour des raisons de sécurité, la journalisation pour plusieurs tâches est désactivée. Pour l'activer :

mongo_no_log: true

Recommandations

Cette section fait référence à ces notes de production officielles de MongoDB.

Ce rôle inclut plusieurs recommandations de configuration, mais pas toutes. Par exemple : "Désactiver atime pour le volume de stockage contenant les fichiers de base de données." Ces tâches sont hors du champ d'application de ce rôle.

Il y a des tâches que ce rôle applique si définies, parmi lesquelles :

• Démarrer MongoDB avec numactl, défini dans le fichier systemd
• Désactivation de la récupération de zone
• Désactivation des transparent hugepages
• Configuration du profil tuned

Voir tasks/thp.yml et tasks/numa.yml pour les modifications effectives du système.

Ces recommandations de configuration sont appliquées par défaut.

mongo_thp: true
mongo_numa: true

Variables de configuration

Tout d'abord, consultez defaults/main.yml.

Le fichier de configuration est placé à /etc/mongod.conf.

Les valeurs définies dans la configuration Ansible sont définies exactement dans le fichier de configuration sur l'hôte. Seules les clés sont prédéfinies. Exemple :

# Variable définie dans la configuration Ansible
mongo_operationprofiling:
  my_Value:
    anotherValue: something

Cela se traduira par le fichier de configuration sur disque :

operationProfiling:
  my_Value:
    anotherValue: something

Si la clé est définie sur une chaîne vide, elle sera commentée dans le fichier de configuration sur disque.

Les clés pouvant être définies sont :

mongo_systemlog
mongo_storage
mongo_processmanagement
mongo_security
mongo_operationprofiling
mongo_replication
mongo_sharding
mongo_auditlog
mongo_snmp

Il existe des valeurs prédéfinies, qui sont par défaut pour Mongo.
Si, pour une raison quelconque, il est souhaité de définir des clés/valeurs personnalisées, utilisez :

mongo_custom_cnf:
  my_key:
    my_value: true

Autorisation

Par conception, trois utilisateurs sont créés : admin, backup et adminuser.
L'admin a le rôle root, l'utilisateur de sauvegarde a le rôle backup et adminuser a le rôle userAdminAnyDatabase.

mongo_admin_pass: 'change_me'
mongo_adminuser_name: adminuser
mongo_adminuser_pass: 'change_me'

Bases de données et utilisateurs

Prenez-en connaissance dans la documentation, définissez votre propre ensemble d'utilisateurs/bases de données.

Consultez la documentation pour les rôles possibles.

Les utilisateurs et les bases de données sont toujours configurés via localhost, via l'utilisateur admin et l'administrateur de base de données.
Lorsqu'un cluster est configuré, la configuration des bases de données et des utilisateurs est exécutée depuis l'hôte principal.

Définissez avec :

mongo_user:
# sous sa forme la plus simple
  - database: my_db
    name: my_user

# valeurs standard
  - database: another_db
    name: another_user
    update_password: on_create
    password: "123ABC!PASSWORD_XYZ"
    roles: 'readWrite,dbAdmin,userAdmin'
    state: present

# toutes les variables possibles
  - database: my_db
    name: someone
    password: my_password
    update_password: on_create             # par défaut toujours
    roles: 'readWrite,dbAdmin,userAdmin'   # par défaut omis
    state: absent                          # par défaut présent
    ssl: true                              # par défaut omis
    ssl_ca_certs: /path/to/ca_certs        # par défaut omis
    ssl_cert_reqs: CERT_REQUIRED           # par défaut omis
    ssl_certfile: /path/to/ssl_certfile    # par défaut omis
    ssl_crlfile: /path/to/ssl_crlfile      # par défaut omis
    ssl_keyfile: /path/to/ssl_keyfile      # par défaut omis
    ssl_pem_passphrase: 'something'        # par défaut omis
    auth_mechanism: PLAIN                  # par défaut omis
    connection_options: my_conn_options    # par défaut omis
    create_for_localhost_exception: value  # par défaut omis

Pour garder le rôle idempotent, vous devez définir la valeur pour update_password sur on_create. Ce n'est que lorsque vous mettez effectivement à jour un mot de passe que vous devez le définir sur always, puis revenir à on_create.

Clustering

Lorsque plusieurs hôtes sont présents dans le play, Ansible suppose que le clustering est configuré.

Le clustering dans une architecture PSA (primaire/secondaire/arbitre) est possible, ou une configuration primaire/secondaire/secondaire.

Pour des raisons de sécurité, la connexion entre les hôtes est sécurisée avec un fichier clé.

Le fichier clé est généré automatiquement et jugé sécurisé.

mongo_security:
  keyFile: /etc/keyfile_mongo

Un cluster de 2 hôtes est une conception fondamentalement défaillante, car il ne peut maintenir un temps de disponibilité sans quorum et la capacité d'un nœud à tomber en panne pour aider à la récupération.
Lorsque deux hôtes sont exactement présents dans le play, la formation d'un cluster n'est pas possible.
Mongo ne formera pas de cluster, car il doit y avoir un nombre valide de membres de réplica set.

Des assertions sont mises en place pour vérifier si une quantité inégale d'hôtes se trouve dans le play.

Configurez avec :

# définissez le rôle par hôte dans host_vars
mongo_replication_role: primary # ou secondary, ou arbiter

# dans group_vars/all.yml
mongo_replication:
  replSetName: something
mongo_security:
  keyFile: /etc/keyfile_mongo

Il ne peut y avoir qu'un seul_primary_ et un seul arbitre définis.

Vous ne devez pas changer la conception du cluster une fois qu'il a été déployé, par exemple changer un secondaire en arbitre.

Arbitre

Comme le dit la documentation, évitez de déployer plus d'un arbitre par ensemble de répliques.

Ansible se chargera d'ajouter correctement l'arbitre au cluster.

mongo_replication_role: arbiter

Sauvegarde

La sauvegarde est configurée pour être effectuée soit sur un seul hôte sans réplication, soit sur le premier hôte secondaire dans le jeu. Elle est réalisée avec mongodump, programmée dans cron.

Les scripts de sauvegarde sont uniquement placés sur le premier nœud secondaire applicable :

- hôte1 [primaire]   <-- scripts de sauvegarde absents ici
- hôte2 [secondaire] <-- scripts de sauvegarde placés ici
- hôte3 [secondaire] <-- scripts de sauvegarde absents ici

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

Assurez-vous de changer le mot de passe de l'utilisateur de sauvegarde et de lui permettre effectivement de sauvegarder une base de données donnée.

Sur disque, le résultat sera :

[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

Gestion des journaux

Veuillez lire la documentation. Assurez-vous que les paramètres sont correctement configurés.

Mise à jour

Avant de mettre à jour, assurez-vous que des tests appropriés sont en place. Commencez par lire les dernières modifications dans la documentation officielle.

Il existe un playbook de mise à jour séparé, consultez playbooks/update.yml. Définissez le bon nom d'hôte et exécutez simplement le playbook.

La mise à jour peut facilement être effectuée pour des versions de correctifs, par exemple de 6.0.1 à 6.0.2.
Ce rôle n'inclut pas les mises à jour majeures en raison de changements majeurs à chaque version et d'autres raisons évidentes.

Si cela est souhaité, la logique est en place dans le playbook de mise à jour pour effectuer une mise à jour majeure.

De nouvelles variables peuvent être définies lors de la mise à jour de Mongo. Pour mettre à jour :

mongo_state: latest

# définir de nouvelles variables est possible lors de la mise à jour de Mongo
mongo_net:
  new_variable: true

Lors de la mise à jour, assurez-vous que les applications n'écrivent pas dans Mongo. De plus, assurez-vous qu'une sauvegarde est créée au préalable.

Mise à jour d'un ensemble de réplicas

Si un ensemble de réplicas est actif, le cluster doit être maintenu après la mise à jour. Comme pris en charge par la documentation, les étapes suivantes sont exécutées :

 - vérifier la santé du cluster, si ok, continuer

 - arrêter l'application mongo sur l'arbitre si présent
 - mettre à jour mongo sur l'arbitre
 - placer la configuration sur l'arbitre
 - démarrer mongo sur l'arbitre

 - attendre que la santé du cluster soit ok

 - arrêter l'application mongo sur un secondaire
 - mettre à jour mongo sur un secondaire
 - placer la configuration sur un secondaire
 - démarrer mongo sur un secondaire

 - attendre que la santé du cluster soit ok

 - répéter pour les autres secondaires

 - démettre le primaire
 - mettre à jour mongo sur le primaire d'origine
 - placer la configuration sur le primaire d'origine
 - démarrer mongo sur le primaire d'origine

 - attendre que la santé du cluster soit ok

Mise à jour d'un environnement partitionné

En développement.

Développement

• Il existe un playbook de réinitialisation pour supprimer tous les fichiers mongo. Cela est utile à des fins de développement, consultez tasks/reset.yml. Il est commenté par conception.

Scalabilité

Toujours en développement... Je ne suis même pas sûr d'avoir cette fonctionnalité, car cela n'est actuellement même pas possible avec Mongo 5.0.
Il n'est pas facile de configurer la scalabilité dans Mongo avec Ansible, car la méthode n'est pas directe.

Jusqu'à présent, j'ai vu que les étapes devraient être :

• Si un arbitre est présent dans la configuration et sur le système
  • retirer l'arbitre du cluster
• Ajouter un ou plusieurs seconds
• Ajouter un arbitre si configuré

J'ai essayé de configurer cela de nombreuses fois, mais j'ai toujours échoué en raison d'une erreur système. J'ai décidé de ne pas inclure la scalabilité pour le moment.

Exemple 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: quelque chose
    mongo_adminuser_pass: quelque chose
    mongo_net:
      bindIp: 0.0.0.0
      port: 27017
    mongo_systemlog:
      destination: file
      logAppend: true
      path: /opt/somewhere/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:
    # assurez-vous que cela est fait
    # - name: assurez-vous que les hôtes peuvent se connecter entre eux via les noms d'hôtes
    #   template:
    #     src: hosts.j2
    #     dest: /etc/hosts