Integre o gateway do Connect com o Cloud Build

Este é um tutorial básico sobre como integrar o Cloud Build com o gateway Connect, que lhe permite criar um pipeline de CI/CD para clusters do GKE em execução em vários ambientes diferentes.

Este tutorial pressupõe que conhece as secções anteriores do guia da gateway Connect e que também conhece o Cloud Build. Estas instruções tiram partido da cloud-sdkimagem do criador, que requer alguns scripts menores (como verá abaixo).

Antes de começar

  • Certifique-se de que tem as seguintes ferramentas de linha de comandos instaladas:

    • A versão mais recente da CLI do Google Cloud, que inclui o gcloud, a ferramenta de linha de comando para interagir com Google Cloud.
    • kubectl, a ferramenta de linhas de comando para interagir com o Kubernetes.

    Se estiver a usar o Cloud Shell como ambiente de shell para interagir com o Google Cloud, estas ferramentas são instaladas automaticamente.

  • Certifique-se de que inicializou a CLI gcloud para utilização com o seu projeto.

  • Certifique-se de que o gateway Connect e outras APIs necessárias estão ativados para o seu projeto, conforme descrito no guia de configuração.

1. Conceda funções do IAM à conta de serviço do Cloud Build

Por predefinição, o Cloud Build usa uma Google Cloud conta de serviço para executar todo o trabalho necessário, com um endereço no formato MY_PROJECT_NUMBER @cloudbuild.gserviceaccount.com. Pode encontrar este endereço de email da conta de serviço do seu projeto em Cloud BuildDefinições na Google Cloud consola.

Captura de ecrã da página de definições do Cloud Build

Siga as instruções em Conceda autorizações de IAM no guia de configuração da gateway para conceder a esta conta as funções necessárias no seu projeto.

2. Especifique políticas de RBAC para a conta de serviço do Cloud Build

Siga as instruções em Configure políticas de RBAC no guia de configuração da gateway para conceder à conta de serviço do Cloud Build as autorizações adequadas em todos os clusters que quer usar.

Recomendamos vivamente a utilização do Policy Controller para implementar e manter políticas de RBAC em vários clusters.

3. Crie um pipeline do Cloud Build

O fluxo de trabalho do Cloud Build precisa de um ficheiro cloudbuild.yaml para configurar o pipeline. Segue-se um exemplo simples que implementa um manifesto estático em dois clusters diferentes (um cluster do GKE no Google Cloude um no VMware). Pode saber 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

Pode colocar qualquer fluxo de trabalho desejado em myapp.yaml para configurar clusters. Vejamos um 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 implementa a aplicação necessária nos clusters especificados. Também pode configurar o Cloud Build para detetar alterações no repositório Git associado para acionar a atualização ou a instalação automática da aplicação.

Utilização avançada

Uma vez que usa conceitos padrão do Cloud Build, pode adaptar e personalizar ainda mais o nosso exemplo para se adequar às suas necessidades específicas de CI/CD. Em particular, se quiser criar uma imagem de raiz e implementá-la no seu pipeline, pode usar o gke-deploy modo de preparação do criador . Por exemplo, a seguinte configuração do Cloud Build:

  1. Cria uma imagem do Docker a partir do Dockerfile na raiz do repositório Git e etiqueta-a com o SHA do Git.
  2. Envia a imagem etiquetada para o Container Registry do projeto.
  3. Prepara os manifestos do Kubernetes no diretório manifest definindo as etiquetas de imagem corretas e colocando os manifestos de saída em output/expanded.
  4. Implementa-se num cluster do GKE no local através do 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

Tenha em atenção que, neste exemplo, tivemos de criar um segredo de obtenção de imagens para autorizar o cluster do GKE no local a obter imagens do Container Registry.

Para mais ideias sobre a utilização do Cloud Build, consulte a documentação do Cloud Build.