빌드를 실행하면 Cloud Build가 빌드 로그를 수집하여 로그 버킷에 저장합니다. 빌드 구성 파일 설정에 따라 빌드 로그는 Cloud Logging 버킷, Cloud Storage 버킷 또는 두 위치 모두에 저장됩니다. 로그가 포함된 로깅 또는 Cloud Storage 버킷의 유형을 구성할 수도 있습니다. 버킷의 위치와 유형은 빌드 로그를 분석하는 기능과 버킷 설정을 제어할 수 있는 정도에 영향을 미칩니다.
개요
빌드 구성 파일을 설정할 때는 다음 사항을 고려하세요.
저장된 빌드 로그의 보관 기간을 제어하려면 Logging으로 전송하세요. 또한 Logging의 로그 뷰어는 Cloud Storage에 비해 버킷에서 특정 빌드 로그를 검색하는 더 많은 옵션을 제공합니다. 하지만 로깅을 사용하면 빌드 로그가 생성되는 시점과 로깅이 이를 수신하는 시점 사이에 지연이 발생할 수 있습니다.
빌드 로그가 생성되는 시점과 Logging이 수신하는 시점 사이의 지연 시간을 줄이려면 빌드 로그를 Cloud Storage의 버킷으로 전송하세요.
버킷 소유권은 저장된 빌드 로그와 상호작용하는 방식에도 영향을 미칩니다. 예를 들어 사용자 소유 버킷을 사용하면 버킷의 설정을 구성할 수 있지만 Google Cloud소유 버킷은 Google Cloud에 의해 생성되며 사용자가 변경할 수 없습니다. 로깅 및 Cloud Storage에는 빌드 로그를 수신하는 버킷의 유형을 구성하는 여러 옵션이 있습니다.
버킷 위치
빌드 구성 파일에서 logging 필드를 설정하여 빌드 로그가 전송되는 위치를 확인합니다.
GCS_ONLY: 빌드 로그가 Cloud Storage 버킷으로 전송됩니다.CLOUD_LOGGING_ONLY: 빌드 로그가 Logging 버킷으로 전송됩니다.LEGACY: 빌드 로그가 두 위치의 버킷으로 전송됩니다.logging이 정의되지 않은 경우 Cloud Build는 이 값을 사용합니다.NONE: 빌드 로그가 저장되지 않습니다.
빌드 로그를 Logging으로 보내는 경우 Logging 버킷 옵션에 대한 자세한 내용은 Cloud Logging 라우팅 구성을 참고하세요. 빌드 로그를 Cloud Storage로 전송하는 경우 사용 가능한 Cloud Storage 버킷에 관한 정보는 다음 섹션을 참고하세요. 버킷 소유권 고려사항 섹션에서는 버킷 위치와 관계없이 버킷 소유권에 따른 버킷의 이점과 고려사항을 설명합니다.
Cloud Storage의 버킷 옵션
빌드 로그가 Cloud Storage로 전송되면 Cloud Build는 빌드 구성 파일의 logsBucket 및 defaultLogsBucketBehavior 필드를 평가하여 빌드 로그를 수신하는 Cloud Storage 버킷의 유형을 결정합니다.
logsBucket 필드에는 모든 유형의 버킷이 있을 수 있습니다. logsBucket가 정의된 경우 defaultLogsBucketBehavior 값과 관계없이 로그가 항상 Cloud Storage의 해당 버킷으로 전송됩니다. logsBucket이 정의되지 않은 경우 defaultLogsBucketBehavior의 값이 다음과 같이 사용됩니다.
REGIONAL_USER_OWNED_BUCKET: 빌드 로그가 Cloud Storage에서 Cloud Build가 생성하고 사용자가 소유한 버킷으로 전송됩니다. 이 버킷은 사용자의 프로젝트에 있으며 빌드와 동일한 리전을 사용합니다.LEGACY_BUCKET: 빌드 로그는 Cloud Build에서 생성하고 Google Cloud에서 소유한 버킷으로 전송되며, 이 버킷은 Google Cloud에서 소유한 프로젝트에 있습니다. 이 값은 이 필드를 정의되지 않은 상태로 두는 것과 동일합니다.
Dockerfile에서 빌드할 때의 로그 스토리지
Dockerfile에서 빌드할 때 빌드 로그 저장소를 설정하려면 gcloud builds
submit를 실행할 때 default-buckets-behavior 플래그 값 중 하나를 포함하세요.
regional-user-owned-bucket: 빌드 로그가 Cloud Storage에서 Cloud Build가 생성하고 사용자가 소유한 버킷으로 전송됩니다. 이 버킷은 사용자의 프로젝트에 있으며 빌드와 동일한 리전을 사용합니다.legacy-bucket: 빌드 로그는 Cloud Build에서 생성하고 Google Cloud에서 소유한 버킷으로 전송되며, 이 버킷은 Google Cloud에서 소유한 프로젝트에 있습니다. 이 값은 이 필드를 정의되지 않은 상태로 두는 것과 동일합니다.
버킷 소유권 고려사항
Cloud Storage를 사용하는지 Logging을 사용하는지와 관계없이 빌드 로그를 사용자가 소유한 버킷으로 전송하는 것이 좋습니다. 이는 사용자가 만든 버킷 (예: logsBucket을 사용자가 만든 버킷으로 설정한 경우) 또는 Cloud Build에서 만들었지만 사용자가 소유한 버킷(예: 리전 사용자 소유 버킷의 설정을 구성한 경우)일 수 있습니다. 이렇게 하면 언제든지 버킷의 특정 속성을 수정하고 버킷의 로그를 볼 수 있습니다. Google Cloud소유 버킷은Google Cloud소유 프로젝트에 있으므로 버킷을 보거나 수정할 수 없으며 빌드 로그는 빌드 세부정보 페이지의 빌드 로그 섹션에서만 볼 수 있습니다.
일반적으로 사용자가 만든 버킷은 버킷 생성 중과 생성 후 모두 버킷 설정을 구성하는 데 가장 유연합니다. 하지만 이 경우 항상 사용자 생성 버킷이 빌드의 요구사항과 일치하는지 확인해야 합니다. 버킷 리전 관리와 같은 경우 Cloud Build에서 생성하고 사용자가 소유한 버킷을 사용하면 기본적으로 Cloud Storage에서 사용할 수 있고 항상 빌드와 동일한 리전에 있는 버킷으로 빌드 로그를 전송할 수 있습니다. 다음 섹션에서는 이 사용 사례에 대해 자세히 설명합니다.
버킷 리전 고려사항
이 설정은 데이터 상주 요구사항을 준수하는 데 도움이 될 수 있으므로 빌드 버킷을 빌드 리전에 맞게 구성하는 것이 좋습니다. 이 방식으로 지역을 정렬하려면 다음을 고려하세요.
Logging 및 Cloud Storage의 사용자 생성 버킷은 버킷 생성 시 정의된 리전을 사용합니다. 사용자가 만든 버킷을 빌드의
logging값으로 설정하는 경우 리전이 빌드 리전과 일치하는지 확인하세요.Cloud Storage에서 리전 사용자 소유 버킷을 사용하도록 빌드 로그를 구성한 경우 빌드 로그는 항상 빌드와 동일한 리전의 버킷으로 전송됩니다.
Google Cloud소유 버킷은 Google Cloud정의 리전으로 설정됩니다. 따라서 이 리전이 빌드의 리전과 항상 일치하지 않을 수 있습니다.
기존 빌드 구성 파일에 defaultLogsBucketBehavior 추가
이전에 logging 또는 logsBucket를 구성한 기존 빌드 구성 파일에 defaultLogsBucketBehavior 옵션을 추가하는 경우 모든 로그 스토리지 설정을 평가하여 로그가 의도한 대로 저장되는지 확인하는 것이 좋습니다. 다음 중 하나라도 해당하는 경우 Cloud Build는 defaultLogsBucketBehavior를 무시합니다.
logging을CLOUD_LOGGING_ONLY또는NONE로 설정합니다.logging이GCS_ONLY또는LEGACY로 설정되고logsBucket이 정의됩니다.
빌드 구성 파일에 로그 저장 필드가 정의되지 않은 상태로 빌드를 실행하면 Cloud Build가 logging를 LEGACY로 설정합니다.
다음 단계
- 빌드 로그를 저장, 확인, 삭제하는 방법 알아보기
- Cloud Build에서 만든 감사 로그에 대해 알아봅니다.
- 빌드 결과를 확인하는 방법 알아보기
- Cloud Build IAM 권한 자세히 알아보기