Utilisation de Terraform pour la gestion des bases de données

L'un des voyages les plus importants que nous entreprenons ici chez Vonage est de nous transformer en une organisation d'ingénierie agile utilisant les principes de l'ingénierie de la fiabilité des sites (SRE). Cela signifie que nous sommes presque allergiques au labeur.

La pénibilité est le type de travail qui tend à être manuel, répétitif, automatisable, tactique, dépourvu de valeur durable et qui évolue de manière linéaire au fur et à mesure que le service se développe.

Nous sommes constamment à la recherche de moyens d'automatiser les tâches quotidiennes afin qu'elles soient davantage axées sur les processus.

Problème

L'une de ces catégories d'activités de travail que nous effectuons régulièrement est la modification des bases de données - modification des schémas, modification ad hoc des enregistrements pour résoudre des problèmes, gestion des subventions, etc. Les SRE étaient les gardiens de ces changements pour les différentes équipes d'ingénieurs qui travaillaient directement sur les bases de données, dans un monde sans automatisation. Cette situation posait deux problèmes : d'une part, les SRE devenaient un goulot d'étranglement qui empêchait les équipes d'avancer suffisamment vite et, d'autre part, il n'existait que peu de traces d'audit des requêtes exécutées sur la base de données.

Pour résoudre ces problèmes, nous avons dû mettre au point un système d'automatisation permettant de

• aux ingénieurs de spécifier et d'exécuter le langage SQL qu'ils souhaitaient exécuter sur les bases de données (ce que nous appelons des plans de poussée)

• exécuter des contrôles sur les plans de poussée soumis qui empêchent les changements dangereux/malveillants d'être exécutés

• maintenir une piste d'audit de ce qui se passe dans une source canonique de vérité, de préférence un système de contrôle des versions (VCS)

Approche

Terraform était un excellent choix pour nous puisque nous l'utilisions déjà à grande échelle pour gérer notre infrastructure en nuage. L'un des aspects souvent négligés de Terraform est qu'il est excellent dans la gestion de l'état. En utilisant cette fonctionnalité, nous voulions permettre aux ingénieurs de spécifier les changements souhaités d'une manière déclarative et idempotente et laisser l'automatisation faire le gros du travail.

L'autre problème à résoudre était l'accès aux données. Pour des raisons de conformité, les ingénieurs de Vonage ne sont pas en possession des informations d'identification de la base de données. Nous stockons tous nos identifiants de manière cryptée à l'aide de AWS SecretsManager. Ainsi, même si nos ingénieurs n'y ont pas accès, notre automatisation peut accéder aux informations d'identification.

Enfin, nous avions besoin d'un runner pour exécuter en toute sécurité les pushplans spécifiés par les ingénieurs. Pour les vérifications proprement dites et l'exécution des plans de poussée, nous avons décidé d'utiliser Python, qui est largement utilisé dans notre outillage. L'ensemble du paquet a été exécuté sur Jenkins, ce qui nous a permis de démocratiser l'accès aux modifications de la base de données à l'ensemble de l'organisation d'ingénierie en toute sécurité.

Code

Plans de poussée SQL

Pour les pushplans SQL proprement dits, nous avons opté pour le bon vieux YAML. Si quelqu'un veut effectuer un changement dans la base de données, il suffit de spécifier le nom du cluster de base de données et le SQL qu'il veut exécuter comme ceci :

---
cluster: dblocal_wdc4
sql: |
    USE config;
    ALTER TABLE mt_routing ADD COLUMN routeToRoutingGroupId VARCHAR(50) NULL DEFAULT NULL AFTER routeToTargetGroupId;

Nous avons utilisé la fonction local-exec de Terraform pour exécuter un script Python qui effectuerait les changements dans la base de données :

resource "null_resource" "db_pushplan" {
  # This will rerun the pushplan if the file contents have been changed
  triggers = {
    hash = filebase64(var.pushplan_file)
  }

  provisioner "local-exec" {
    command = "pipenv run python ${path.module}/pushplan_executor.py -d ${var.db_host} -p ${var.db_port} -f ${var.pushplan_file}"

    environment = {
      db_username = var.db_username
      db_password = var.db_password
    }
  }
}

Note : Il est important de transmettre les informations d'identification au script sous forme de variables d'environnement : Il est important de transmettre les informations d'identification au script sous forme de variables d'environnement afin d'éviter qu'elles ne soient divulguées dans les journaux ou dans l'historique de bash.

Python

Le script python que nous avons utilisé pour exécuter le plan de poussée proprement dit ne se contente pas de l'exécuter. Il effectue d'abord une série de vérifications :

• S'assure que le cluster spécifié dans le plan de poussée est valide.

• Utilisation de l'outil Python sqlparse vérifie si le code SQL spécifié est valide.

• Si le code SQL contient des actions interdites - SELECT, GRANT, SHOW - il échoue rapidement en informant les utilisateurs de la ou des raisons.

• Exécute les instructions SQL en toute sécurité :

  • S'il y a plusieurs mises à jour, le système se met en veille entre les déclarations consécutives afin de ne pas surcharger la base de données.

  • S'il y a des ALTER, il utilisera gh-ost pour effectuer les changements en toute sécurité.

Conclusion

Il y a encore plusieurs améliorations que nous aimerions apporter à cet outil. Par exemple

• Utilisation de le fournisseur MySQL de Terraform de Terraform pour gérer les subventions. Ce fournisseur permet aux ingénieurs de miner et d'utiliser plus rapidement différents utilisateurs de base de données pour différentes Applications.

• Incorporer Flyway dans l'outil pour s'assurer qu'il sert également de source canonique de vérité pour tous nos schémas.

• Intégrer un mécanisme de promotion qui permette aux ingénieurs de tester les changements dans un premier temps dans un environnement non productif. Si ces changements fonctionnent correctement, les ingénieurs peuvent les promouvoir en version prod.

Et il y en aura bien d'autres. Cependant, nous disposons maintenant d'une bonne base pour étendre cette automatisation à tous les autres aspects de la gestion des bases de données avec le mécanisme de base défini.