1. Antes de começar
Configuração de ambiente personalizada
- 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.
- 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
- Abra o editor do Cloud Shell acessando o seguinte URL
https://ide.cloud.google.com
- 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)')
- Ativar APIs
gcloud services enable \
cloudbuild.googleapis.com \
secretmanager.googleapis.com
- 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}
- Na janela do terminal, clone a origem do aplicativo com o seguinte comando:
git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git
- 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.
- Copie o modelo para o diretório de trabalho
cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR
cd $WORK_DIR/app-templates
- Crie um repositório remoto vazio na sua conta do GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-app-templates
- 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
- 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.
- Copiar o modelo para o diretório de trabalho
cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR
cd $WORK_DIR/shared-kustomize
- Crie um repositório remoto vazio na sua conta do GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize
- 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
- 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
- Criar um repositório remoto vazio na sua conta do GitHub
$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}
- 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.
- Para revisar a chave, clique neste link.
- 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.
- 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))
- Criar o secret
printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-
- 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.
- 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
- Defina o local do repositório de configuração de base compartilhado.
export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize
- 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
- 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á localizado
gcloud 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}`
- Para analisar o gatilho do Cloud Build recém-criado no console, acesse este link.
- 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
- Configurar o webhook no GitHub
$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL
- 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
- Verifique se você está no diretório certo
cd $BASE_DIR
- 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.
- Extraia o URL do repositório do GitHub executando o seguinte comando:
echo ${GIT_BASE_URL}/demo-app
- Abra o URL com seu navegador da Web para analisar o novo aplicativo.
- 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
- 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
- Revise o gatilho do Cloud Build no console neste link
- Consulte o histórico de builds nesta página.