Utilização do Terraform para gerenciamento de bancos de dados

Uma das jornadas mais importantes que estamos empreendendo aqui na Vonage é nos transformarmos em uma organização de engenharia ágil, utilizando os princípios da engenharia de confiabilidade do site (SRE). E isso significa que somos quase alérgicos a trabalho pesado.

O trabalho árduo é aquele que tende a ser manual, repetitivo, automatizável, tático, desprovido de valor duradouro e que se expande linearmente à medida que um serviço cresce.

Estamos constantemente buscando maneiras de tornar as tarefas rotineiras mais orientadas a processos por meio da automação.

Problema

Uma dessas categorias de atividades rotineiras nas quais nos envolvemos regularmente são as alterações no banco de dados — modificações no esquema, modificações pontuais em registros para corrigir problemas, gerenciamento de permissões, etc. Os SREs eram os responsáveis por aprovar essas alterações para as diferentes equipes de engenharia diretamente nos bancos de dados, em um cenário sem automação. Essa situação apresentava dois problemas: os SREs se tornavam o gargalo, impedindo que as equipes agissem com a rapidez necessária, e havia pouca informação em termos de trilha de auditoria das consultas efetivamente executadas no banco de dados.

Para resolver esses problemas, precisávamos criar uma automação que permitisse

• engenheiros para especificar e executar as consultas SQL que desejavam executar nos bancos de dados (o que chamamos de “pushplans”)

• realizar verificações nos planos de envio apresentados para impedir que alterações inseguras ou maliciosas sejam aprovadas

• manter um registro de auditoria do que está ocorrendo em uma fonte canônica de verdade, de preferência algum sistema de controle de versão (VCS)

Abordagem

O Terraform foi uma excelente escolha para nós, já que já o utilizávamos em grande escala para gerenciar nossa infraestrutura em nuvem. Um dos aspectos frequentemente ignorados do Terraform é que ele é excelente no gerenciamento do estado. Com essa funcionalidade, queríamos permitir que os engenheiros especificassem as alterações desejadas de maneira declarativa e idempotente, deixando que a automação fizesse o trabalho pesado.

A outra questão a ser abordada era o acesso aos dados. Por motivos de conformidade, os engenheiros da Vonage não têm acesso imediato às credenciais do banco de dados. Armazenamos todas as nossas credenciais de forma criptografada usando AWS SecretsManager. Assim, embora nossos engenheiros não tivessem acesso a elas, nossa automação conseguia acessar as credenciais.

Por fim, precisávamos de um executor para executar com segurança os planos de implementação especificados pelos engenheiros. Para as verificações propriamente ditas e a execução desses planos, decidimos usar Python, linguagem amplamente utilizada em muitas de nossas ferramentas. E todo o pacote foi executado no Jenkins, o que nos permitiu democratizar o acesso para que toda a equipe de engenharia pudesse realizar alterações no banco de dados com segurança.

Código

Planos de execução do SQL

Para os planos de execução SQL propriamente ditos, optamos pelo bom e velho YAML. Se alguém quiser fazer uma alteração no banco de dados, basta especificar o nome do cluster do banco de dados e a instrução SQL que deseja executar, desta forma:

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

Utilizamos o local-exec para executar um script em Python que faria as alterações no banco de dados:

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

Observação: É importante passar as credenciais para o script como variáveis de ambiente para evitar que elas sejam expostas nos logs ou no histórico do bash.

Python

O script em Python que usamos para executar o plano de envio propriamente dito faz mais do que apenas executá-lo. Inicialmente, ele realiza uma série de verificações:

• Verifica se o cluster especificado no plano de envio é válido

• Usando o Python sqlparse , verifica se o SQL especificado é válido.

• Se a consulta SQL contiver alguma ação não permitida — SELECT, GRANT, SHOW —, ela será rejeitada imediatamente, informando aos usuários o(s) motivo(s).

• Executa as instruções SQL propriamente ditas com segurança:

  • Se houver várias atualizações, o sistema entrará em espera entre instruções consecutivas para não sobrecarregar o banco de dados.

  • Se houver comandos ALTER, ele utilizará gh-ost para aplicar as alterações com segurança.

Conclusão

Ainda há várias melhorias que gostaríamos de incorporar a essa ferramenta. Por exemplo:

• Usando o provedor MySQL do Terraform para gerenciar permissões. Esse provedor permite que os engenheiros criem e utilizem diferentes usuários de banco de dados para diferentes Applications com mais rapidez.

• Incorporando Flyway na ferramenta para garantir que ela também sirva como fonte canônica de verdade para todos os nossos esquemas.

• Implemente um mecanismo de promoção que permita aos engenheiros testar as alterações primeiro em um ambiente não produtivo. Se forem executadas com sucesso, os engenheiros poderão promover essas alterações para o ambiente produtivo.

E haverá muitos outros. No entanto, isso já nos proporcionou uma boa base para estender essa automação a todos os outros aspectos do gerenciamento de bancos de dados, agora que o mecanismo básico já está definido.