빌드 구성 개요

빌드 구성 파일에는 Cloud Build가 사양에 따라 태스크를 수행하는 방법에 대한 안내가 포함되어 있습니다. 예를 들어 빌드 구성 파일에 Docker 이미지를 빌드하고, 패키징하고, 내보내는 안내가 포함될 수 있습니다.

이 페이지에서는 Cloud Build 구성 파일의 구조를 설명합니다.

빌드 구성 파일의 구조

빌드 구성 파일은 Cloud Build API의 Build 리소스를 사용하여 모델링됩니다.

빌드 구성 파일은 YAML 또는 JSON 구문을 사용하여 작성할 수 있습니다. curl과 같은 타사 http 도구를 사용하여 빌드 요청을 제출하는 경우 JSON 구문을 사용하세요.

빌드 구성 파일의 구조는 다음과 같습니다.

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)
queueTtl: 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, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object (Artifacts)
images:
- [string, string, ...]

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)",
    "queueTtl": "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",
        "..."
    ],
    "serviceAccount": "string",
    "secrets": "object(Secret)",
    "availableSecrets": "object(Secrets)",
    "artifacts": "object(Artifacts)",
    "images": [
        "string",
        "string",
        "..."
    ]
}

빌드 구성 파일의 각 섹션은 Cloud Build에서 실행할 작업의 일부를 정의합니다.

빌드 단계

빌드 단계는 Cloud Build가 수행해야 하는 작업을 가리킵니다. 각 빌드 단계에서 Cloud Build는 docker run의 인스턴스로 Docker 컨테이너를 실행합니다. 빌드 단계는 스크립트의 명령어와 유사하며, 빌드에서 임의의 명령을 실행할 수 있는 유연성을 제공합니다. 빌드 도구를 컨테이너에 패키징할 수 있으면 Cloud Build가 빌드의 일부로 이를 실행할 수 있습니다. 기본적으로 Cloud Build는 동일한 머신에서 빌드의 모든 단계를 순차적으로 실행합니다. 동시에 실행할 수 있는 단계가 있는 경우 waitFor 옵션을 사용하세요.

구성 파일에 하나 이상의 빌드 단계를 포함할 수 있습니다.

빌드 구성 파일의 steps 필드를 사용하여 빌드 단계를 지정합니다. 다음은 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",
            "."
        ]
    }
    ]
}

이름

일반적인 도구를 실행하는 컨테이너 이미지인 클라우드 빌더를 지정하려면 빌드 단계의 name 필드를 사용합니다. 빌드 단계에서 빌더를 사용하여 작업을 실행합니다.

다음 스니펫은 bazel, gcloud, 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

빌드 단계의 args 필드는 인수 목록을 가져오고 name 필드로 참조되는 빌더에 전달합니다. 빌더에 전달된 인수는 빌더에서 실행 중인 도구에 전달되고, 이 도구에서 지원하는 모든 명령어를 호출하는 데 사용할 수 있습니다. 빌드 단계에서 사용된 빌더에 진입점이 있으면 args가 해당 진입점에 대한 인수로 사용됩니다. 빌더가 진입점을 정의하지 않으면 args의 첫 번째 요소가 진입점으로 사용되며 나머지는 인수로 사용됩니다.

다음 스니펫은 docker build 명령어를 호출하고 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

빌드 단계의 env 필드는 단계를 실행할 때 사용할 환경 변수 목록을 가져옵니다. 변수의 형식은 KEY=VALUE입니다.

다음 빌드 구성에서 빌드 단계의 env 필드는 kubectl을 실행하기 전에 Compute Engine 영역과 GKE 클러스터를 설정합니다.

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

단계를 실행할 때 사용할 작업 디렉터리를 설정하려면 빌드 단계의 dir 필드를 사용합니다. 기본적으로 Cloud Build는 /workspace라는 디렉터리를 작업 디렉터리로 사용합니다. 구성 파일에 둘 이상의 빌드 단계가 있으면 /workspace 디렉터리의 지속성을 통해 한 단계에서 생성한 애셋이 다음 단계로 전달될 수 있으며, 애셋을 공유하는 빌드 단계의 파이프라인을 설정할 수 있습니다. 빌드 단계에 dir 필드를 설정하면 작업 디렉터리가 /workspace/<dir>로 설정됩니다. 이 값이 상대 경로이면 빌드의 작업 디렉터리와 상대적 관계를 갖습니다. 이 값이 절대 경로이면 빌드 작업 디렉터리 외부에 있을 수 있습니다. 이 경우 경로의 내용이 빌드 단계가 실행되는 동안 지속되지 않을 수 있습니다(해당 경로의 볼륨이 지정되지 않은 경우).

다음 스니펫은 작업 디렉터리를 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

단계 실행에 대한 시간 제한을 설정하려면 빌드 단계의 timeout 필드를 사용합니다. 이 필드를 설정하지 않으면 단계에 시간 제한이 적용되지 않으며 단계가 완료되거나 빌드 자체가 제한 시간을 초과할 때까지 실행이 허용됩니다. 빌드 단계의 timeout 필드는 빌드에 지정된 timeout 값을 초과하면 안 됩니다. timeout은 최대 9자리 소수의 초 단위로 지정되고 's'로 끝나야 합니다. 예: '3.5s'

다음 빌드 구성에서는 500초 후에 ubuntu 단계의 제한 시간이 초과됩니다.

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

빌드 단계의 고유 식별자를 설정하려면 id 필드를 사용합니다. idwaitFor 필드와 함께 사용되어 빌드 단계 실행 순서를 구성합니다. waitForid를 사용하는 방법은 빌드 단계 순서 구성을 참조하세요.

waitFor

빌드 단계의 waitFor 필드를 사용하여 이 단계보다 먼저 실행해야 하는 단계를 지정합니다. waitFor에 지정된 값이 없으면 빌드 단계는 빌드 요청의 모든 이전 빌드 단계가 완료될 때까지 기다린 후에 실행됩니다. waitForid를 사용하는 방법은 빌드 단계 순서 구성을 참조하세요.

entrypoint

빌더의 기본 진입점을 사용하지 않으려면 빌드 단계의 entrypoint를 사용하여 진입점을 지정합니다. 이 필드를 설정하지 않으면 Cloud Build가 빌더의 진입점을 사용합니다. 다음 스니펫은 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

Cloud KMS 암호화 키를 사용하여 암호화된 환경 변수 목록. 이러한 값은 빌드의 비밀번호에 지정되어야 합니다. 이 필드를 사용하는 방법에 대한 자세한 내용은 빌드 요청에 암호화된 변수 사용을 참조하세요.

volumes

볼륨은 빌드 단계에서 파일을 유지하고자 빌드 단계에 마운트되는 Docker 컨테이너 볼륨입니다. Cloud Build가 빌드 단계를 실행하면 workspace 볼륨을 /workspace에 자동으로 마운트합니다. 단계에 volumes 필드를 사용하여 빌드 단계의 컨테이너에 마운트할 추가 볼륨을 지정할 수 있습니다.

예를 들어 다음 빌드 구성 파일은 첫 번째 단계의 볼륨에 파일을 쓰고 두 번째 단계에서 읽습니다. 이 단계에서 /persistent_volume 경로를 영구 볼륨으로 지정하지 않으면 첫 번째 단계에서 해당 경로에 파일을 쓰고 두 번째 단계가 실행되기 전에 해당 파일이 삭제됩니다. 두 단계에 동일한 이름의 볼륨을 지정하면 첫 번째 단계에서 /persistent_volume의 내용이 두 번째 단계에서도 유지됩니다.

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

빌드를 실행할 수 있는 시간을 초 단위로 지정하려면 빌드에 timeout 필드를 사용합니다. 이 시간이 지나면 빌드에 대한 작업이 중단되고 빌드 상태TIMEOUT이 됩니다. timeout이 설정되지 않으면 기본 timeout 10분이 빌드에 적용됩니다. timeout에 적용할 수 있는 최댓값은 24시간입니다. timeout은 최대 9자리 소수의 초 단위로 지정되고 's'로 끝나야 합니다. 예: '3.5s'

다음 스니펫에서 timeout은 빌드가 절전 시간 때문에 제한 시간을 초과하지 않도록 660초로 설정됩니다.

YAML

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

JSON

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

queueTtl

queueTtl 필드를 사용하여 빌드를 큐에 넣을 수 있는 시간을 지정합니다. 빌드가 queueTtl에 설정된 값보다 오래 동안 큐에 있으면 빌드가 만료되고 빌드 상태EXPIRED로 설정됩니다. queueTtlcreateTime에서 틱을 시작합니다. queueTtl은 최대 9자리 소수의 초 단위로 지정되고 's'로 끝나야 합니다(예: '3.5s').

다음 스니펫에서 timeout은 '20s'로 설정되고 queueTtl은 '10s'로 설정됩니다. queueTtl이 빌드가 요청된 시간인 createTime에 틱을 시작하고, timeout은 빌드가 시작되는 시간인 startTime에 틱을 시작합니다. 따라서 그 때까지 빌드가 시작되지 않으면 queueTtlcreateTime + 10s에 만료됩니다.

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '5']
timeout: 20s
queueTtl: 10s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "5"
        ]
    }
    ],
    "timeout": "20s",
    "queueTtl": "10s"
}

logsBucket

로그를 작성해야 하는 Cloud Storage 버킷을 지정하려면 빌드에 logsBucket 필드를 설정합니다. 이 필드를 설정하지 않으면 Cloud Build가 기본 버킷을 사용하여 빌드 로그를 저장합니다.

다음 스니펫은 빌드 로그를 저장할 로그 버킷을 설정합니다.

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 필드를 사용합니다.

env: 이 빌드의 모든 빌드 단계에 존재하는 전역 환경 변수 정의의 목록입니다. 변수가 전역적으로도 빌드 단계에도 모두 정의되어 있으면 변수는 빌드 단계 값을 사용합니다. 요소는 값 VALUE가 지정된 환경 변수 KEY의 경우 KEY=VALUE 형식입니다.

secretEnv: Cloud Key Management Service 암호화 키를 사용하여 암호화된 전역 환경 변수 목록으로, 이 빌드의 모든 빌드 단계에서 사용할 수 있습니다. 이러한 값은 빌드의 Secret에 지정되어야 합니다.

volumes: 모든 빌드 단계에 전역적으로 마운트할 볼륨 목록입니다. 각 볼륨은 빌드 프로세스를 시작하기 전에 빈 볼륨으로 생성됩니다. 빌드가 완료되면 볼륨과 그 내용이 삭제됩니다. 전역 볼륨 이름과 경로는 빌드 단계가 정의된 볼륨과 중복되어서는 안 됩니다. 단계가 하나뿐인 빌드에서 전역 볼륨을 사용하는 것은 구성이 잘못된 빌드 요청을 나타내므로 유효하지 않습니다.

sourceProvenanceHash: 소스 출처에 해시 알고리즘을 지정하려면 sourceProvenanceHash 옵션을 설정합니다. 다음 스니펫은 해시 알고리즘이 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: Cloud Build는 빌드를 실행하기 위해 4가지의 고성능 CPU 가상 머신 유형, 즉 8 CPU 머신 유형 2가지와 32 CPU 머신 유형 2가지를 제공합니다. 기본 머신 유형은 1CPU입니다. 고성능 CPU 가상 머신을 요청하면 빌드 시작 시간이 길어질 수 있습니다. 고성능 CPU 가상 머신을 요청하려면 machineType 옵션을 추가하세요.

YAML

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

JSON

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

machineType 옵션 사용에 대한 자세한 내용은 빌드 속도 향상을 참조하세요.

diskSizeGb: 빌드의 커스텀 디스크 크기를 요청하려면 diskSizeGb 옵션을 사용합니다. 요청 가능한 최대 크기는 1,000GB입니다.

다음 스니펫은 200GB의 디스크 크기를 요청합니다.

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: Cloud Storage로 빌드 로그를 스트리밍할지를 지정하려면 이 옵션을 사용합니다. 기본적으로 Cloud Build는 빌드 완료 시 빌드 로그를 수집합니다. 이 옵션은 빌드 프로세스를 통해 실시간으로 빌드 로그를 스트리밍할지 여부를 지정합니다. 다음 스니펫은 빌드 로그가 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: Cloud Logging 또는 Cloud Storage 중 로그를 저장할 위치를 지정하려면 이 옵션을 사용합니다. 이 옵션을 설정하지 않으면 Cloud Build는 Cloud Logging과 Cloud Storage 모두에 로그를 저장합니다. logging 옵션을 GCS_ONLY로 설정하여 Cloud Storage에만 로그를 저장할 수 있습니다. 다음 스니펫은 로그가 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: 아래의 substitutions 필드와 이 옵션을 함께 설정하여 대체 검사 오류 발생 시 동작을 지정할 수 있습니다.

substitutions

빌드 시 특정 변수를 대체하려면 빌드 구성 파일에 substitutions를 사용합니다. substitutions는 빌드할 때까지 값을 알 수 없는 변수에 또는 다른 변수 값을 사용하여 기존 빌드 요청을 다시 사용하는 데 유용합니다. 기본적으로 누락된 대체 변수나 누락된 대체 항목이 있으면 빌드가 오류를 반환합니다. 그러나 ALLOW_LOOSE 옵션을 사용하여 이 검사를 건너뛸 수 있습니다.

다음 스니펫은 substitutions를 사용하여 'hello world'를 인쇄합니다. ALLOW_LOOSE 대체 옵션이 설정됩니다. 이는 누락된 대체 변수 또는 누락된 대체 항목이 있으면 빌드가 오류를 반환하지 않음을 의미합니다.

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"
    }
}

substitutions 사용에 대한 추가 지침은 변수 값 치환을 참조하세요.

tags

빌드를 그룹별로 정리하고 빌드를 필터링하려면 tags 필드를 사용합니다. 다음 구성은 mytag1mytag2라는 두 개의 태그를 설정합니다.

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"
    ]
}

availableSecrets

Cloud Build에서 보안 비밀 관리자의 보안 비밀을 사용하려면 이 필드를 사용하세요. 자세한 내용은 보안 비밀 사용을 참조하세요.

secrets

secret은 암호화된 값이 포함된 비밀 환경 변수 세트와 값을 해독하는 데 사용할 Cloud KMS 키를 페어링합니다.

serviceAccount

이 필드를 사용하여 빌드 시 사용할 IAM 서비스 계정을 지정합니다. 자세한 내용은 사용자 지정 서비스 계정 구성을 참조하세요.

이미지

빌드 구성 파일의 images 필드는 Cloud Build가 Container Registry로 푸시할 하나 이상의 Docker 이미지를 지정합니다. Docker 이미지를 생성하지 않고 작업을 수행하는 빌드가 있을 수 있지만 이미지를 빌드하고 Container Registry로 푸시하지 않으면 빌드가 완료될 때 이미지가 삭제됩니다. 빌드 중에 지정된 이미지가 생성되지 않으면 빌드가 실패합니다. 이미지를 저장하는 방법에 대한 자세한 내용은 이미지 및 아티팩트 저장을 참조하세요.

다음 빌드 구성은 빌드된 이미지를 저장하도록 images 필드를 설정합니다.

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

빌드 구성 파일의 artifacts 필드는 Cloud Storage에 저장될 하나 이상의 컨테이너가 아닌 아티팩트를 지정합니다. 컨테이너가 아닌 아티팩트를 저장하는 방법에 대한 자세한 내용은 이미지 및 아티팩트 저장을 참조하세요.

다음 빌드 구성은 빌드된 Go 패키지를 gs://mybucket/에 저장하도록 artifacts 필드를 설정합니다.

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"
        ]
      }
    }
}

Dockerfile 사용

gcloud 도구 또는 빌드 트리거를 사용하여 Cloud Build에서 Docker 빌드를 실행할 경우 Dockerfile만 사용하여 이미지를 빌드할 수 있습니다. 별도의 빌드 구성 파일이 필요하지 않습니다. Docker 빌드를 더 조정하려면 Dockerfile 외에도 빌드 구성 파일을 제공하면 됩니다. Dockerfile을 사용하여 Docker 이미지를 빌드하는 방법은 Docker 빠른 시작을 참조하세요.

Cloud Build 네트워크

Cloud Build가 각 빌드 단계를 실행할 때 단계의 컨테이너를 cloudbuild라는 로컬 Docker 네트워크에 연결합니다. cloudbuild 네트워크는 Google Cloud 서비스에서 사용자 인증 정보를 자동으로 찾는 데 사용할 수 있는 애플리케이션 기본 사용자 인증 정보(ADC)를 호스팅합니다. 중첩된 Docker 컨테이너를 실행 중이고 ADC를 기본 컨테이너에 노출하거나 docker 단계에서 gsutil 또는 gcloud를 사용하려면 docker build 단계에서 --network 플래그를 사용하세요.

YAML

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

JSON

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

다음 단계