Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/container-registry/docs/using-with-google-cloud-platform below:

Using Container Registry with Google Cloud

Stay organized with collections Save and categorize content based on your preferences.

To simplify your build and deployment workflows, some Google Cloud service accounts and runtime environments are pre-configured with permissions to access containers stored in the same project.

This page summarizes common integrations with Google Cloud products and the associated requirements to access containers.

By default, service accounts for some common integrations are configured with Cloud Storage permissions to access Container Registry within the same project.

For the service account used by Compute Engine VMs, including VMs in Google Kubernetes Engine clusters, access is based on both IAM permissions and storage access scopes.

You must configure or modify permissions yourself if:

• You are using a service account in one project to access Container Registry in a different project
• You are using a default service account with read-only access to storage, but you want to both pull and push images
• You are using a custom service account to interact with Container Registry

Refer to the product-specific sections for additional information.

By default, the Cloud Build service account has permissions to push and pull images when Container Registry is in the same project.

You must configure the appropriate permissions yourself in the following cases:

• Cloud Build is in a different project than the repositories that you want the builds to access.
• Your builds are using a service account other than the default Cloud Build service account. In this case, you must grant the service account permissions to access Container Registry.

You can create VM instances using images stored in Container Registry.

If the VM instance and Container Registry are in the same Google Cloud project, the Compute Engine default service account is configured with permissions to pull images.

If the VM instance is in a different project or if the VM instance uses a different service account, you must grant the service account the appropriate permissions to access the storage bucket used by Container Registry.

By default, a Compute Engine VM has the read-only access scope configured for storage buckets. To push private Docker images, the VM instance must have the read-write storage access scope.

For details about permissions and access scopes, see Integrating with Google Cloud services.

When you create a VM you can deploy an image to it. To learn more, see the Compute Engine documentation for deploying containers and creating VM instance templates.

For information about how to start a container-optimized Compute Engine instance using an image in your registry, see Starting a Docker container via cloud-config.

For additional information, see Creating and Configuring Instances.

Google Kubernetes Engine uses the service account configured on the VM instances of cluster nodes to push and pull images.

If the Google Kubernetes Engine cluster and the Container Registry storage bucket are in the same Google Cloud project, the Compute Engine default service account is configured with the appropriate permissions to push or pull images.

If the cluster is in a different project or if the VMs in the cluster use a different service account, you must grant the service account the appropriate permissions to access the storage bucket used by Container Registry.

By default, a Compute Engine VM has the read-only access scope configured for storage buckets. To push private Docker images, the VM instance must have the read-write storage access scope.

For details about permissions and access scopes, see Integrating with Google Cloud services.

You can run a Container Registry image on a Google Kubernetes Engine cluster using the following command:

kubectl run [NAME] --image=[HOSTNAME]/[PROJECT-ID]/[IMAGE]:[TAG]

where:

• [NAME] is the name of the resource
• [HOSTNAME] is listed under Location in the console. It's one of four options: gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io.
• [PROJECT-ID] is your Google Cloud console project ID. If your project ID contains a colon (:), see Domain-scoped projects.
• [IMAGE] is the image's name in Container Registry.
• [TAG] is the tag that identifies the version of the image in Container Registry. If you do not specify a tag, Container Registry will look for the default tag latest.

For more information about Kubernetes commands, see Overview of kubectl.

You can deploy images stored in Container Registry to Cloud Run.

To deploy to Cloud Run, you must have the Owner or Editor role, or both the Cloud Run Admin and Service Account User roles, or any custom role that includes this specific list of permissions.

To learn about deploying an image to Cloud Run, see the Cloud Run documentation.

You can use the App Engine Flexible Environment to customize an existing runtime (such as Java 8), or to provide your own runtime by supplying a custom Docker image or Dockerfile.

With Cloud Build, you can automate building your containers, pushing them to Container Registry, and deploying them to App Engine.

By default, the App Engine default service account has permissions to pull from and push to repositories in the same project.

If App Engine is in a different project, you must grant the App Engine service account with permissions to access your Container Registry repository.

You can deploy an image hosted by Container Registry to App Engine using the Google Cloud CLI.

1. Create the App Engine configuration file for your app.
2. Build a Docker image and push it to your repository. You can use Cloud Build to build and push your container to the repository.

3. Deploy your image to App Engine by running the following command:

   gcloud app deploy --image-url=[HOSTNAME]/[PROJECT-ID]/[IMAGE]:[TAG]
   

where:

• [HOSTNAME] is listed under Location in the console. It's one of four options: gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io.
• [PROJECT-ID] is your Google Cloud console project ID. If your project ID contains a colon (:), see Domain-scoped projects.
• [IMAGE] is the image's name in Container Registry.
• [TAG] is the tag that identifies the version of the image in Container Registry. If you do not specify a tag, Container Registry will look for the default tag latest.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Certain Google Cloud service accounts and runtime environments are pre-configured with permissions to access containers within the same project, simplifying build and deployment workflows."],["By default, service accounts for integrations like Cloud Build, Compute Engine, and Google Kubernetes Engine have permissions to access Container Registry in the same project."],["You must manually configure or adjust permissions if accessing Container Registry across different projects, needing read/write access with a read-only default service account, or using a custom service account."],["Compute Engine VMs and Google Kubernetes Engine cluster nodes require both IAM permissions and storage access scopes, with `read-write` scope needed to push images."],["Deploying to Cloud Run requires specific roles or permissions, and deploying to App Engine might require granting the App Engine service account access to your Container Registry repository if it's in a different project."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4