Uso de Terraform para la gestión de bases de datos

Uno de los viajes más importantes que estamos emprendiendo aquí en Vonage es transformarnos en una organización de ingeniería ágil que utilice los principios de la ingeniería de fiabilidad del sitio (SRE). Y eso significa que somos casi alérgicos al trabajar.

El trabajo duro es el tipo de trabajo que tiende a ser manual, repetitivo, automatizable, táctico, carente de valor duradero y que se escala linealmente a medida que crece un servicio.

Buscamos constantemente formas de hacer que las tareas habituales estén más orientadas a los procesos mediante la automatización.

Problema

Una de estas actividades que realizamos con regularidad son los cambios en las bases de datos: alteraciones de esquemas, modificaciones ad hoc de registros para solucionar problemas, gestión de subvenciones, etc. Los SRE eran los guardianes que afectaban a estos cambios para diferentes equipos de ingeniería directamente en las bases de datos en un mundo sin automatización. Esta situación planteaba dos problemas: por un lado, los SRE se convertían en el cuello de botella que impedía a los equipos avanzar con suficiente rapidez y, por otro, apenas existía un registro de auditoría de las consultas reales que se ejecutaban en la base de datos.

Para resolver estos problemas, necesitábamos idear una automatización que permitiera

• los ingenieros podían especificar y ejecutar el SQL que querían ejecutar en las bases de datos (lo que denominamos pushplans)

• ejecutar comprobaciones en los planes push enviados que impidan que se realicen cambios inseguros o malintencionados

• mantener un registro de auditoría de lo que ocurre en una fuente de verdad canónica, preferiblemente algún sistema de control de versiones (VCS)

Acérquese a

Terraform fue una excelente opción para nosotros, puesto que ya lo estábamos utilizando a gran escala para gestionar nuestra infraestructura en la nube. Uno de los aspectos que a menudo se pasan por alto de Terraform es que es excelente en la gestión del estado. Utilizando esta funcionalidad, queríamos permitir a los ingenieros especificar los cambios deseados de forma declarativa e idempotente y dejar que la automatización hiciera el trabajo pesado.

La otra cuestión que había que abordar era el acceso a los datos. Por razones de cumplimiento, los ingenieros de Vonage no están en posesión de las credenciales de la base de datos. Almacenamos todas nuestras credenciales de forma cifrada utilizando AWS SecretsManager. Así, aunque nuestros ingenieros no tuvieran acceso a ellas, nuestra automatización podía acceder a las credenciales.

Por último, necesitábamos un "runner" para ejecutar de forma segura los "pushplans" especificados por los ingenieros. Para las comprobaciones reales y la ejecución de los pushplans decidimos utilizar Python, que se utiliza ampliamente en muchas de nuestras herramientas. Y todo el paquete se ejecutó en Jenkins, lo que nos permitió democratizar el acceso para realizar cambios en la base de datos a toda la organización de ingeniería de forma segura.

Código

Planes SQL

Para los planes SQL en sí, utilizamos el viejo YAML. Si alguien quiere realizar un cambio en la base de datos, sólo tiene que especificar el nombre del clúster de base de datos y el SQL que desea ejecutar:

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

Utilizamos Terraform local-exec para ejecutar un script de Python que realizaría los cambios en la base de datos:

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
    }
  }
}

Nota: Es importante pasar las credenciales al script como variables de entorno para evitar que se filtren en los logs o en el historial de bash.

Python

El script de python que utilizamos para ejecutar el plan push real hace algo más que ejecutarlo. Inicialmente, realiza una serie de comprobaciones:

• Asegura que el cluster especificado en el pushplan es válido

• Utilizando la herramienta de Python sqlparse comprueba si el SQL especificado es válido.

• Si el SQL contiene alguna acción no permitida - SELECT, GRANT, SHOW - falla rápidamente informando a los usuarios de la/s razón/es.

• Ejecuta las sentencias SQL reales de forma segura:

  • Si hay varias actualizaciones, se dormirá entre sentencias consecutivas para no sobrecargar la base de datos.

  • Si hay ALTERs, utilizará gh-ost para realizar los cambios de forma segura.

Conclusión

Todavía hay varias mejoras que nos gustaría incorporar a esta herramienta. Por ejemplo

• Uso de Proveedor MySQL de Terraform para realizar la gestión de subvenciones. Este proveedor permite a los ingenieros acuñar y utilizar diferentes usuarios de bases de datos para diferentes aplicaciones de forma más rápida.

• Incorporación de Flyway en la herramienta para garantizar que también sirva como fuente canónica de verdad para todos nuestros esquemas.

• Incorporar un mecanismo de promoción que permita a los ingenieros probar primero los cambios que no sean de producción. Si se comprueba que funcionan correctamente, los ingenieros pueden promover esos cambios a prod.

Y habrá muchos más. Sin embargo, ahora nos ha dado una buena base para extender esta automatización a todos los demás aspectos de la gestión de bases de datos con el conjunto de mecanismos de base.