A Google Cloud Deploy execution environment is the environment in which Google Cloud Deploy executes its render and deploy operations. The execution environment consists of the following:
The Cloud Build worker pool (default or private) in which Google Cloud Deploy executes render and deploy operations.
The service account (default or alternate) that calls Google Cloud Deploy to perform these actions.
The storage location (default or alternate) for rendered manifests in Cloud Storage.
This article describes the default execution environment, service accounts, and storage for Google Cloud Deploy, as well as why and how you can change these defaults.
Defaults
The following are the defaults that Google Cloud Deploy uses to run, to execute rendering and deployment, and to store assets such as rendered manifests:
Default worker pool
By default, Google Cloud Deploy runs in the default Cloud Build worker pool. However, you can configure Google Cloud Deploy to use a Cloud Build private worker pool.
For more details about worker pools, see the Cloud Build Overview of default pools and private pools.
Default execution service account
By default, Google Cloud Deploy uses the default Compute Engine service account.
Default Google Cloud Deploy storage location
This value is the Cloud Storage bucket where Google Cloud Deploy stores your rendered manifests. By default, Google Cloud Deploy creates a Cloud Storage bucket, in the same region as the Google Cloud Deploy resources, taking the following form:
<location>.deploy-artifacts.<project ID>.appspot.com
Default Cloud Build timeout
By default, Cloud Build has a timeout of 1 hour on operations it performs for Google Cloud Deploy. You can change that timeout in the execution environment specification in target configuration.
The sections that follow describe the circumstances under which you would change any of these values, and links to instructions for doing so.
About Cloud Build worker pools
The Google Cloud Deploy execution environment can use one of the following:
-
The default worker pool is a secure, hosted environment with access to the public internet. Render and deploy operations are executed in that pool, isolated from other workloads.
A private pool
Private worker pools are private, dedicated pools that can be customized more than the default worker pool. That customization can include the ability to access resources in a private network. Like the default worker pool, private worker pools are hosted and fully managed by Cloud Build. These pools can scale up or scale down to zero, with no infrastructure to set up, upgrade, or scale.
The Cloud Build Private pools overview describes default worker pools and private worker pools more thoroughly, including a table comparing their features.
Changing the Google Cloud Deploy execution environment
You might change the Google Cloud Deploy execution environment under the following circumstances:
You want to deploy to a private Google Kubernetes Engine cluster
You want render or deploy operations, or both, to be performed in an environment that is isolated from other organizations.
You want these operations to be performed in an environment that isn't connected to the public internet.
You want separate environments for render and deploy.
You want to use a dedicated service account with permissions that are more specific to your use than the permissions available in the default service account.
You want to store rendered manifests in a location different from the default Cloud Storage bucket.
Configuration of all three parts of the execution environment (worker pool, service account, and storage) is done per target, in each target's YAML configuration.
Changing from the default pool to a private pool
You configure worker pools per target,
so that the pool is used for RENDER
or DEPLOY
(or both) for that target
only.
To use the default worker pool for both render and deploy operations, you don't need to do anything.
The following is a sample target configuration that specifies a private worker
pool for DEPLOY
and the default worker pool for RENDER
:
executionConfigs:
- usages:
- DEPLOY
workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
- RENDER
For more information about how to configure private pools for targets, see Delivery pipeline configuration documentation.
Changing from the default to custom execution service account
As with the worker pool, you can specify an alternate service account to use for
rendering or deploying (or both) per target. To do so, add the following line to
the target configuration, after the workerPool
element:
serviceAccount: "[name]@[project_name].iam.googleapis.com"
The specified service account must include the clouddeploy.jobRunner
role, as
described in the Google Cloud Deploy service accounts
document.
See Target definitions for more details on this configuration.
Changing the storage location
To change the storage bucket from the Google Cloud Deploy default, add the
following line to the target definition
in the workerPool
stanza:
artifactStorage: "gs://[bucket_name]/[dir]"
This configuration changes where the rendered manifests are stored, but does not affect where the rendering source is stored.
Deploying to a private cluster on a Virtual Private Cloud network
You can configure a target to deploy to a private GKE cluster connected to a Virtual Private Cloud network:
-
A private cluster is a VPC-native cluster whose nodes and Pods are isolated by default from the public internet.
If you plan to use the internal IP of the private cluster target, then set
internalIp
totrue
undergke
in the target configuration. In Cloud Build, create a private worker pool that you can use to deploy to this private cluster.
Configure the execution environment to use that private pool.
You must use this pool for
RENDER
. You can also use it forDEPLOY
. Here's an example that uses both:executionConfigs: - usages: - RENDER - DEPLOY workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
See Accessing private GKE clusters with Cloud Build private pools for more information.
Project and permissions considerations
It's simple to configure a target to use a private worker pool that can deploy to a private cluster. But there are some things to note if resources are in different projects.
When Google Cloud Deploy and the worker pool are in separate projects
To communicate with a private pool that has access to a VPC and that's in a different project from your target, the Google Cloud Deploy service agent needs sufficient permissions to talk to that project.
The execution service account also needs permissions to access the Cloud Storage bucket.
When the worker pool and the cluster are in separate projects
If the private GKE cluster is in a different project from the private worker pool, the execution service account requires sufficient permissions to talk to the project the cluster is in.
Using Google Cloud Deploy in a VPC Service Controls perimeter
Google Cloud Deploy supports VPC Service Controls.
You can follow the VPC Service Controls quickstart to set up a service perimeter.
Limitations
You must use a Cloud Build private worker pool for the target's execution environment—not the default worker pool.
The project that contains the worker pool and the project that contains your Google Cloud Deploy resources must remain in the same VPC Service Controls security perimeter.
Any GKE cluster you deploy to in the VPC Service Controls perimeter must be a private cluster.
To set up a private pool for a private cluster, see this tutorial.
What's next
Find out more about Google Cloud Deploy target configuration.
Read about Cloud Build private pools.
Read about how Cloud Build uses VPC Service Controls.
Learn about how Google Cloud Deploy uses service accounts.