Getting Started with Registries

Introduction and Lesson Goals

Welcome to the first lesson in our course on working with container registries, specifically Artifact Registry . In this course, you'll learn how to effectively manage and deploy container images using Google Cloud's fully managed container registry service. Artifact Registry is a critical component of modern containerized applications. It serves as a secure, scalable repository where you can store, manage, and deploy your Docker container images. Think of it as a specialized warehouse for your containerized applications — it keeps your images organized, versioned, and readily available for deployment across your Google Cloud infrastructure. Understanding Artifact Registry matters because it seamlessly integrates with the broader Google Cloud ecosystem, especially services like Google Kubernetes Engine (GKE) and Cloud Build. It eliminates the complexity of managing your own registry infrastructure while providing enterprise-grade security and performance. By the end of this lesson, you will have: A solid foundation in what Artifact Registry is and how it fits into container workflows . Verified that your environment is properly configured to work with Google Cloud container registries. Confirmed your gcloud CLI installation and explored the available Artifact Registry commands. This practical verification will ensure you're ready to dive into hands-on exercises in the upcoming lessons.

Container Registries in Context

A container registry serves three primary functions: Stores your container images. Manages different versions of those images. Serves them to systems that need to run your containers. When you build a Docker image locally, you need to push it to a registry to deploy it to servers or share it with team members. The registry acts as a centralized hub for your images. While you may be familiar with the public Docker Hub, Google Cloud provides private, cloud-native alternatives with Artifact Registry. Teams invested in the Google Cloud ecosystem often choose Artifact Registry for several advantages: Native Cloud IAM Integration: Provides fine-grained access control using Google Cloud IAM. High Availability: Geographically distributed across Google Cloud regions for better performance and reliability. Seamless Service Integration: Works effortlessly with Google Cloud container services like GKE and Cloud Build. Managed Service: Google Cloud handles the operational overhead of running a registry, including scaling, patching, and maintenance. Multi-format Support: Artifact Registry supports not just Docker images but also other package formats like Maven, npm, and Python packages.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Artifact Registry Essentials

Artifact Registry organizes your container images using a hierarchical structure:

Repositories: Collections of related Docker images (e.g., a repository for your my-app application).
Images: A specific version of your containerized application within a repository.
Tags: Human-readable labels that point to a specific image (e.g., latest, v1.2).

You will work with image URIs (Uniform Resource Identifiers) that uniquely identify your images.

Artifact Registry URI format:
region-docker.pkg.dev/project-id/repository-name/image-name:tag

Example: us-central1-docker.pkg.dev/my-project/my-repo/my-app:latest

Keypoints:

Uses a region-specific endpoint (e.g., us-central1-docker.pkg.dev) — the docker in the endpoint indicates this is a Docker-format registry, as Artifact Registry also supports other artifact types like Maven and npm packages
Includes your Google Cloud project ID
Specifies the repository name within Artifact Registry
Image name and tag identify the specific image version

Artifact Registry offers private repositories by default, requiring Google Cloud credentials to ensure your images remain secure. For public sharing, you can configure repository permissions to allow unauthenticated access, though this requires explicit IAM policy configuration.

Understanding regions is crucial. Each repository exists within a specific Google Cloud region, and you must pull images from the correct endpoint. Artifact Registry provides granular regional control, allowing you to place your images closer to your compute resources for better performance. Pricing is based on data storage and network egress, with costs that are generally competitive and predictable.

Note on Google Container Registry (GCR): If you encounter references to GCR (gcr.io), this is the legacy predecessor to Artifact Registry. While GCR still functions, Google recommends migrating to Artifact Registry for new projects. GCR uses a simpler URI format (gcr.io/project-id/image-name:tag) but lacks many of Artifact Registry's features. This course focuses on Artifact Registry as the current best practice.

Common Gotchas and Key Terms

As you begin working with Artifact Registry, there are several common issues that can cause confusion. Keeping these in mind will help you troubleshoot more effectively:

Region and Endpoint Mismatches: This is one of the most frequent sources of problems. Artifact Registry repositories are region-specific. A repository created in us-central1 won't be accessible from a europe-west1 endpoint. Always ensure that your Docker configuration and image URIs match the correct registry endpoint.
Permission Errors: These often occur when Cloud IAM policies aren't configured correctly. Artifact Registry requires specific permissions for different operations — for example, you need artifactregistry.repositories.uploadArtifacts to push images. If you encounter access issues, checking your IAM policies and service account permissions is a good first step.
Authentication Configuration: Unlike some other registries, Google Cloud requires explicit Docker authentication configuration using gcloud auth configure-docker. If you forget this step or need to authenticate to a new regional endpoint, Docker won't be able to push or pull images. The authentication configuration persists in your Docker config file, but you may need to reconfigure it when working with new Artifact Registry regions.
Project ID Confusion: Google Cloud uses project IDs in image URIs, not account numbers. Make sure you're using the correct project ID, which may differ from your project name.
Repository Must Exist First: Unlike some registries, you must explicitly create an Artifact Registry repository before pushing images to it. Pushing to a non-existent repository will fail.

Understanding key terminology will also help you navigate container registry documentation and concepts. Here are the most important terms:

A registry refers to the overall Artifact Registry service in your Google Cloud project, while a repository is a specific collection of related images within that registry.
An image is a specific version of your containerized application. It can be referenced by a tag, which is a human-readable label (like latest or v1.2), or by its digest, which is a unique, immutable identifier based on its content.
The URI is the complete address used to pull or push an image, combining the registry endpoint, project ID, repository name, and a tag or digest.
A service account is a special type of Google Cloud account used by applications and services to authenticate, rather than individual users.

Introduction and Lesson Goals

Container Registries in Context

Join the 1M+ learners on CodeSignal

Artifact Registry Essentials

How Artifact Registry Integrates with Docker and Google Cloud

Tools You'll Use (and What's Pre-installed on CodeSignal)

Verify Your Environment (What We'll Run)

Common Gotchas and Key Terms

Summary and What's Next