Integração do app

1. Antes de começar

Configuração de ambiente personalizada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. Ele é uma string de caracteres que não é usada pelas APIs do Google e pode ser atualizada a qualquer momento.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O Console do Cloud gera automaticamente uma string única, geralmente não importa o que seja. Na maioria dos codelabs, você precisará fazer referência ao ID do projeto, que geralmente é identificado como PROJECT_ID. Então, se você não gostar dele, gere outro ID aleatório ou crie um próprio e veja se ele está disponível. Em seguida, ele fica "congelado" depois que o projeto é criado.
• Há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto precisa ser globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Se um projeto for excluído, esse ID não poderá mais ser usado novamente.

Observação: se você estiver usando uma conta do Gmail, deixe o local padrão definido como Sem organização. Se você estiver usando uma conta do Google Workspace, escolha um local adequado à sua organização.

2. Em seguida, você precisará ativar o faturamento no Console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar cobranças além deste tutorial, siga as instruções de "limpeza" encontradas no final do codelab. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

2. Preparar seu espaço de trabalho

1. Abra o editor do Cloud Shell acessando o seguinte URL:

https://ide.cloud.google.com

2. Verifique se o nome do projeto está definido na CLI

gcloud config set project {{project-id}}

export PROJECT_ID=$(gcloud config get-value project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

3. Ativar APIs

gcloud services enable \

cloudbuild.googleapis.com \

secretmanager.googleapis.com

4. Fornecer direitos ao CloudDeploy

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.admin ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/container.developer ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/iam.serviceAccountUser ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.jobRunner ${PROJECT_ID}

5. Na janela do terminal, clone a origem do aplicativo com o seguinte comando:

git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git

6. Mude para o diretório e defina o espaço de trabalho do IDE como a raiz do repositório.

cd software-delivery-workshop && rm -rf .git

cd delivery-platform && cloudshell workspace .

3. Usar modelos de apps predefinidos e personalizados

Os desenvolvedores precisam poder escolher entre um conjunto de modelos usados com frequência na organização. O processo de integração vai criar um conjunto centralizado de repositórios de modelos armazenados na sua conta do GitHub. Nas etapas posteriores, esses repositórios de modelos serão copiados e modificados para uso como base de novos aplicativos. Neste laboratório, você vai inserir uma estrutura de amostra fornecida aqui no repositório de modelos. É possível adicionar seus próprios modelos adicionando outras pastas semelhantes à amostra.

Nesta etapa, você vai criar seu próprio repositório para armazenar modelos de apps com base nos arquivos de exemplo fornecidos. Um script auxiliar é fornecido para simplificar as interações com o GitHub.

Estas são etapas únicas usadas para preencher os repositórios de modelos. As próximas etapas vão reutilizar esses repositórios.

Configurar o acesso ao GitHub

As etapas deste tutorial chamam a API do GitHub para criar e configurar repositórios. Seu nome de usuário do GitHub e um token de acesso pessoal são necessários em vários pontos a seguir. O script abaixo ajuda a adquirir os valores e armazená-los como variáveis locais para uso posterior.

source ./onboard-env.sh

echo Git Username: $GIT_USERNAME

echo Git Base URL: $GIT_BASE_URL

Criar repositório de modelos de app

Modelos de aplicativos de exemplo são fornecidos com este laboratório como um exemplo de como você pode integrar seus próprios modelos de base. Nesta etapa, você vai criar sua própria cópia desses arquivos em um repositório chamado mcd-app-templates na sua conta do GitHub.

1. Copie o modelo para o diretório de trabalho

cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR

cd $WORK_DIR/app-templates

2. Crie um repositório remoto vazio na sua conta do GitHub

$BASE_DIR/scripts/git/gh.sh create mcd-app-templates

3. Envie o repositório de modelos para seu repositório remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/mcd-app-templates

git push origin main

4. Limpar o diretório de trabalho

cd $BASE_DIR

rm -rf $WORK_DIR/app-templates

Criar repositório de configurações de base compartilhadas

Este tutorial usa uma ferramenta chamada Kustomize, que usa arquivos de configuração de base compartilhados por várias equipes e sobrepõe configurações específicas do aplicativo. Isso permite que as equipes de plataforma escalonem em várias equipes e ambientes.

Nesta etapa, você cria o repositório de configuração compartilhada chamado mcd-shared_kustomize com base nas amostras fornecidas.

1. Copie o modelo para o diretório de trabalho

cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR

cd $WORK_DIR/shared-kustomize

2. Crie um repositório remoto vazio na sua conta do GitHub

$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize

3. Envie o repositório de modelos para seu repositório remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/mcd-shared_kustomize

git push origin main

4. Limpar o diretório de trabalho

cd $BASE_DIR

rm -rf $WORK_DIR/shared-kustomize

Com os repositórios de modelos criados, você pode usá-los para criar uma instância de app.

4. Como criar uma nova instância de um aplicativo

Criar um aplicativo com base em um modelo geralmente exige que variáveis de marcador de posição sejam substituídas por valores reais em vários arquivos na estrutura do modelo. Quando a substituição é concluída, um novo repositório é criado para a nova instância do app. É esse repositório de instâncias de app que os desenvolvedores vão clonar e usar no desenvolvimento diário.

Nesta etapa, você vai substituir valores em um modelo de app e postar os arquivos resultantes em um novo repositório.

Defina um nome para o novo aplicativo.

export APP_NAME=my-app

Recuperar o repositório de modelos do Go

cd $WORK_DIR/

git clone -b main $GIT_BASE_URL/mcd-app-templates app-templates

rm -rf app-templates/.git

cd app-templates/golang

Substituir valores de marcador

Uma das necessidades mais comuns de integração é a troca de variáveis em modelos por instâncias reais usadas no aplicativo. Por exemplo, fornecendo o nome do aplicativo. O comando a seguir cria instâncias de todos os arquivos .tmpl com os valores armazenados em variáveis de ambiente.

for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done

Crie um novo repositório e armazene os arquivos atualizados

1. Crie um repositório remoto vazio na sua conta do GitHub

$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}

2. Envie o repositório de modelos para seu repositório remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/${APP_NAME}

git push origin main

Agora que a instância do app foi criada, é hora de implementar builds contínuos.

5. Configurar a execução automatizada do pipeline

A parte central de um sistema de integração contínua é a capacidade de executar a lógica do pipeline com base nos eventos originados no sistema de controle de origem. Quando um desenvolvedor confirma o código no repositório, eventos são acionados e podem ser configurados para iniciar processos em outros sistemas.

Nesta etapa, você vai configurar o GitHub para chamar o Google Cloud Build e executar seu pipeline sempre que os usuários fizerem commit ou adicionarem tags ao código no repositório.

Ativar o acesso seguro

Você vai precisar de dois elementos para configurar o acesso seguro ao pipeline de aplicativos. Uma chave de API e um secret exclusivos para o pipeline.

Chave de API

A chave de API é usada para identificar o cliente que está chamando uma determinada API. Nesse caso, o cliente será o GitHub. Uma prática recomendada não abordada aqui é restringir o escopo da chave de API apenas às APIs específicas que o cliente vai acessar. Você criou a chave em uma etapa anterior.

1. Clique neste link para analisar a chave.
2. Para garantir que o valor esteja definido, execute o seguinte comando:

echo $API_KEY_VALUE

Secret do pipeline

Os secrets são usados para autorizar um caller e garantir que ele tenha direitos para o trabalho de destino específico do Cloud Build. Você pode ter dois repositórios diferentes no GitHub que só devem ter acesso aos próprios pipelines. Enquanto a API_KEY limita quais APIs podem ser usadas pelo GitHub (neste caso, a API Cloud Build está sendo chamada), o segredo limita qual trabalho na API Cloud Build pode ser executado pelo cliente.

1. Definir o nome, o local e o valor do secret

SECRET_NAME=${APP_NAME}-webhook-trigger-cd-secret

SECRET_PATH=projects/${PROJECT_NUMBER}/secrets/${SECRET_NAME}/versions/1

SECRET_VALUE=$(sed "s/[^a-zA-Z0-9]//g" <<< $(openssl rand -base64 15))

2. Criar o secret

printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-

3. Permitir que o Cloud Build leia o secret

gcloud secrets add-iam-policy-binding ${SECRET_NAME} \

--member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com \

--role='roles/secretmanager.secretAccessor'

Criar gatilho do Cloud Build

O gatilho do Cloud Build é a configuração que vai executar os processos de CICD.

O job exige que alguns valores principais sejam fornecidos na criação para configurar corretamente o gatilho.

4. Defina o nome do gatilho e onde o arquivo de configuração pode ser encontrado.

export TRIGGER_NAME=${APP_NAME}-clouddeploy-webhook-trigger

export BUILD_YAML_PATH=$WORK_DIR/app-templates/golang/build/cloudbuild-cd.yaml

5. Defina o local do repositório de configuração de base compartilhada.

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

6. Uma variável foi definida no script onboard-env.sh, definindo o registro de contêiner do projeto. Analise o valor com o comando abaixo.

echo $IMAGE_REPO

7. Crie um gatilho de webhook do Cloud Build usando as variáveis criadas anteriormente. O local do repositório do aplicativo é extraído do corpo da solicitação do GitHub. Um valor abaixo faz referência ao caminho no corpo da solicitação em que ele está localizadogcloud alpha builds triggers create webhook \

    `--name=${TRIGGER_NAME} \`
   
    `--substitutions='_APP_NAME='${APP_NAME}',_APP_REPO=$(body.repository.git_url),_CONFIG_REPO='${GIT_BASE_URL}'/'${CLUSTER_CONFIG_REPO}',_DEFAULT_IMAGE_REPO='${IMAGE_REPO}',_KUSTOMIZE_REPO='${GIT_BASE_URL}'/'${SHARED_KUSTOMIZE_REPO}',_REF=$(body.ref)' \`
   
    `--inline-config=$BUILD_YAML_PATH \`
   
    `--secret=${SECRET_PATH}`
   

8. Analise o gatilho de build do Cloud Build recém-criado no console acessando este link.
9. Defina uma variável para o URL do endpoint, que será usada pelo GitHub na próxima etapa.

WEBHOOK_URL="https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY_VALUE}&secret=${SECRET_VALUE}"

Configurar o webhook do GitHub

1. Configurar o webhook no GitHub

$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL

2. Acesse o repositório do aplicativo e analise o webhook recém-configurado.

REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks

echo $REPO_URL

Agora que você realizou manualmente todas as etapas necessárias para criar um novo aplicativo, é hora de automatizar isso em um script.

6. Automatizar todas as etapas de integração

Na prática, não é viável executar cada uma das etapas acima para cada novo aplicativo. Em vez disso, a lógica precisa ser incorporada a um script para facilitar a execução. As etapas acima já foram incluídas em um script para seu uso.

Nesta etapa, você vai usar o script fornecido para criar um novo aplicativo.

Crie um novo aplicativo

1. Verifique se você está no diretório certo

cd $BASE_DIR

2. Crie um novo aplicativo

export APP_NAME=demo-app

./app.sh create ${APP_NAME}

Todas as etapas são executadas automaticamente.

Revise o repositório do GitHub

Neste ponto, você poderá revisar o novo repositório no GitHub.

1. Recupere o URL do repositório do GitHub executando o seguinte comando:

echo ${GIT_BASE_URL}/demo-app

2. Abra o URL com seu navegador da Web para analisar o novo aplicativo.
3. Observe exemplos em que as variáveis de modelo foram substituídas por valores de instância, conforme mostrado no URL abaixo.

echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24

4. Revise o webhook configurado no URL abaixo

echo ${GIT_BASE_URL}/demo-app/settings/hooks

Analisar o gatilho do Cloud Build

O gatilho foi configurado automaticamente pelo script

1. Analise o gatilho de build do Cloud Build no console acessando este link.
2. Revise o histórico de builds nesta página.