Faça a gestão de regras de qualidade de dados como código com o Terraform

Este tutorial explica como gerir as regras de qualidade dos dados do catálogo universal do Dataplex como código com o Terraform, o Cloud Build e o GitHub.

Estão disponíveis muitas opções diferentes para regras de qualidade de dados para definir e medir a qualidade dos seus dados. Quando automatiza o processo de implementação de regras de qualidade de dados como parte da sua estratégia de gestão de infraestrutura mais ampla, garante que os seus dados são sujeitos de forma consistente e previsível às regras que lhes atribui.

Se tiver versões diferentes de um conjunto de dados para vários ambientes, como os ambientes dev e prod, o Terraform oferece uma forma fiável de atribuir regras de qualidade de dados a versões de conjuntos de dados específicas do ambiente.

O controlo de versões também é uma prática recomendada importante de DevOps. A gestão das regras de qualidade dos dados como código oferece-lhe versões das regras de qualidade dos dados que estão disponíveis no seu histórico do GitHub. O Terraform também pode guardar o respetivo estado no Cloud Storage, que pode armazenar versões anteriores do ficheiro de estado.

Para mais informações sobre o Terraform e o Cloud Build, consulte o artigo Vista geral do Terraform no Google Cloud e no Cloud Build.

Arquitetura

Para compreender como este tutorial usa o Cloud Build para gerir as execuções do Terraform, considere o seguinte diagrama de arquitetura. Tenha em atenção que usa ramificações do GitHub, dev e prod, para representar ambientes reais.

Infraestrutura com ambientes de desenvolvimento e produção.

O processo começa quando envia código do Terraform para o ramo dev ou prod. Neste cenário, o Cloud Build aciona e, em seguida, aplica os manifestos do Terraform para alcançar o estado pretendido no ambiente respetivo. Por outro lado, quando envia código Terraform para qualquer outro ramo, por exemplo, para um ramo de funcionalidade, o Cloud Build é executado para executar terraform plan, mas não é aplicado nada a nenhum ambiente.

Idealmente, os programadores ou os operadores têm de fazer propostas de infraestrutura para ramificações não protegidas e, em seguida, enviá-las através de pedidos de obtenção. A app GitHub do Cloud Build, abordada mais adiante neste tutorial, aciona automaticamente as tarefas de compilação e associa os relatórios terraform plan a estes pedidos de envio. Desta forma, pode discutir e rever as potenciais alterações com os colaboradores e adicionar commits de seguimento antes de as alterações serem unidas no ramo base.

Se não forem levantadas preocupações, tem de unir primeiro as alterações ao ramo dev Esta união aciona uma implementação de infraestrutura no ambiente dev, o que lhe permite testar este ambiente. Depois de testar e ter a certeza do que foi implementado, tem de unir a ramificação dev à ramificação prod para acionar a instalação da infraestrutura no ambiente de produção.

Objetivos

  • Configure o seu repositório do GitHub.
  • Configure o Terraform para armazenar o estado num contentor do Cloud Storage.
  • Conceda autorizações à sua conta de serviço do Cloud Build.
  • Associe o Cloud Build ao seu repositório do GitHub.
  • Estabeleça regras de qualidade de dados do Dataplex Universal Catalog.
  • Altere a configuração do ambiente num ramo de funcionalidades e teste.
  • Promova alterações para o ambiente de desenvolvimento.
  • Promova alterações para o ambiente de produção.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  7. No Cloud Shell, obtenha o ID do projeto que acabou de selecionar: 
    gcloud config get-value project
     Se este comando não devolver o ID do projeto, configure o Cloud Shell para usar o seu projeto. Substitua PROJECT_ID pelo ID do seu projeto. 
    gcloud config set project PROJECT_ID
  8. Ative as APIs necessárias: 
    gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com
     Este passo pode demorar alguns minutos a ser concluído.
  9. Se nunca usou o Git no Cloud Shell, configure-o com o seu nome e endereço de email: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    O Git usa estas informações para identificar o utilizador como o autor das confirmações que cria na Cloud Shell.

    10. Configure o seu repositório do GitHub

    Neste tutorial, usa um único repositório Git para definir a sua infraestrutura na nuvem. Orquestra esta infraestrutura com diferentes ramificações correspondentes a diferentes ambientes:

    • O ramo dev contém as alterações mais recentes que são aplicadas ao ambiente de desenvolvimento.
    • O ramo prod contém as alterações mais recentes que são aplicadas ao ambiente de produção.

    Com esta infraestrutura, pode sempre consultar o repositório para saber que configuração é esperada em cada ambiente e propor novas alterações, primeiro, ao juntá-las ao ambiente dev. Em seguida, promove as alterações ao unir a ramificação dev à ramificação prod subsequente.

    Para começar, crie uma ramificação do repositório terraform-google-dataplex-auto-data-quality.

    1. No GitHub, navegue para https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

    2. Clique em Criar ramificação.

      Agora, tem uma cópia do repositório com os ficheiros de origem.terraform-google-dataplex-auto-data-quality

    3. No Cloud Shell, clone o seguinte repositório bifurcado:

      cd ~
git clone https://github.com/GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
cd ~/terraform-google-dataplex-auto-data-quality

      Substitua o seguinte:

      • GITHUB_USERNAME: o seu nome de utilizador do GitHub

    4. Crie ramificações dev e prod:

      git checkout -b prod
git checkout -b dev

    O código neste repositório está estruturado da seguinte forma:

    • A pasta environments/ contém subpastas que representam ambientes, como dev e prod, que oferecem uma separação lógica entre cargas de trabalho em diferentes fases de maturidade, desenvolvimento e produção, respetivamente.

    • A pasta modules/ contém módulos Terraform incorporados. Estes módulos representam agrupamentos lógicos de recursos relacionados e são usados para partilhar código em diferentes ambientes. O módulo modules/deploy/ aqui representa um modelo para uma implementação e é reutilizado para diferentes ambientes de implementação.

    • Em modules/deploy/:

      • A pasta rule/ contém yaml ficheiros com regras de qualidade dos dados. Um ficheiro representa um conjunto de regras de qualidade dos dados para uma tabela. Este ficheiro é usado em ambientes dev e prod.

      • A pasta schemas/ contém o esquema da tabela para a tabela do BigQuery implementada nesta infraestrutura.

      • O ficheiro bigquery.tf contém a configuração das tabelas do BigQuery criadas nesta implementação.

      • O ficheiro dataplex.tf contém uma análise de dados do Dataplex Universal Catalog para qualidade de dados. Este ficheiro é usado em conjunto com o elemento rules_file_parsing.tf para ler regras de qualidade de dados de um ficheiro yaml no ambiente.

    • O ficheiro cloudbuild.yaml é um ficheiro de configuração de compilação que contém instruções para o Cloud Build, como a forma de realizar tarefas com base num conjunto de passos. Este ficheiro especifica uma execução condicional consoante o ramo do qual o Cloud Build está a obter o código, por exemplo:

      • Para os ramos dev e prod, são executados os seguintes passos:

        1. terraform init
        2. terraform plan
        3. terraform apply

      • Para qualquer outro ramo, são executados os seguintes passos:

        1. terraform init para todas as environments subpastas
        2. terraform plan para todas as environments subpastas

    Para garantir que as alterações propostas são adequadas para todos os ambientes, terraform init e terraform plan são executados para todos os ambientes. Antes de unir o pedido de obtenção, pode rever os planos para se certificar de que o acesso não está a ser concedido a uma entidade não autorizada, por exemplo.

    Configurar o Terraform para armazenar o estado em contentores do Cloud Storage

    Por predefinição, o Terraform armazena o estado localmente num ficheiro denominado terraform.tfstate. Esta configuração predefinida pode dificultar a utilização do Terraform para as equipas, especialmente quando muitos utilizadores executam o Terraform ao mesmo tempo e cada máquina tem a sua própria compreensão da infraestrutura atual.

    Para ajudar a evitar estes problemas, esta secção configura um estado remoto que aponta para um contentor do Cloud Storage. O estado remoto é uma funcionalidade dos servidores de back-end e, neste tutorial, é configurado no ficheiro backend.tf.

    # Copyright 2024 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate-dev"
  }
}

    Existe um ficheiro backend.tf separado em cada um dos ambientes dev e prod. É considerada uma prática recomendada usar um contentor do Cloud Storage diferente para cada ambiente.

    Nos passos seguintes, cria dois contentores do Cloud Storage para dev e prod e altera alguns ficheiros para apontarem para os novos contentores e para o seu projeto do Google Cloud .

    1. No Cloud Shell, crie os dois contentores do Cloud Storage:

      DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
gcloud storage buckets create ${DEV_BUCKET}

PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
gcloud storage buckets create ${PROD_BUCKET}

    2. Para manter o histórico das suas implementações, ative a opção Object Versioning:

      gcloud storage buckets update ${DEV_BUCKET} --versioning
gcloud storage buckets update ${PROD_BUCKET} --versioning

      A ativação do controlo de versões de objetos aumenta os custos de armazenamento, que pode mitigar configurando a gestão do ciclo de vida de objetos para eliminar versões de estado antigas.

    3. Em cada ambiente, nos ficheiros main.tf e backend.tf , substitua PROJECT_ID pelo ID do projeto:

      cd ~/terraform-google-dataplex-auto-data-quality
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf

      No OS X ou macOS, pode ter de adicionar duas aspas ("") após sed -i, da seguinte forma:

      cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf

    4. Verifique se todos os ficheiros foram atualizados:

      git status

      Segue-se um exemplo de saída:

      On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/main.tf
       modified:   environments/prod/backend.tf
       modified:   environments/prod/main.tf
no changes added to commit (use "git add" and/or "git commit -a")

    5. Confirme e envie as alterações:

      git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

      Consoante a sua configuração do GitHub, tem de se autenticar para enviar as alterações anteriores.

    Conceda autorizações à sua conta de serviço do Cloud Build

    Para permitir que a conta de serviço do Cloud Build execute scripts do Terraform com o objetivo de gerir recursos, tem de lhe conceder o acesso adequado ao seu projeto. Google Cloud Para simplificar, o acesso de editor do projeto é concedido neste tutorial. No entanto, quando a função de editor do projeto tem uma permissão de grande alcance, em ambientes de produção, tem de seguir as práticas recomendadas de segurança de TI da sua empresa, normalmente fornecendo acesso com privilégios mínimos.

    1. No Cloud Shell, obtenha o email da conta de serviço do Cloud Build do seu projeto:

      CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

    2. Conceda o acesso necessário à sua conta de serviço do Cloud Build:

      gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$CLOUDBUILD_SA --role roles/editor

    Associe diretamente o Cloud Build ao seu repositório do GitHub

    Esta secção descreve como instalar a app GitHub do Cloud Build. Esta instalação permite-lhe associar o seu repositório GitHub ao seu projetoGoogle Cloud para que o Cloud Build possa aplicar automaticamente os seus manifestos do Terraform sempre que criar um novo ramo ou enviar código para o GitHub.

    Os passos seguintes fornecem instruções para instalar a app apenas para o repositório terraform-google-dataplex-auto-data-quality, mas pode optar por instalar a app para mais ou todos os seus repositórios.

    1. No GitHub Marketplace, aceda à página da app Cloud Build.

      • Se for a primeira vez que configura uma app no GitHub: clique em Configurar com o Google Cloud Build na parte inferior da página. Em seguida, clique em Conceder acesso desta app à sua conta do GitHub.
      • Se não for a primeira vez que configura uma app no GitHub: clique em Configurar acesso. É aberta a página Aplicações da sua conta pessoal.

    2. Clique em Configurar na linha do Cloud Build.

    3. Selecione Selecionar apenas repositórios e, de seguida, selecione terraform-google-dataplex-auto-data-quality para estabelecer ligação ao repositório.

    4. Clique em Guardar ou Instalar. A etiqueta do botão muda consoante o seu fluxo de trabalho. É feito o redirecionamento para Google Cloud para continuar a instalação.

    5. Inicie sessão com a sua conta do Google Cloud . Se lhe for pedido, autorize a integração do Cloud Build com o GitHub.

    6. Na página Cloud Build, selecione o seu projeto. É apresentado um assistente.

    7. Na secção Selecionar repositório, selecione a sua conta do GitHub e o repositório terraform-google-dataplex-auto-data-quality.

    8. Se concordar com os termos de utilização, selecione a caixa de verificação e, de seguida, clique em Associar.

    9. Na secção Crie um acionador, clique em Crie um acionador:

      1. Adicione um nome do acionador, como push-to-branch. Tome nota do nome deste acionador, pois vai precisar dele mais tarde.
      2. Na secção Evento, selecione Enviar para uma ramificação.
      3. Na secção Origem, selecione .* no campo Filial.
      4. Clique em Criar.

    A app GitHub do Cloud Build está configurada e o seu repositório do GitHub está associado ao seu Google Cloud projeto. As alterações ao repositório do GitHub acionam execuções do Cloud Build, que comunicam os resultados ao GitHub através do GitHub Checks.

    Altere a configuração do ambiente num novo ramo de funcionalidades

    Tem a maior parte do ambiente configurada. Faça as alterações de código necessárias no seu ambiente local:

    1. No GitHub, navegue para a página principal do repositório bifurcado.

      https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

    2. Certifique-se de que está na ramificação dev.

    3. Para abrir o ficheiro para edição, aceda ao ficheiro modules/deploy/dataplex.tf.

    4. Na linha 19, altere a etiqueta the_environment para environment.

    5. Adicione uma mensagem de confirmação na parte inferior da página, como "modificar etiqueta", e selecione Criar um novo ramo para esta confirmação e iniciar um pedido de obtenção.

    6. Clique em Propor alterações.

    7. Na página seguinte, clique em Create pull request para abrir um novo pedido de envio com a sua alteração ao ramo dev.

      Depois de o pedido de obtenção estar aberto, é iniciado automaticamente um trabalho do Cloud Build.

    8. Clique em Mostrar todas as verificações e aguarde até que a verificação fique verde. Não associe o seu pedido de envio já. A união é feita num passo posterior do tutorial.

    9. Clique em Detalhes para ver mais informações, incluindo o resultado do terraform plan no link Ver mais detalhes no Google Cloud Build.

    Tenha em atenção que a tarefa do Cloud Build executou o pipeline definido no ficheiro cloudbuild.yaml. Este pipeline tem comportamentos diferentes consoante o ramo que está a ser obtido. A compilação verifica se a variável $BRANCH_NAME corresponde a alguma pasta de ambiente. Se for o caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, o Cloud Build executa terraform plan para todos os ambientes para garantir que a alteração proposta é adequada para todos eles. Se algum destes planos não for executado, a compilação falha.

    - id: 'tf plan'
  name: 'hashicorp/terraform:1.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

    Da mesma forma, o comando terraform apply é executado para ramificações do ambiente, mas é completamente ignorado em qualquer outro caso. Nesta secção, enviou uma alteração de código para um novo ramo, pelo que não foram aplicadas implementações de infraestrutura ao seu Google Cloud projeto.

    - id: 'tf apply'
  name: 'hashicorp/terraform:1.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

    Aplique o sucesso da execução do Cloud Build antes de unir ramificações

    Para garantir que as unificações só podem ser aplicadas quando as respetivas execuções do Cloud Build são bem-sucedidas, siga estes passos:

    1. No GitHub, navegue para a página principal do repositório bifurcado.

      https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

    2. Abaixo do nome do repositório, clique em Definições.

    3. No menu do lado esquerdo, clique em Ramos.

    4. Em Regras de proteção de ramificações, clique em Adicionar regra.

    5. Em Padrão do nome da ramificação, escreva dev.

    6. Na secção Proteger ramos correspondentes, selecione Exigir que as verificações de estado sejam aprovadas antes da união.

    7. Pesquise o nome do acionador do Cloud Build criado anteriormente.

    8. Clique em Criar.

    9. Repita os passos 3 a 7, definindo o Padrão do nome da ramificação como prod.

    Esta configuração é importante para proteger os ramos dev e prod. Isto significa que os commits têm de ser enviados primeiro para outro ramo e só depois podem ser unidos ao ramo protegido. Neste tutorial, a proteção requer que a execução do Cloud Build seja bem-sucedida para permitir a união.

    Promova alterações para o ambiente de desenvolvimento

    Tem um pedido de obtenção a aguardar a união. Está na altura de aplicar o estado que quer ao seu ambiente dev.

    1. No GitHub, navegue para a página principal do repositório bifurcado.

      https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

    2. Abaixo do nome do repositório, clique em Pedidos de obtenção.

    3. Clique no pedido de obtenção que acabou de criar.

    4. Clique em Unir pedido de envio e, de seguida, em Confirmar união.

    5. Verifique se foi acionado um novo Cloud Build:

      Aceda à página do Cloud Build

    6. Abra a compilação e verifique os registos. São apresentados todos os recursos que o Terraform está a criar e gerir.

    Promova alterações para o ambiente de produção

    Agora que o seu ambiente de desenvolvimento foi totalmente testado, pode promover o código das regras de qualidade dos dados para produção.

    1. No GitHub, navegue para a página principal do repositório bifurcado.

      https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

    2. Abaixo do nome do repositório, clique em Pedidos de obtenção.

    3. Clique em Novo pedido de envio.

    4. Para o repositório base, selecione o repositório que acabou de criar.

    5. Para base, selecione prod no seu próprio repositório base. Para comparar, selecione dev.

    6. Clique em Criar pedido de obtenção.

    7. Para título, introduza um título, como Changing label name, e, em seguida, clique em Criar pedido de envio.

    8. Reveja as alterações propostas, incluindo os detalhes do terraform planCloud Build, e, de seguida, clique em Unir pedido de obtenção.

    9. Clique em Confirmar união.

    10. Na Google Cloud consola, abra a página Histórico de compilações para ver as alterações aplicadas ao ambiente de produção:

      Aceda à página do Cloud Build

    Configurou com êxito regras de qualidade de dados geridas através do Terraform e do Cloud Build.

    Limpar

    Depois de concluir o tutorial, limpe os recursos que criou no Google Cloud para que não lhe sejam faturados no futuro.

    Elimine o projeto

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    Elimine o repositório do GitHub

    Para evitar o bloqueio de novos pedidos de obtenção no seu repositório do GitHub, pode eliminar as regras de proteção de ramos:

    1. No GitHub, navegue para a página principal do repositório criado a partir de outro.
    2. Abaixo do nome do repositório, clique em Definições.
    3. No menu do lado esquerdo, clique em Ramos.
    4. Na secção Regras de proteção de ramificações, clique no botão Eliminar para as linhas dev e prod.

    Opcionalmente, pode desinstalar completamente a app Cloud Build do GitHub:

    1. No GitHub, aceda à página de aplicações do GitHub.

    2. No separador Apps GitHub instaladas, clique em Configurar na linha Cloud Build. Em seguida, na secção Zona de perigo, clique no botão Desinstalar na linha Desinstalar o Google Cloud Builder.

      Na parte superior da página, é apresentada a mensagem "Está tudo pronto. Foi adicionada uma tarefa à fila para desinstalar o Google Cloud Build."

    3. No separador Apps GitHub autorizadas, clique no botão Revogar na linha Google Cloud Build e, de seguida, em Compreendo, revogar acesso.

    Se não quiser manter o seu repositório do GitHub, elimine-o:

    1. No GitHub, aceda à página principal do repositório bifurcado.
    2. Abaixo do nome do repositório, clique em Definições.
    3. Aceda a Zona de perigo.
    4. Clique em Eliminar este repositório e siga os passos de confirmação.

    O que se segue?