Visão geral da configuração da build

Um arquivo desse tipo contém instruções para o Cloud Build executar tarefas de acordo com as especificações que você define. Por exemplo, seu arquivo de configuração de versão pode conter instruções para criar, empacotar e enviar imagens do Docker.

Nesta página, explicamos a estrutura do arquivo de configuração da versão do Cloud Build.

Estrutura de um arquivo de configuração da build

Os arquivos de configuração da versão são modelados por meio do recurso Build da API Cloud Build.

É possível gravar o arquivo de configuração da criação usando a sintaxe YAML ou JSON. Se você enviar solicitações de criação usando ferramentas http de terceiros, como curl, use a sintaxe JSON.

Um arquivo de configuração da build tem a seguinte estrutura:

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
- name: string
  ...
- name: string
  ...
timeout: string (Duration format)
logsBucket: string
options:
 env: [string, string, ...]
 secretEnv: string
 volumes: object(Volume)
 sourceProvenanceHash: enum(HashType)
 machineType: enum(MachineType)
 diskSizeGb: string (int64 format)
 substitutionOption: enum(SubstitutionOption)
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
substitutions: map (key: string, value: string)
tags: [string, string, ...]
secrets: object(Secret)
images:
- [string, string, ...]
artifacts: object (Artifacts)

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)"
    },
    {
        "name": "string"
        ...
    },
    {
        "name": "string"
        ...
    }
    ],
    "timeout": "string (Duration format)",
    "logsBucket": "string",
    "options": {
        "sourceProvenanceHash": "enum(HashType)",
        "machineType": "enum(MachineType)",
        "diskSizeGb": "string (int64 format)",
        "substitutionOption": "enum(SubstitutionOption)",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)"
        "env": [
            "string",
            "string",
            "..."
        ],
        "secretEnv": "string",
        "volumes": "object(Volume)",
    },
    "substitutions": "map (key: string, value: string)",
    "tags": [
        "string",
        "string",
        "..."
    ],
    "secrets": "object(Secret)",
    "images": [
        "string",
        "string",
        "..."
    ],
    "artifacts": "object(Artifacts)"
}

Cada uma das seções do arquivo de configuração da versão define uma parte da tarefa que você quer que o Cloud Build execute:

Etapas da criação

Uma etapa da criação especifica uma ação que deverá ser executada pelo Cloud Build. Para cada etapa da criação, o Cloud Build executa um contêiner de Docker como uma instância de docker run. As etapas da criação são análogas aos comandos em um script e oferecem a flexibilidade de execução de instruções arbitrárias na versão. Se você puder inserir uma ferramenta de criação em um contêiner, o Cloud Build poderá executá-la como parte da criação. Todas as etapas de uma criação em série são executadas pelo Cloud Build na mesma máquina. Caso haja etapas que possam ser executadas simultaneamente, use a opção waitFor.

Inclua uma ou mais etapas da criação no seu arquivo de configuração.

Use o campo steps, do arquivo de configuração da versão para especificar uma etapa da criação. Veja um snippet do tipo de configuração que é possível definir no campo steps:

YAML

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/mydepl', 'my-image=gcr.io/my-project/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image"
            "deployment/mydepl"
            "my-image=gcr.io/my-project/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
            "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

nome

Use o campo name de uma etapa da criação para especificar um criador de nuvem, que é uma imagem de contêiner em que estão sendo executadas ferramentas comuns. Use um criador em uma etapa da criação para executar suas tarefas.

O snippet a seguir mostra etapas da criação usadas para chamar os criadores bazel, gcloud e docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/bazel'
...

- name: 'gcr.io/cloud-builders/gcloud'
...

- name: 'gcr.io/cloud-builders/docker'
...

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/bazel"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/gcloud"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/docker"
        ...
    }
    ]
}

args

O campo argsde uma etapa da criação recebe uma lista de argumentos e os transmite ao criador referido no campo name. Argumentos transmitidos para o criador são passados para a ferramenta que está sendo executada no criador, o que permite invocar qualquer comando compatível com a ferramenta. Se o criador usado na etapa da criação tiver um entrypoint, args será usado como argumentos para esse entrypoint. Se o criador não definir um entrypoint, o primeiro elemento em args será usado como entrypoint e os demais serão usados como argumento.

O snippet a seguir invoca o comando docker build e instala as dependências do Maven:

YAML

steps:
- name: 'gcr.io/cloud-builders/mvn'
  args: ['install']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/mvn",
        "args": [
            "install"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

env

O campo env de uma etapa da criação recebe uma lista de variáveis de ambiente a serem usadas na execução da etapa. As variáveis estão no formato KEY=VALUE.

Na configuração da criação a seguir, o campo env, da etapa da criação define a zona do Compute Engine e o cluster do GKE antes de executar o kubectl:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/myimage', 'frontend=gcr.io/myproject/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east1-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image",
            "deployment/myimage",
            "frontend=gcr.io/myproject/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east1-b",
            "CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster"
        ]
    }
    ]
}

dir

Use o campo dir em uma etapa da criação para definir um diretório de trabalho a ser usado na execução da etapa. Por padrão, o Cloud Build usa um diretório chamado /workspace como diretório de trabalho. Se o arquivo de configuração tiver mais de uma etapa de criação, os recursos produzidos por uma etapa poderão ser passados para a próxima pela permanência do diretório /workspace, o que permite configurar um pipeline de etapas de criação que compartilhem recursos. Se você definir o campo dir na etapa de criação, o diretório de trabalho será definido como /workspace/<dir>. Se esse valor for um caminho relativo, ele é relativo ao diretório de trabalho da criação. Se esse valor for absoluto, talvez ele esteja fora do diretório de trabalho da criação. Nesse caso, o conteúdo do caminho pode não ser permanente durante as execuções de etapas de criação, a não ser que seja especificado um volume para esse caminho.

O diretório de trabalho é definido pelo snippet a seguir como examples/hello_world:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
  env: ['PROJECT_ROOT=hello']
  dir: 'examples/hello_world'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ],
        "env": [
            "PROJECT_ROOT=hello"
        ],
        "dir": "examples/hello_world"
    }
    ]
}

timeout

Para definir um limite de tempo para execução da etapa de criação, use o campo timeout em uma etapa. Se esse campo não for definido, a etapa não terá limite de tempo, permanecendo em execução até se concluir ou até que a própria criação expire. O campo timeout em uma etapa de build não pode exceder o valor de timeout especificado para uma build. É preciso que timeout seja especificado em segundos, com até nove dígitos fracionários, encerrados por "s". Exemplo: "3.5s"

Na seguinte configuração de build, a etapa ubuntu expira após 500 segundos:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
  timeout: 500s
- name: 'ubuntu'
  args: ['echo', 'hello world, after 600s']

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ],
        "timeout": "500s"
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello world, after 600s"
        ]
    }
    ]
}

id

Use o campo id para definir um identificador exclusivo para uma etapa de criação. id é usado com o campo waitFor para configurar a ordem em que as etapas de criação devem ser executadas. Para receber instruções sobre como usar waitFor e id, consulte Como configurar a ordem das etapas de criação.

waitFor

Use o campo waitFor em uma etapa de criação para especificar as etapas que precisam ser executadas antes que a etapa de criação seja executada. Se nenhum valor for informado para waitFor, a etapa de criação aguardará até que todas as etapas de criação anteriores, que façam parte da solicitação da criação, sejam concluídas com êxito, antes de proceder à execução. Para receber instruções sobre como usar waitFor e id, consulte Como configurar a ordem das etapas de criação.

entrypoint

Se você não quiser usar o entrypoint padrão do criador em uma etapa de criação, use entrypoint para especificar um. Se você não definir esse campo, o Cloud Build usará o entrypoint do criador. O snippet a seguir define os entrypoints da etapa de criação npm:

YAML

steps:
- name: 'gcr.io/cloud-builders/npm'
  entrypoint: 'node'
  args: ['--version']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/npm",
        "entrypoint": "node",
        "args": [
            "--version"
        ]
    }
    ]
}

secretEnv

Uma lista de variáveis de ambiente, criptografadas com uma chave de criptografia do Cloud KMS. Esses valores precisam ser especificados nos segredos da criação. Para informações sobre como usar esse campo, consulte Como usar a variável criptografada em solicitações de criação.

volumes

Um Volume é um volume de contêiner do Docker que é montado nas etapas de criação para permitir a permanência de arquivos nas etapas de criação. Quando o Cloud Build executa uma etapa de criação, ele monta automaticamente um volume workspace em /workspace. Especifique mais volumes a serem montados nos contêineres das etapas de criação usando o campo volumes para suas etapas

Por exemplo, o arquivo de configuração da criação a seguir grava um arquivo em um volume na primeira etapa e faz a respectiva leitura na segunda etapa. Se o caminho /persistent_volume não for especificado por essas etapas como um volume permanente, a primeira etapa gravará o arquivo nesse caminho e depois esse arquivo será descartado antes da execução da segunda etapa Ao especificar o volume com o mesmo nome nas duas etapas, o conteúdo de /persistent_volume na primeira etapa é mantido na segunda etapa.

YAML

steps:
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
        echo "Hello, world!" > /persistent_volume/file
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  args: ['cat', '/persistent_volume/file']

JSON

  {
    "steps": [
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "entrypoint": "bash",
        "args": [
          "-c",
          "echo \"Hello, world!\" > /persistent_volume/file\n"
        ]
      },
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "args": [
          "cat",
          "/persistent_volume/file"
        ]
     }
    ]
  }

timeout

Use o campo timeout de uma criação para especificar o tempo de duração da permissão para que a criação seja executada, até a segunda granularidade. Se esse tempo terminar, o trabalho na criação será encerrado e o status da criação será TIMEOUT. Se timeout não for definido, um timeout padrão de 10 minutos será aplicado para a criação. O valor máximo que pode ser aplicado ao timeout é de 24 horas. É preciso que timeout seja especificado em segundos, com até nove dígitos fracionários, encerrados por "s". Exemplo: "3.5s"

No snippet a seguir, timeout está definido como 660 segundos, para evitar que a criação exceda o tempo limite devido ao modo de suspensão:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
timeout: 660s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ]
    }
    ],
    "timeout": "660s"
}

logsBucket

Defina o campo logsBucket de uma criação para especificar um bucket do Cloud Storage em que os registros precisam ser gravados. Se você não definir esse campo, o Cloud Build usará um bucket padrão para armazenar os registros de criação.

O snippet a seguir define um bucket de registros para armazenar os registros de versão:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
logsBucket: 'gs://mybucket'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "logsBucket": "gs://mybucket"
}

options

Use o campo options para especificar os seguintes argumentos opcionais do seu build:

env : uma lista de definições de variáveis de ambiente global para todas as etapas de criação nessa criação. Se uma variável for definida tanto globalmente quanto em uma etapa de criação, a variável usará o valor da etapa de criação. Os elementos estão no formato KEY=VALUE para a variável de ambiente KEY receber o valor VALUE.

secretEnv : uma lista de variáveis de ambiente global, criptografada usando uma chave de criptografia do Cloud Key Management Service, que estará disponível para todas as etapas de criação. É preciso que esses valores sejam especificados no Secret da build.

volumes : uma lista de volumes a serem montados globalmente para TODAS as etapas de criação. Cada volume é criado como um volume vazio, antes do início do processo de criação. Após a conclusão da versão, os volumes e seus conteúdos são descartados. Os caminhos e nomes de volume globais não podem entrar em conflito com os volumes definidos em uma etapa de criação. O uso de um volume global em uma criação com apenas uma etapa não é válido porque isso significa uma solicitação de criação com uma configuração incorreta.

sourceProvenanceHash : defina a opção sourceProvenanceHash para especificar o algoritmo de hash para a origem. O snippet a seguir especifica que o algoritmo hash é SHA256:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    sourceProvenanceHash: ['SHA256']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "sourceProvenanceHash": ["SHA256"]
    }
}

machineType: o Cloud Build fornece dois tipos de máquina virtual com grande quantidade de CPUs, para a execução das suas versões: 8 CPUs e 32 CPUs. O tipo de máquina padrão é de 1 CPU. Solicitar uma máquina virtual com grande quantidade de CPUs pode aumentar o tempo de inicialização da sua criação. Adicione a opção machineType para solicitar uma máquina virtual com uma quantidade maior de CPUs:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 machineType: 'N1_HIGHCPU_8'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    ],
    "options": {
        "machineType": "N1_HIGHCPU_8"
    }
}

Para receber mais informações sobre como usar a opção machineType, consulte Como acelerar as criações .

diskSizeGb : use a opção diskSizeGb para solicitar um tamanho de disco personalizado para sua criação. O tamanho máximo que pode ser solicitado é de 1.000 GB.

O snippet a seguir solicita um tamanho de disco de 200 GB:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 diskSizeGb: 200

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "diskSizeGb": 200
    }
}

logStreamingOption: use essa opção para especificar que seja feito stream de registros de criação para o Cloud Storage. Por padrão, o Cloud Build coleta registros de criação na conclusão da criação. Essa opção especifica se você quer transmitir registros de criação em tempo real por meio do processo de criação. O snippet a seguir especifica que os registros de versão são transmitidos para o Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
options:
 logStreamingOption: STREAM_ON

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "options": {
        "logStreamingOption": "STREAM_ON"
    }
}

logging: use essa opção para especificar se você quer armazenar registros no Cloud Logging ou no Cloud Storage. Se você não definir essa opção, o Cloud Build armazenará os registros no Cloud Logging e no Cloud Storage. É possível definir a opção logging para GCS_ONLY para armazenar os registros apenas no Cloud Storage. O seguinte snippet especifica que os registros são armazenados no Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 logging: GCS_ONLY

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "logging": "GCS_ONLY"
    }
}

substitutionOption : você definirá essa opção com o campo substitutions abaixo para especificar o comportamento quando houver um erro nas verificações de substituição.

substitutions

Use substituições em seu arquivo de configuração da criação para substituir variáveis específicas no momento da criação. As substituições são úteis para variáveis que tenham um valor não conhecido até o momento da criação ou para reutilizar uma solicitação de versão existente com diferentes valores variáveis. Por padrão, a criação retornará um erro se faltar uma variável de substituição ou uma substituição. No entanto, é possível usar a opção ALLOW_LOOSE para ignorar essa verificação.

O snippet a seguir usa substituições para imprimir "hello world". A opção de substituição ALLOW_LOOSE está definida, isto é, a criação não retornará um erro se faltar uma variável de substituição ou uma substituição.

YAML

steps:
- name: 'ubuntu'
  args: ['echo', 'hello ${_SUB_VALUE}']
substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello ${_SUB_VALUE}"
        ]
    }
    ],
    "substitutions": {
        "_SUB_VALUE": "world"
},
    "options": {
        "substitution_option": "ALLOW_LOOSE"
    }
}

Para receber mais instruções sobre o uso de substitutions, consulte Como substituir valores de variável.

tags

Use o campo tags para organizar suas criações em grupos e filtrar suas criações. A configuração a seguir define duas tags chamadas mytag1 e mytag2:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  ...
- name: 'ubuntu'
  ...
tags: ['mytag1', 'mytag2']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker"
    },
    {
        "name": "ubuntu"
    }
    ],
    "tags": [
        "mytag1",
        "mytag2"
    ]
}

secrets

Um secret combina um conjunto de variáveis de ambiente secretas contendo valores criptografados com a chave do Cloud KMS a ser usada para descriptografar o valor. Use o campo secrets na definição de secrets para descriptografar usando o Cloud KMS. Para ver um exemplo de como usar esse campo, consulte Como usar chaves secrets e credenciais criptografados.

images

No arquivo de configuração da criação, o campo images especifica uma ou mais imagens do Docker a serem enviadas pelo Cloud Build para o Container Registry. É possível ter uma criação que executa tarefas sem produzir nenhuma imagem do Docker, mas se você criar imagens e não as enviar para o Container Registry, elas serão descartadas na conclusão da criação. Se uma imagem especificada não for produzida durante a criação, a criação apresentará falha. Para saber mais informações sobre como armazenar imagens, consulte Como armazenar imagens e artefatos.

A seguinte configuração da build define o campo images para armazenar a imagem criada:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
images: ['gcr.io/myproject/myimage']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "images": [
        "gcr.io/myproject/myimage"
    ]
}

artifacts

No arquivo de configuração da criação, o campo artifacts especifica um ou mais artefatos que não são contêineres a serem armazenados no Cloud Storage. Para saber mais informações sobre como armazenar artefatos que não sejam contêineres, consulte Como armazenar imagens e artefatos.

A configuração a seguir define o campo artifacts para armazenar o pacote Go criado para gs://mybucket/:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['build', 'my-package']
artifacts:
  objects:
    location: 'gs://mybucket/'
    paths: ['my-package']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "build",
            "my-package"
        ]
    }
    ],
    "artifacts": {
      "objects": {
        "location": "gs://mybucket/",
        "paths": [
            "my-package"
        ]
      }
    }
}

Como usar Dockerfiles

Se você estiver executando versões do Docker no Cloud Build usando a ferramenta gcloud ou gatilhos de compilação, será possível usar apenas um Dockerfile para criar a imagem. Você não precisa de um arquivo de configuração de build à parte. Se quiser fazer mais ajustes nas suas versões do Docker, forneça um arquivo de configuração de build, além do Dockerfile. Para ver instruções sobre como criar uma imagem do Docker usando um Dockerfile, veja Guia de início rápido do Docker .

Rede do Cloud Build

Quando o Cloud Build executa cada etapa de build, ele anexa o contêiner da etapa a uma rede local do Docker denominada cloudbuild. A rede cloudbuild hospeda Application Default Credentials (ADC) que os serviços do Google Cloud podem usar para encontrar suas credenciais automaticamente. Se você estiver executando contêineres do Docker aninhados e quiser expor o ADC a um contêiner um nível abaixo, use a sinalização --network na etapa build do Docker:

YAML

steps:
- name: gcr.io/cloud-builders/docker
  args: ["build","--network=cloudbuild", "."]

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "--network=cloudbuild",
        "."
      ]
   }
  ]
}

A seguir