Entrega contínua no estilo GitOps com o Cloud Build

Nesta página, explicamos como criar um pipeline de integração e entrega contínuas (CI/CD, na sigla em inglês) no Google Cloud usando apenas produtos hospedados e a famosa metodologia GitOps.

Há muito tempo que os engenheiros do Google armazenam arquivos de configuração e implantação em nosso repositório de código-fonte principal. Esta metodologia é descrita no capítulo 8 do livro Engenharia de Confiabilidade do Site ( Beyer et. Al., 2016 ), e foi demonstrada por Kelsey Hightower durante sua apresentação feita no Google Cloud Next de 2017 (em inglês). O termo “GitOps” foi cunhado pela Weaveworks. Uma parte fundamental do GitOps é a ideia de “ambientes como código”: descrever as implementações de maneira declarativa, usando arquivos, como manifestos do Kubernetes, armazenados em um repositório Git.

Neste tutorial, você vai criar um pipeline de CI/CD que gera automaticamente uma imagem de contêiner com base no código confirmado, armazena a imagem no Artifact Registry, atualiza um manifesto do Kubernetes em um repositório Git e implanta o aplicativo no Google Kubernetes Engine (GKE) usando esse manifesto.

Arquitetura do pipeline de CI/CD

Neste tutorial, usaremos dois repositórios Git:

Repositório do aplicativo: contém o código-fonte do próprio aplicativo.
Repositório do ambiente: contém os manifestos para a implantação no Kubernetes.

Quando você envia uma alteração para o repositório do app, o pipeline do Cloud Build executa testes, cria uma imagem de contêiner e a envia para o Artifact Registry. Depois de enviar a imagem, o Cloud Build atualiza o manifesto de implantação e o envia para o repositório do ambiente. Isso aciona outro pipeline do Cloud Build que aplica o manifesto ao cluster do GKE e, se bem-sucedido, armazena o manifesto em outra ramificação do repositório do ambiente.

Mantemos os repositórios do aplicativo e do ambiente separados porque eles têm utilidades e ciclos de vida diferentes. O repositório do aplicativo é dedicado a um aplicativo específico e é usado principalmente por pessoas reais. Os principais usuários do repositório do ambiente são sistemas automatizados, como o Cloud Build, e ele pode ser compartilhado por vários aplicativos. O repositório do ambiente pode ter várias ramificações, cada uma mapeando para um ambiente específico (você usará apenas o de produção neste tutorial). Ele cita uma imagem de contêiner específica, o que não acontece com o repositório do aplicativo.

Ao terminar este tutorial, você terá um sistema em que facilmente poderá:

distinguir entre implantações com falha e bem-sucedidas observando o histórico do Cloud Build;
acessar o manifesto usado atualmente observando o branch de produção do repositório do ambiente;
reverter para qualquer versão anterior bastando executar novamente a versão correspondente do Cloud Build.

Fluxo do pipeline de CI/CD

Sobre este tutorial

Neste tutorial, usamos o Cloud Source Repositories para hospedar repositórios do Git. No entanto, é possível chegar aos mesmos resultados com produtos de terceiros, como GitHub, Bitbucket ou GitLab.

Este pipeline não implementa um mecanismo de validação antes da implantação. Se você usa o GitHub, o Bitbucket ou o GitLab, é possível modificar o pipeline para usar uma solicitação de envio com essa finalidade.

Recomendamos o Spinnaker para as equipes que querem implementar padrões avançados de implantação (azul/verde, análise de teste canário, várias nuvens etc.). No entanto, o conjunto de recursos dessa solução talvez não seja necessário para que organizações e projetos menores tenham uma estratégia de CI/CD bem-sucedida. Neste tutorial, você aprenderá como criar um ajuste de pipeline de CI/CD para aplicativos hospedados no GKE com ferramentas.

Para simplificar, este tutorial usa um único ambiente, o de produção, no repositório do ambiente, mas é possível estendê-lo à implantação em vários ambientes, se necessário.

Objetivos

Criar repositórios Git no Cloud Source Repositories.
Criar uma imagem de contêiner com o Cloud Build e armazená-la no Artifact Registry.
Criar um pipeline de CI.
Criar um pipeline de CD.
Testar o pipeline de CI/CD.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

Selecione ou crie um projeto do Google Cloud.

Acessar "Gerenciar recursos"
Ative o faturamento no projeto.

Ativar faturamento
Abra o Cloud Shell para executar os comandos listados neste tutorial. O Cloud Shell é um ambiente shell interativo para o Google Cloud que permite gerenciar projetos e recursos a partir do navegador da Web.

Acessar o Cloud Shell
Se o comando gcloud config get-value project não retornar o ID do projeto que foi selecionado, configure o Cloud Shell para usar seu projeto.
```
gcloud config set project [PROJECT_ID]
```

No Cloud Shell, ative as APIs necessárias.

gcloud services enable container.googleapis.com \
    cloudbuild.googleapis.com \
    sourcerepo.googleapis.com \
    artifactregistry.googleapis.com

Crie um repositório do Docker do Artifact Registry chamado my-repository na região us-central1 para armazenar as imagens de contêiner.
```
gcloud artifacts repositories create my-repository \
  --repository-format=docker \
  --location=us-central1
```
No Cloud Shell, crie um cluster do GKE que você usará para implantar o aplicativo de amostra deste tutorial.
Piloto automático
Crie um cluster do Autopilot chamado hello-cloudbuild:
```
gcloud container clusters create-auto hello-cloudbuild \
    --region us-central1
```
Padrão
Crie um cluster padrão de um nó chamado hello-cloudbuild:
```
gcloud container clusters create hello-cloudbuild \
    --num-nodes 1 --region us-central1
```
Se você nunca usou o Git no Cloud Shell, configure-o com seu nome e endereço de e-mail. O Git usará essas informações para identificar você como autor das confirmações a serem criadas no Cloud Shell.
```
git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
```

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Veja mais detalhes em Limpar.

Como criar repositórios Git no Cloud Source Repositories

Nesta seção, você criará os dois repositórios Git, do aplicativo e do ambiente, que serão usados neste tutorial e inicializará o repositório do aplicativo com um código de amostra.

No Cloud Shell, crie os dois repositórios Git.

gcloud source repos create hello-cloudbuild-app
gcloud source repos create hello-cloudbuild-env

Clone o código de amostra do GitHub.

cd ~
git clone https://github.com/GoogleCloudPlatform/gke-gitops-tutorial-cloudbuild \
    hello-cloudbuild-app

Configure o Cloud Source Repositories como remoto.

cd ~/hello-cloudbuild-app
PROJECT_ID=$(gcloud config get-value project)
git remote add google \
    "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"

O código clonado contém um aplicativo "Hello World".

app.py

Ver no GitHub

from flask import Flask
app = Flask('hello-cloudbuild')

@app.route('/')
def hello():
  return "Hello World!\n"

if __name__ == '__main__':
  app.run(host = '0.0.0.0', port = 8080)

Como criar uma imagem de contêiner com o Cloud Build

O código que você clonou contém o Dockerfile a seguir.

Dockerfile

Ver no GitHub

FROM python:3.7-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]

Com esse Dockerfile, crie uma imagem de contêiner com o Cloud Build e armazene-a no Artifact Registry.

No Cloud Shell, crie uma versão do Cloud Build com base na confirmação mais recente usando o comando abaixo.
```
cd ~/hello-cloudbuild-app
COMMIT_ID="$(git rev-parse --short=7 HEAD)"
gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
```
O Cloud Build faz o streaming dos registros gerados pela criação da imagem do contêiner para seu terminal quando você executa esse comando.
Depois de concluir a versão, verifique se a nova imagem do contêiner está realmente disponível no Artifact Registry.

Acessar o Artifact Registry

Como criar o pipeline de integração contínua

Nesta seção, você configurará o Cloud Build para executar automaticamente um teste de unidade pequeno, construirá a imagem do contêiner e, por fim, enviará essa imagem para o Artifact Registry. Enviar uma nova confirmação para o Cloud Source Repositories aciona automaticamente esse pipeline. O arquivo cloudbuild.yaml incluído no código é a configuração do pipeline.

cloudbuild.yaml

Ver no GitHub

steps:
# This step runs the unit tests on the app
- name: 'python:3.7-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'

Abra a página Gatilhos do Cloud Build.

Acessar acionadores
Clique em Criar gatilho.
Preencha as opções a seguir:
- No campo Nome, digite hello-cloudbuild.
- Em Evento, selecione Mover para uma ramificação.
- Em Origem, selecione hello-cloudbuild-app como Repositório e ^master$ como Ramificação.
- Em Configuração da compilação, selecione arquivo de configuração do Cloud Build.
- No campo local do arquivo de configuração do Cloud Build, digite cloudbuild.yaml depois do /.
Clique em Criar para salvar o gatilho de compilação.

Dica: se você precisar criar acionadores de versão para vários projetos, use a API Build Triggers.
No Cloud Shell, envie o código do aplicativo para o Cloud Source Repositories para acionar o pipeline de CI no Cloud Build.
```
cd ~/hello-cloudbuild-app
git push google master
```
Abra o console do Cloud Build.

Acessar o Cloud Build

Suas versões recém-executadas e concluídas serão exibidas. Se quiser, clique na versão para acompanhar a execução e examinar os registros.

Como criar o pipeline de entrega contínua

O Cloud Build também é usado para o pipeline de entrega contínua. Esse pipeline é executado sempre que uma confirmação é enviada para o branch candidato do repositório hello-cloudbuild-env. O pipeline aplica a versão nova do manifesto ao cluster do Kubernetes e, se bem-sucedido, copia o manifesto para o branch de produção. Esse processo tem as seguintes propriedades:

O branch candidato é um histórico das tentativas de implantação.
O branch de produção é um histórico das implantações bem-sucedidas.
É possível ver as implantações bem-sucedidas e com falha no Cloud Build.
É possível reverter para qualquer implantação anterior, bastando executar novamente a versão correspondente no Cloud Build. A reversão também atualiza o branch de produção para refletir fielmente o histórico de implantações.

Você modificará o pipeline de integração contínua para atualizar o branch candidato do repositório hello-cloudbuild-env, acionando o pipeline de entrega contínua.

Como conceder acesso do GKE ao Cloud Build

Para implantar o aplicativo no cluster do Kubernetes, o Cloud Build precisa do papel de gerenciamento de identidade e acesso do desenvolvedor do Kubernetes Engine.

Shell

No Cloud Shell, execute o comando a seguir:

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')"
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

Console

No Console do Google Cloud, abra a página "Configurações do Cloud Build":
Abrir as configurações do Cloud Build

A página Permissões da conta de serviço é exibida:
Defina o status do papel Desenvolvedor do Kubernetes Engine como Ativado.

Como inicializar o repositório hello-cloudbuild-env

É necessário inicializar o repositório hello-cloudbuild-env com dois branches, de produção e candidato, e um arquivo de configuração do Cloud Build que descreve o processo de implantação.

No Cloud Shell, clone o repositório hello-cloudbuild-env e crie o branch de produção.

cd ~
gcloud source repos clone hello-cloudbuild-env
cd ~/hello-cloudbuild-env
git checkout -b production

Copie o arquivo cloudbuild-delivery.yaml disponível no repositório hello-cloudbuild-app e confirme a alteração.

cd ~/hello-cloudbuild-env
cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/hello-cloudbuild-env/cloudbuild.yaml
git add .
git commit -m "Create cloudbuild.yaml for deployment"

O arquivo cloudbuild-delivery.yaml descreve o processo de implantação a ser executado no Cloud Build. Isso é feito em duas etapas:

O Cloud Build aplica o manifesto no cluster do GKE.
Se bem-sucedido, o Cloud Build copia o manifesto no branch de produção.

cloudbuild-delivery.yaml

Ver no GitHub

steps:
# This step deploys the new version of our container image
# in the hello-cloudbuild Kubernetes Engine cluster.
- name: 'gcr.io/cloud-builders/kubectl'
  id: Deploy
  args:
  - 'apply'
  - '-f'
  - 'kubernetes.yaml'
  env:
  - 'CLOUDSDK_COMPUTE_REGION=us-central1'
  - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'

# This step copies the applied manifest to the production branch
# The COMMIT_SHA variable is automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/git'
  id: Copy to production branch
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    # Configure Git to create commits with Cloud Build's service account
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
    # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
    git fetch origin production && git checkout production && \
    git checkout $COMMIT_SHA kubernetes.yaml && \
    # Commit the kubernetes.yaml file with a descriptive commit message
    git commit -m "Manifest from commit $COMMIT_SHA
    $(git log --format=%B -n 1 $COMMIT_SHA)" && \
    # Push the changes back to Cloud Source Repository
    git push origin production

Crie um branch candidato e envie os dois branches para que fiquem disponíveis no Cloud Source Repositories.
```
git checkout -b candidate
git push origin production
git push origin candidate
```

Conceda o papel de IAM de Gravador do repositório de origem à conta de serviço do Cloud Build para o repositório hello-cloudbuild-env.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
    --format='get(projectNumber)')"
cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com
  role: roles/source.writer
EOF
gcloud source repos set-iam-policy \
    hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml

Como criar o gatilho do pipeline de entrega contínua

Nesta seção, você configurará o Cloud Build para que seja acionado por um envio no branch candidato do repositório hello-cloudbuild-env.

Abra a página Gatilhos do Cloud Build.

Acessar acionadores
Clique em Criar gatilho.
Preencha as opções a seguir:
- No campo Nome, digite hello-cloudbuild-deploy.
- Em Evento, selecione Mover para uma ramificação.
- Em Origem, selecione hello-cloudbuild-env como Repositório e ^candidate$ como Ramificação.
- Em Configuração, selecione arquivo de configuração do Cloud Build (yaml ou json).
- No campo local do arquivo de configuração do Cloud Build, digite cloudbuild.yaml depois do /.
Clique em Criar.

Como modificar o pipeline de integração contínua para acionar o pipeline de entrega contínua

Nesta seção, você adicionará algumas etapas ao pipeline de integração contínua que gerará uma nova versão do manifesto do Kubernetes e, depois, enviará esse manifesto para o repositório hello-cloudbuild-env para acionar o pipeline de entrega contínua.

Substitua o arquivo cloudbuild.yaml pelo exemplo estendido no arquivo cloudbuild-trigger-cd.yaml.

cd ~/hello-cloudbuild-app
cp cloudbuild-trigger-cd.yaml cloudbuild.yaml

O cloudbuild-trigger-cd.yaml é uma versão estendida do arquivo cloudbuild.yaml. Ele adiciona etapas para gerar o novo manifesto do Kubernetes e acionar o pipeline de entrega contínua.

cloudbuild-trigger-cd.yaml

Ver no GitHub

# This step clones the hello-cloudbuild-env repository
- name: 'gcr.io/cloud-builders/gcloud'
  id: Clone env repository
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    gcloud source repos clone hello-cloudbuild-env && \
    cd hello-cloudbuild-env && \
    git checkout candidate && \
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')

# This step generates the new manifest
- name: 'gcr.io/cloud-builders/gcloud'
  id: Generate manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml

# This step pushes the manifest back to hello-cloudbuild-env
- name: 'gcr.io/cloud-builders/gcloud'
  id: Push manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    cd hello-cloudbuild-env && \
    git add kubernetes.yaml && \
    git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin candidate

Confirme as modificações e envie-as para o Cloud Source Repositories.
```
cd ~/hello-cloudbuild-app
git add cloudbuild.yaml
git commit -m "Trigger CD pipeline"
git push google master
```
Isso aciona o pipeline de integração contínua no Cloud Build.
Examine a versão de integração contínua.

Acessar o Cloud Build

Suas versões executadas e concluídas recentemente para o repositório hello-cloudbuild-app são exibidas. Se quiser, clique na versão para acompanhar a execução e examinar os registros. A última etapa desse pipeline envia o manifesto novo para o repositório hello-cloudbuild-env, que aciona o pipeline de entrega contínua.
Examine a versão de entrega contínua.

Acessar o Cloud Build

Suas versões executadas e concluídas recentemente para o repositório hello-cloudbuild-env são exibidas. Se quiser, clique na versão para acompanhar a execução e examinar os registros.

Como testar o pipeline completo

O pipeline de CI/CD completo agora está configurado. Nesta seção, você testará o pipeline inteiro.

Acesse a página “Serviços” do GKE.

ACESSAR A PÁGINA “SERVIÇOS” DO GOOGLE KUBERNETES ENGINE

A lista contém um único serviço denominado hello-cloudbuild, criado pela versão de entrega contínua concluída recentemente.
Clique no endpoint do serviço hello-cloudbuild. "Hello World!" será exibido. Se não houver um endpoint ou ocorrer um erro no balanceador de carga, talvez seja necessário aguardar alguns minutos até que o balanceador de carga seja totalmente inicializado. Clique em Atualizar para atualizar a página, se necessário.

No Cloud Shell, substitua “Hello World” por “Hello Cloud Build” no aplicativo e no teste de unidade.

cd ~/hello-cloudbuild-app
sed -i 's/Hello World/Hello Cloud Build/g' app.py
sed -i 's/Hello World/Hello Cloud Build/g' test_app.py

Confirme e envie a alteração para o Cloud Source Repositories.
```
git add app.py test_app.py
git commit -m "Hello Cloud Build"
git push google master
```
Isso aciona o pipeline de CI/CD inteiro.
Após alguns minutos, atualize o aplicativo no seu navegador. "Hello Cloud Build!" será exibido.

Como testar a reversão

Nesta seção, você voltará para a versão do aplicativo que dizia "Hello World!".

Abra o console do Cloud Build no repositório hello-cloudbuild-env.

Acessar o Cloud Build
Clique na segunda versão mais recente disponível.
Clique em Recriar.
Quando a versão estiver concluída, atualize o aplicativo no seu navegador. "Hello World!" aparecerá novamente.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

No Console do Google Cloud, acesse a página Gerenciar recursos.
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Como excluir os recursos

Se você quiser manter o projeto do Google Cloud usado neste tutorial, exclua os recursos individuais:

Exclua os repositórios Git locais.

cd ~
rm -rf ~/hello-cloudbuild-app
rm -rf ~/hello-cloudbuild-env

Exclua os repositórios Git no Cloud Source Repositories.

gcloud source repos delete hello-cloudbuild-app --quiet
gcloud source repos delete hello-cloudbuild-env --quiet

Exclua os acionadores do Cloud Build.
1. Abra a página Gatilhos do Cloud Build.
  
  Acessar acionadores
2. Para cada gatilho, clique em Mais e, depois, em Excluir.

Exclua o repositório do Docker no Artifact Registry.

gcloud artifacts repositories delete my-repository \
    --location=us-central1

Remova a permissão concedida ao Cloud Build para se conectar ao GKE.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
    --format='get(projectNumber)')"
gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

Exclua o cluster do GKE.

gcloud container clusters delete hello-cloudbuild \
   --region us-central1

A seguir

Confira os recursos mais avançados do Cloud Build em Como configurar a ordem das etapas de versão, Como criar, testar e implantar artefatos e Como criar etapas personalizadas de versão
Saiba como espelhar um repositório GitHub ou Bitbucket no Cloud Source Repositories.
Conecte o Cloud Build diretamente ao seu repositório GitHub.

Entrega contínua no estilo GitOps com o Cloud Build

Sobre este tutorial

Objetivos

Custos

Antes de começar

Piloto automático

Padrão

Como criar repositórios Git no Cloud Source Repositories

Como criar uma imagem de contêiner com o Cloud Build

Como criar o pipeline de integração contínua

Como criar o pipeline de entrega contínua

Como conceder acesso do GKE ao Cloud Build

Shell

Console

Como inicializar o repositório hello-cloudbuild-env

Como criar o gatilho do pipeline de entrega contínua

Como modificar o pipeline de integração contínua para acionar o pipeline de entrega contínua

Como testar o pipeline completo

Como testar a reversão

Limpeza

Como excluir os recursos

A seguir