Google Cloud: Container Registry will be replaced by Artifact Registry

-

Spoiler Alert: (you've got some time)

Container Registry will be replaced by Artifact Registry. Please upgrade your projects to Artifact Registry before March 18, 2025.

On March 18, 2025, Container Registry will be replaced by Artifact Registry. We understand this change may affect your production workloads, so we've put together resources to make this transition as smooth as possible for you.

What do you need to know?

To retain access to your container images, please take note of these critical dates and actions you need to take related to the Container Registry shutdown:

  • March 18, 2025: You will no longer be able to push new images to Container Registry.
  • April 22, 2025: You will lose access to existing images in Container Registry. To maintain access, you must copy them to the Artifact Registry before this date.
  • May 22, 2025: All requests to the gcr.io domain will be handled exclusively by Artifact Registry. Ensure the Artifact Registry API is enabled.

Can you keep using Container Registry until the shutdown date?

  • For projects already using Container Registry:
    Yes, you can continue using Container Registry for both pushing and pulling images until March 18, 2025.
  • For new projects starting after May 15, 2024:
    No, new projects cannot use Container Registry. They must use Artifact Registry for hosting and managing container images. All gcr.io repositories will be hosted on Artifact Registry by default as per the notification sent on May 15, 2023.

What do you need to do?

Upgrade to Artifact Registry, which is the recommended service for container image storage and management on Google Cloud, before March 18, 2025. Follow the steps below to upgrade:

  • Evaluate where Container Registry is used in your organization:
    • Identify projects within your organization that use Container Registry and images that need to be moved to Artifact Registry.
    • Use this utility to help identify usage.
  • For images that you no longer need:
    • There is no need to copy these images to Artifact Registry. We recommend that you clean up the storage buckets that store these images after you have validated that your upgraded projects are working as intended.

What else do you need to do?

  • If you use Container Registry transitively through another Google Cloud service, such as Cloud Build, App Engine, or Cloud Functions, upgrade to Artifact Registry using repositories with gcr.io support to ensure that your workflows continue to function.
  • gcr.io domain support in Artifact Registry will be supported throughout the lifetime of Artifact Registry.

You can find your affected projects using our Container Registry usage finder.

We understand that these changes may require some planning, but we are here to support you as you make the transition. Please do not hesitate to reach out to our Google Cloud Support team, if you have any questions or require assistance.

Thanks for choosing Google Cloud. 

Popular

Federated user activity made easy

-
Image
 Federated user activity made easy. The other day I was auditing a sandboxed account in AWS and started investigating resources connected to a federated role for a group of students that are no longer enabled on the account. I noticed a few objects that should have been elsewhere or terminated after the fact, regardless, neither here nor there. After about 30 minutes of sifting through logs, creating custom queries, and trying to put them together, I lost interest because of the time and day-to-day priorities. I felt this was a good use case for me to test out some of the functionality of CloudGuard's investigation and correlation engine within the platform and try out this voice-over platform. Enjoy - Video below: if you feel inclined to research further, visit the product page
Read more

Meet Kaniko

-
Image
So, what is kaniko? Kaniko is a tool to build container images from a Dockerfile inside a container or Kubernetes cluster. Another great callout for me is that my CI provider, GitLab makes it super easy to implement in my pipelines. Kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile entirely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster. How does Kaniko work? The kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry. Within the executor image, we extract the filesystem of the base image (the FROM image in the Dockerfile). We then execute the commands in the Dockerfile, snapshotting the filesystem in userspace after each one. After each command, we append a layer of changed files to the base image (if there are any) and update image metadata. Highly recommend visiting their  repo  ...
Read more