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. Como 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. Conceder 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 ambiente de desenvolvimento integrado como raiz do repositório

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

cd delivery-platform && cloudshell workspace .

3. Como 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. Em etapas posteriores, esses repositórios de modelos serão copiados e modificados para uso como base de novos aplicativos. Neste laboratório, você vai iniciar o repositório de modelos com uma estrutura de exemplo fornecida aqui. Para adicionar seus próprios modelos, adicione outras pastas com base no exemplo.

Nesta etapa, você vai criar seu próprio repositório para armazenar modelos de apps usando os 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 etapas futuras 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 vai ajudar você 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

Os modelos de aplicativo de exemplo são fornecidos com este laboratório como um exemplo de como integrar seus próprios modelos básicos. Nesta etapa, você cria 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. Enviar o repositório de modelos para o 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 básicas compartilhadas

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

Nesta etapa, você vai criar o repositório de configuração compartilhado chamado mcd-shared_kustomize com base nos exemplos fornecidos.

1. Copiar 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. Enviar o repositório de modelos para o 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 do app.

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

A criação de um novo aplicativo a partir de um modelo geralmente exige que as variáveis de marcador de posição sejam trocadas por valores reais em vários arquivos na estrutura do modelo. Quando a substituição for concluída, um novo repositório será criado para a nova instância do app. É esse repositório de instância do app que os desenvolvedores clonarão e usarão 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.

Definir um nome para o novo aplicativo

export APP_NAME=my-app

Extrair o repositório de modelos Golang

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 é trocar as variáveis nos modelos por instâncias reais usadas no aplicativo. Por exemplo, informando 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. Criar um repositório remoto vazio na sua conta do GitHub

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

2. Enviar o repositório de modelos para o 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. Como configurar a execução de pipelines automatizados

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, são gerados eventos que podem ser configurados para acionar processos em outros sistemas.

Nesta etapa, você vai configurar o GitHub para chamar o Google Cloud Build e executar o pipeline sempre que os usuários confirmarem ou marcarem o código no repositório.

Ativar o acesso seguro

Serão necessários dois elementos para configurar o acesso seguro ao pipeline do aplicativo. 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 é bloquear o escopo da chave de API para apenas as APIs específicas que o cliente vai acessar. Você criou a chave em uma etapa anterior.

1. Para revisar a chave, clique neste link.
2. Execute o comando a seguir para garantir que o valor seja definido.

echo $API_KEY_VALUE

Secret do pipeline

Os segredos são usados para autorizar um autor da chamada e garantir que ele tenha direitos sobre o job de destino específico do Cloud Build. Você pode ter dois repositórios diferentes no GitHub que só deveriam ter acesso aos próprios pipelines. Enquanto o API_KEY limita quais APIs podem ser utilizadas pelo GitHub (neste caso, a API Cloud Build está sendo chamada), o segredo limita quais jobs na API Cloud Build podem ser executados 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. Permita 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 de chave sejam fornecidos na criação para configurar o acionador corretamente.

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 compartilhado.

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

6. Uma variável foi definida no script onboard-env.sh que define o registro de contêineres do projeto. Confira o valor com o comando abaixo.

echo $IMAGE_REPO

7. Crie o gatilho do 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. Para analisar o gatilho do Cloud Build recém-criado no console, acesse 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 revise 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 automatizá-lo em um script.

6. Como 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 roteiro para você usar.

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.

Analisar o repositório do GitHub

Agora você pode analisar o novo repositório no GitHub.

1. Extraia 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 os exemplos em que as variáveis do 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 web hook configurado no URL abaixo

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

Revisar o gatilho do CloudBuild

O acionador foi configurado automaticamente pelo script

1. Revise o gatilho do Cloud Build no console neste link
2. Consulte o histórico de builds nesta página.