소스 코드를 Cloud Run에 배포하면 해당 소스가 Cloud Storage 버킷에 저장됩니다. 그러면 Cloud Build가 컨테이너 이미지에 코드를 자동으로 빌드하고 해당 이미지를 이미지 레지스트리에 푸시합니다. 각 빌드는 자체 작업자에서 실행됩니다. Cloud Run은 배포 시 빌드된 이미지를 가져옵니다.
Cloud Build가 VPC 서비스 제어 보안 빌드 컨텍스트에 사용하는 빌드 작업자 풀을 맞춤설정하려면 작업자 풀을 맞춤설정합니다. 이 페이지는 Google Cloud CLI를 사용하여 소스에서 Cloud Run 서비스 또는 함수를 배포하고 Cloud Build에서 사용하는 비공개 풀을 구성하는 플랫폼 개발자를 대상으로 합니다. 빌드 작업자 풀 gcloud CLI 플래그는 소스 배포(--source)에 지원되지만 컨테이너 이미지 배포(--image)에는 지원되지 않습니다.
프로젝트에 대한 서비스 사용량 소비자(roles/serviceusage.serviceUsageConsumer) 역할
Cloud Run 서비스 ID에 대한 서비스 계정 사용자(roles/iam.serviceAccountUser) 역할
Cloud Build 서비스 계정에 필요한 역할을 보려면 클릭
이 동작을 재정의하지 않는 한 Cloud Build는 자동으로 Compute Engine 기본 서비스 계정을 기본 Cloud Build 서비스 계정으로 사용하여 소스 코드와 Cloud Run 리소스를 빌드합니다. Cloud Build에서 소스를 빌드할 수 있게 하려면 관리자에게 프로젝트의 Compute Engine 기본 서비스 계정에 Cloud Run 빌더(roles/run.builder)를 부여해 달라고 요청하세요.
기본적으로 빌드 프로세스 중에 Cloud Build가 인터넷에 무제한으로 액세스할 수 있습니다. VPC 서비스 제어(VPC SC) 경계를 설정했고 빌드 액세스를 경계 내부에 저장된 종속 항목(예: npm 패키지)으로만 제한하려면 Cloud Build 비공개 작업자 풀 기능을 사용하면 됩니다.
비공개 작업자 풀이 Cloud Run 서비스와 다른 프로젝트에 있으면 Cloud Build 서비스가 작업자 풀에 액세스할 수 있도록 Cloud Run 서비스 에이전트(service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com)에 Cloud Build WorkerPool 사용자(cloudbuild.workerPoolUser) 역할을 부여해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Set build worker pools (source deploy)\n\nWhen you deploy your source code to Cloud Run, that source\nis stored in a Cloud Storage bucket. Cloud Build then\nautomatically builds your code into a container image and pushes that image to\nan image registry. Each build runs on its own worker. Cloud Run\nimports the built image when deploying.\n\nIf you wanted to customize the build worker pool that Cloud Build\nuses for a VPC Service Controls secured build context, you would customize the\nworker pool. This page is relevant for platform developers who are deploying\nCloud Run [services](/run/docs/deploying-source-code) or\n[functions](/run/docs/deploy-functions) from source using the Google Cloud CLI,\nand configuring private pools that are used by Cloud Build. The build\nworker pools gcloud CLI flags are supported for\n[source deployments](/run/docs/deploying-source-code) (`--source`), and not\nsupported for [container image deployments](/run/docs/deploying) (`--image`).\n\nBefore you begin\n----------------\n\n- Enable the Cloud Run Admin API and the Cloud Build API:\n\n ```bash\n gcloud services enable run.googleapis.com \\\n cloudbuild.googleapis.com\n ```\n\n After the Cloud Run Admin API is enabled, the Compute Engine default service account is\n automatically created.\n\n### Required roles\n\nYou or your administrator must grant the deployer account and the\nCloud Build service account the following IAM roles. \n\n#### Click to view required roles for the deployer account\n\nTo get the permissions that you need to build and deploy from source,\nask your administrator to grant you the following IAM\nroles:\n\n- [Cloud Run Source Developer](/iam/docs/understanding-roles#run.sourceDeveloper) (`roles/run.sourceDeveloper`) on your project\n- [Service Usage Consumer](/iam/docs/understanding-roles#serviceusage.serviceUsageConsumer) (`roles/serviceusage.serviceUsageConsumer`) on your project\n- [Service Account User](/iam/docs/understanding-roles#iam.serviceAccountUser) (`roles/iam.serviceAccountUser`) on the Cloud Run service identity \n\n#### Click to view required roles for the Cloud Build service account\n\nCloud Build automatically uses the\n[Compute Engine default service\naccount](/build/docs/cloud-build-service-account) as the default Cloud Build service account to build your source code and\nCloud Run resource, unless you override this behavior. For\nCloud Build to build your sources, ask your administrator to grant\n[Cloud Run Builder](/iam/docs/understanding-roles#run.builder)\n(`roles/run.builder`) to the Compute Engine default\nservice account on your project: \n\n```bash\n gcloud projects add-iam-policy-binding PROJECT_ID \\\n --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \\\n --role=roles/run.builder\n \n```\n\nReplace \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e with your Google Cloud\nproject number, and \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud\nproject ID. For detailed instructions on how to find your project ID, and project number,\nsee [Creating\nand managing projects](/resource-manager/docs/creating-managing-projects#identifying_projects).\n\nGranting the Cloud Run builder role to the Compute Engine default service account\ntakes a couple of minutes to [propagate](/iam/docs/access-change-propagation).\n| **Note:**\n|\n|\n| The [`iam.automaticIamGrantsForDefaultServiceAccounts` organization policy constraint](/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants)\n| prevents the Editor role from being automatically granted to default service accounts. If you\n| created your organization after May 3, 2024, this constraint is enforced by\n| default.\n|\n|\n| We strongly recommend that you enforce this constraint to disable the automatic role grant. If you\n| disable the automatic role grant, you must decide which roles to grant to the default service\n| accounts, and then [grant these roles](/iam/docs/granting-changing-revoking-access)\n| yourself.\n|\n|\n| If the default service account already has the Editor role, we recommend that you replace the\n| Editor role with less permissive roles.To safely modify the service account's roles, use [Policy Simulator](/policy-intelligence/docs/simulate-iam-policies) to see the impact of\n| the change, and then [grant and revoke the\n| appropriate roles](/iam/docs/granting-changing-revoking-access).\n\nFor a list of IAM roles and permissions that are associated with\nCloud Run, see\n[Cloud Run IAM roles](/run/docs/reference/iam/roles)\nand [Cloud Run IAM permissions](/run/docs/reference/iam/permissions).\nIf your Cloud Run service interfaces with\nGoogle Cloud APIs, such as Cloud Client Libraries, see the\n[service identity configuration guide](/run/docs/configuring/services/service-identity).\nFor more information about granting roles, see\n[deployment permissions](/run/docs/reference/iam/roles#additional-configuration)\nand [manage access](/iam/docs/granting-changing-revoking-access).\n\nSecure your build with private pools\n------------------------------------\n\nBy default, Cloud Build has unlimited internet access during the build\nprocess. If you have set up a VPC Service Controls (VPC SC) perimeter and want to\nlimit the build's access only to dependencies stored inside the perimeter (for\nexample, npm packages), you can use the\n[Cloud Build private worker pools](/build/docs/private-pools/private-pools-overview)\nfeature.\n\nIn general, follow these steps to set up your private pool:\n\n1. Create your private worker pool. See [Creating and managing private pools](/build/docs/private-pools/create-manage-private-pools).\n2. Configure your VPC Service Controls perimeter. See\n [Using VPC Service Controls](/build/docs/private-pools/using-vpc-service-controls).\n\n3. If your private worker pool is in a different project than your\n Cloud Run service, you need to grant the Cloud Run\n [Service Agent](/iam/docs/service-agents)\n (`service-`\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`@serverless-robot-prod.iam.gserviceaccount.com`)\n the [Cloud Build WorkerPool User](/iam/docs/understanding-roles#cloudbuild.workerPoolUser)\n (`cloudbuild.workerPoolUser`) role so that the Cloud Build service can\n access the worker pool.\n\n ```bash\n gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \\\n --member serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com \\\n --role roles/cloudbuild.workerPoolUser\n ```\n\n Replace:\n - \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e with the project number where the service runs.\n - \u003cvar translate=\"no\"\u003ePRIVATE_POOL_PROJECT_ID\u003c/var\u003e with the *ID* of the project in which the worker pool is located. See [Running builds in a private pool](/build/docs/private-pools/run-builds-in-private-pool#permissions) for more information.\n4. Deploy your service from source to build using a private pool:\n\n ### gcloud\n\n To specify a private pool to build when deploying from source\n code, use the `--build-worker-pool` flag: \n\n ```bash\n gcloud run deploy SERVICE \\\n --source . \\\n --build-worker-pool WORKER_POOL\n ```\n\n Replace:\n - \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e with name of your service.\n - \u003cvar translate=\"no\"\u003eWORKER_POOL\u003c/var\u003e with the name of the private pool.\n\n If you are deploying a function, add the `--function` flag with the\n function entry point from your source code.\n\nDelete build worker pools\n-------------------------\n\nYou can delete build worker pools for existing services. \n\n### gcloud\n\nTo clear the Cloud Build worker pool for source deployments, use\nthe `--clear-build-worker-pool` flag: \n\n```bash\ngcloud run deploy SERVICE \\\n --source . \\\n --clear-build-worker-pool WORKER_POOL\n```\n\nReplace:\n\n- \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e with name of your service.\n- \u003cvar translate=\"no\"\u003eWORKER_POOL\u003c/var\u003e with the name of the private pool you would like to delete.\n\nIf you are deploying a function, add the `--function` flag with the\nfunction entry point from your source code."]]
