MySQL¶

Rôle¶

Le dépôt /root/mysql provisionne une VM MySQL autonome (INDDATA007, 10.100.2.199) sur le segment seg-data, aux côtés du cluster PostgreSQL. Contrairement à ce dernier, ce dépôt ne contient aucune configuration Ansible : la VM est clonée et adressée par Terraform, mais l'installation et la configuration du moteur MySQL lui-même ne sont pas automatisées ici — elle reste nue après un terraform apply.

Les règles de pare-feu distribué NSX admin-to-data et service-to-data (/root/nsx/security_policies.tf) autorisent explicitement le service prédéfini /infra/services/MySQL depuis seg-admin et seg-service vers seg-data — cette VM est donc déjà réseau-accessible en tant que ressource de données partagée potentielle pour les applications de seg-service.

En pratique, les applications de seg-service qui ont typiquement besoin d'un moteur MySQL/MariaDB — GLPI et OCS Inventory NG — déploient et consomment chacune leur propre instance MariaDB locale (db_host: localhost, rôle mariadb dans leurs dépôts respectifs) plutôt que de se connecter à INDDATA007. Aucun dépôt applicatif de l'infra ne référence cette VM comme backend à ce jour : elle apparaît provisionnée par anticipation (ou pour un usage non encore implémenté) plutôt que réellement consommée.

Architecture¶

• 1 nœud Rocky Linux 9.6 (clone de tmpl-rocky96-hardened) : INDDATA007, IP 10.100.2.199, segment seg-data (10.100.2.192/27, même segment que PostgreSQL).
• 2 vCPU / 4096 Mo RAM (valeurs par défaut Terraform, identiques au dimensionnement des nœuds PostgreSQL).
• Nœud unique : pas de VIP, pas de réplication, contrairement au cluster PostgreSQL du même segment.
• Aucun moteur de base de données installé : la VM ne fait tourner que le socle tmpl-rocky96-hardened (SELinux enforcing, firewalld zone drop).

Structure du dépôt¶

Fichier	Contenu
main.tf	VM unique INDDATA007, clone de data.vsphere_virtual_machine.template, IP assignée par NetBox
variables.tf	vsphere_network = "seg-data", vm_gateway = "10.100.2.222", vm_netmask = 27, nodes = [INDDATA007], vm_cpu = 2, vm_ram = 4096
versions.tf	Providers hashicorp/vsphere (>= 2.6.0), e-breuninger/netbox (>= 5.0.0, < 6.0.0)
terraform.tfvars / .example	Identifiants vCenter/NetBox (non versionné / modèle)

flowchart LR
    subgraph SEGDATA["seg-data — 10.100.2.192/27"]
        MYSQL["INDDATA007<br/>10.100.2.199<br/>VM nue, aucun moteur installé"]
    end
    ADMIN["seg-admin"] -- "DFW admin-to-data<br/>MySQL + PostgreSQL + HTTPS (ALLOW)" --> SEGDATA
    SERVICE["seg-service"] -- "DFW service-to-data<br/>MySQL + PostgreSQL + HTTPS (ALLOW)" --> SEGDATA

    GLPI["GLPI — INDSERV025"] -. "MariaDB locale (localhost)<br/>aucune connexion réseau vers INDDATA007" .-> GLPIDB[("MariaDB<br/>locale à GLPI")]
    OCS["OCS Inventory NG — INDSERV026"] -. "MariaDB locale (localhost)<br/>aucune connexion réseau vers INDDATA007" .-> OCSDB[("MariaDB<br/>locale à OCS")]

Provisioning Terraform¶

• /root/mysql/main.tf : structure identique aux autres projets vSphere de l'infra — clone du template via data.vsphere_virtual_machine.template, IP assignée par NetBox via data.netbox_ip_addresses (filtre dns_name, comparé en minuscules avec lower(...)), resource "vsphere_virtual_machine" "mysql" avec for_each sur var.nodes (une seule entrée aujourd'hui : INDDATA007).
• lifecycle.ignore_changes couvre annotation, clone[0].template_uuid, clone[0].customize et disk[0].io_share_count — évite qu'un apply ne recrée la VM sur une dérive cosmétique post-clonage (même pattern que tous les autres projets de l'infra).
• Variables (variables.tf) : vsphere_network = "seg-data", vm_gateway = "10.100.2.222", vm_netmask = 27, nodes = [{ name = "INDDATA007" }], vm_cpu = 2, vm_ram = 4096.
• Providers (versions.tf) : hashicorp/vsphere (>= 2.6.0), e-breuninger/netbox (>= 5.0.0, < 6.0.0) — identiques au reste de l'infra.
• Identifiants vCenter/NetBox attendus dans terraform.tfvars (non versionné, .gitignore) ; modèle dans terraform.tfvars.example.
• output "vms" expose l'IP effective attribuée par vSphere (default_ip_address), pour vérification post-apply.

Configuration Ansible¶

Non applicable. Le dépôt ne contient aucun sous-dossier ansible/ (confirmé par l'arborescence réelle du dépôt) : ni le moteur MySQL, ni une éventuelle base applicative, ni un pare-feu local dédié ne sont configurés par ce projet.

Procédure de déploiement¶

1. terraform apply (dans /root/mysql) : clone la VM INDDATA007 et lui attribue son IP via NetBox.
2. Aucune étape Ansible existante dans ce dépôt à ce jour — la VM reste au socle tmpl-rocky96-hardened après l'étape 1.

Contrôle de santé / Vérification¶

Aucune vérification applicative n'est possible : seule la présence de la VM peut être contrôlée (ping, ssh indio-adm@10.100.2.199, systemctl list-units ne montrant aucun service mysqld/mariadb). Une tentative de connexion MySQL (mysql -h 10.100.2.199) échouera par absence de service en écoute, pas par un blocage réseau — le DFW autorise déjà le flux.

Points d'attention¶

• Pas de configuration applicative versionnée : si ce nœud doit être mis en service, l'installation du moteur (paquets, my.cnf, comptes applicatifs, durcissement, sauvegarde) reste entièrement à écrire — aucun rôle Ansible n'existe encore pour ce projet.
• Accès réseau déjà ouvert, service absent : les règles DFW admin-to-data/service-to-data autorisent déjà MySQL en amont d'une éventuelle mise en service — à réévaluer si le besoin disparaît définitivement, pour resserrer le périmètre réseau.
• Secrets : les identifiants vCenter/NetBox sont fournis via terraform.tfvars (non versionné) — valeurs gérées séparément (voir gestion des secrets).