Integrar o gateway do Connect ao Cloud Build
Este é um tutorial básico sobre como integrar o Cloud Build ao gateway do Connect, permitindo criar um pipeline de CI/CD para clusters do GKE em execução em muitos ambientes diferentes.
Neste tutorial, presumimos que você esteja familiarizado com as seções anteriores do guia do gateway do Connect e também com o Cloud Build. Essas instruções usam a imagem do builder cloud-sdk
, que requer um pouco de script (como você verá abaixo).
Antes de começar
Verifique se você tem as seguintes ferramentas de linha de comando instaladas:
- A versão mais recente da Google Cloud CLI, que inclui
gcloud
, a ferramenta de linha de comando para interagir com o Google Cloud. kubectl
Se você estiver usando o Cloud Shell como ambiente shell para interagir com o Google Cloud, essas ferramentas estarão instaladas.
- A versão mais recente da Google Cloud CLI, que inclui
Verifique se você inicializou a CLI gcloud para usar com seu projeto.
Verifique se o gateway do Connect e outras APIs necessárias estão ativadas para o projeto, conforme descrito no guia de configuração.
1. Conceder papéis do IAM à conta de serviço do Cloud Build
Por padrão, o Cloud Build usa uma conta de serviço do Google Cloud para executar todo o trabalho necessário, com um endereço no formato MY_PROJECT_NUMBER @cloudbuild.gserviceaccount.com
. Esse endereço de e-mail da conta de serviço do projeto é encontrado em Cloud Build > Configurações no Console do Google Cloud.
Siga as instruções em Conceder permissões do IAM no guia de configuração do gateway para conceder a essa conta os papéis necessários no projeto.
2. Especificar políticas de RBAC para a conta de serviço do Cloud Build
Siga as instruções em Como configurar políticas de RBAC no guia de configuração do gateway para conceder à conta de serviço do Cloud Build as permissões apropriadas em todos os clusters que você quer usar.
Recomendamos o uso do Controlador de Políticas para implantar e manter as políticas do RBAC em vários clusters.
3. Criar um pipeline do Cloud Build
O fluxo de trabalho do Cloud Build precisa de um arquivo cloudbuild.yaml
para configurar o pipeline. Confira a seguir um exemplo simples que implanta um manifesto estático em dois clusters diferentes (um cluster do GKE no Google Cloud e outro no VMware). Saiba mais sobre como configurar um pipeline do Cloud Build na documentação do Cloud Build.
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: bash
id: Deploy to cluster on Google Cloud
args:
- '-c'
- |
set -x && \
export KUBECONFIG="$(pwd)/gateway-kubeconfig" && \
gcloud container fleet memberships get-credentials my-gke-cluster && \
kubectl --kubeconfig gateway-kubeconfig apply -f myapp.yaml
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: bash
id: Deploy to cluster on VMware
args:
- '-c'
- |
set -x && \
export KUBECONFIG="$(pwd)/gateway-kubeconfig" && \
gcloud container fleet memberships get-credentials my-vmware-cluster && \
kubectl --kubeconfig gateway-kubeconfig apply -f myapp.yaml
É possível colocar qualquer fluxo de trabalho desejado em myapp.yaml
para configurar clusters. Exemplo:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Depois de enviar a configuração para o repositório Git, o fluxo de trabalho do Cloud Build implantará o aplicativo necessário nos clusters especificados. Também é possível configurar o Cloud Build para detectar alterações no repositório Git vinculado a fim de acionar a atualização ou instalação automática do aplicativo.
Uso avançado
Como usamos conceitos padrão do Cloud Build, é possível adaptar e personalizar ainda mais nosso exemplo para atender às suas necessidades específicas de CI/CD. Para criar uma imagem do zero e implantá-la no pipeline, use o modo de preparação do builder gke-deploy
. Por exemplo, a seguinte configuração do Cloud Build:
- Cria uma imagem do Docker com base no Dockerfile na raiz do repositório Git e a marca com o Git SHA.
- Envia a imagem marcada para o Container Registry do projeto.
- Prepara os manifestos do Kubernetes no diretório
manifest
definindo as tags de imagem corretas, colocando os manifestos de saída emoutput/expanded
. - Implanta em um cluster local do GKE usando o gateway do Connect.
steps:
- name: 'gcr.io/cloud-builders/docker'
id: "Build Container"
args: ['build', '--tag=gcr.io/$PROJECT_ID/demo-app:$SHORT_SHA', '.']
- name: 'gcr.io/cloud-builders/docker'
id: "Push to GCR"
args: ['push', 'gcr.io/$PROJECT_ID/demo-app:$SHORT_SHA']
- name: "gcr.io/cloud-builders/gke-deploy"
id: "Prepare Manifests"
args:
- prepare
- --filename=manifests/
- --image=gcr.io/$PROJECT_ID/demo-app:$SHORT_SHA
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: bash
id: "Deploy to cluster on VMware
args:
- '-c'
- |
set -x && \
export KUBECONFIG="$(pwd)/gateway-kubeconfig" && \
gcloud container fleet memberships get-credentials my-vmware-cluster && \
kubectl --kubeconfig=gateway-kubeconfig apply -f output/expanded
Neste exemplo, foi necessário criar um secret de pull de imagem para autorizar o cluster local do GKE a extrair imagens do Container Registry.
Para mais ideias de uso do Cloud Build, consulte a documentação do Cloud Build.