Gerenciar manifestos no Cloud Deploy

Esta página descreve como configurar o Cloud Deploy para renderizar a configuração de cada destino em um pipeline de entrega.

O Cloud Deploy usa o Skaffold para renderizar os manifestos do Kubernetes. O serviço é compatível com a renderização de manifestos brutos e ferramentas de gerenciamento de manifesto mais avançadas, como Helm, Kustomize e kpt (links em inglês). de dados.

O processo de renderização tem dois estágios:

  1. A ferramenta de gerenciamento de manifestos gera o manifesto.

  2. O Skaffold substitui as referências de imagens no manifesto pelas imagens que você quer implantar na versão.

Nesta página, incluímos exemplos de configuração que usam o Helm e o Kustomize.

Como usar o Skaffold para gerar sua configuração

Se você ainda não tiver um arquivo de configuração (skaffold.yaml) do Skaffold, use o Skaffold para gerar um para você, com base no que está no seu repositório.

  1. Instale o Skaffold usando a Google Cloud CLI:

    gcloud components install skaffold

  2. Execute skaffold init no repositório que contém seus manifestos:

    skaffold init --skip-build

Esse comando cria um arquivo skaffold.yaml no seu repositório. Esse arquivo faz referência aos manifestos nesse repositório. O conteúdo é semelhante a este:

apiVersion: skaffold/v4beta7
kind: Config
metadata:
  name: sample-app
manifests:
  rawYaml:
    - k8s-manifests/deployment.yaml
    - k8s-manifests/rbac.yaml
    - k8s-manifests/redis.yaml
    - k8s-manifests/service.yaml

Renderizar manifestos brutos

Os manifestos brutos não são gerenciados por uma ferramenta, como o Helm ou o Kustomize, e, portanto, não precisam de pré-processamento antes de serem hidratados e implantados em um cluster.

Por padrão, o Cloud Deploy usa skaffold render para renderizar os manifestos do Kubernetes, substituindo nomes de imagens não marcadas pelos nomes das imagens de contêiner que você está implantando. Depois, quando você promover a versão, o Cloud Deploy usará skaffold apply para aplicar os manifestos e implantar as imagens no cluster do Google Kubernetes Engine.

Uma estrofe manifests de uma configuração básica é semelhante a esta:

manifests:
  rawYaml:
    - PATH_TO_MANIFEST

Consulte a documentação do Skaffold para mais informações sobre quais valores podem ser transmitidos aqui.

Renderização usando Helm

É possível usar o Cloud Deploy para renderizar os gráficos do Helm. Para isso, inclua detalhes do gráfico Helm em uma estrofe deploy em um perfil do Skyffold.

Cada definição tem esta aparência:

apiVersion: skaffold/v4beta7
kind: Config
manifests:
  helm:
    releases:
      - name: RELEASE_NAME
        chartPath: PATH_TO_HELM_CHART

Em que:

RELEASE_NAME é o nome da instância de gráfico do Helm para esta versão.

PATH_TO_HELM_CHART é o caminho local para um gráfico do Helm empacotado ou um diretório de gráfico do Helm descompactado.

É possível usar outras opções de configuração do Helm, conforme descrito na documentação do Skaffold

Renderização usando Kustomize

É possível usar o Kustomize com o Cloud Deploy. Para fazer isso, aponte para os arquivos do Kustomization de acordo com a estrofe deploy na configuração do perfil skaffold.yaml.

Inclua uma configuração separada do Kustomize para cada destino em que você está usando o Kustomize, em cada profile correspondente na sua skaffold.yaml.

Cada definição tem esta aparência:

apiVersion: skaffold/v4beta7
kind: Config
manifests:
  kustomize:
    paths:
      - PATH_TO_KUSTOMIZE

Em que:

PATH_TO_KUSTOMIZE aponta para os arquivos do Kustomization. O padrão é ["."].

É possível usar outras opções de configuração do Kustomize, conforme descrito na documentação do Skaffold

Como configurar diferentes manifestos por destino

Muitas vezes, cada destino precisa de uma configuração um pouco diferente. Por exemplo, talvez você tenha mais réplicas nas implantações de produção do que nas implantações de preparo.

É possível renderizar um conjunto diferente de manifestos para cada destino, fornecendo cada variação como um perfil do Skyffold diferente.

Perfis com manifestos brutos

Ao trabalhar com manifestos brutos, você pode apontar o Cloud Deploy em um arquivo diferente, dependendo do destino. Você pode configurar isso da seguinte maneira:

apiVersion: skaffold/v4beta7
kind: Config
profiles:
  - name: prod
    manifests:
      rawYaml:
        - prod.yaml
  - name: staging
    manifests:
      rawYaml:
        - staging.yaml

Perfis com Kustomize

Veja um exemplo de skaffold.yaml que tem perfis diferentes para preparo e produção usando o Kustomize, em que cada perfil aponta para uma Kustomize diferente:

apiVersion: skaffold/v4beta7
kind: Config
profiles:
  - name: prod
    manifests:
      kustomize:
        paths:
          - environments/prod
  - name: staging
    manifests:
      kustomize:
        paths:
          - environments/staging

Perfis referenciados no pipeline de entrega

Esses perfis, definidos em skaffold.yaml, são referenciados na configuração do pipeline de entrega por destino:

serialPipeline:
  stages:
  - targetId: staging-target
    profiles:
    - staging
  - targetId: prod-target
    profiles:
    - prod

Substituir uma imagem específica ao criar a versão

O manifesto pode usar um marcador de posição para o nome da imagem, que pode ser substituído ao criar a versão.

Confira um exemplo de um manifesto com um marcador de posição para a imagem:

apiVersion: v1
kind: Deployment
metadata:
  name: getting-started
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: my-app-image

Ao criar a versão, use a flag --images= para identificar a imagem específica a ser implantada. Por exemplo, o comando a seguir cria uma versão e substitui um nome de imagem qualificado por SHA pelo nome do marcador de posição:

gcloud deploy releases create test-release-001 \
  --project=test-gke-using-deployment \
  --region=us-central1 \
  --delivery-pipeline=my-gke-demo-app-1 \
  --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa

O manifesto renderizado resultante agora tem uma referência à imagem especificada em vez de my-app-image.

A seguir