[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[[["\u003cp\u003eRegistries store and distribute container images and artifacts, organizing them into repositories, which can be public or private, and services like Artifact Registry offer options for both.\u003c/p\u003e\n"],["\u003cp\u003eRepositories hold images and artifacts with the same name but varying tags, where untagged images are often given the \u003ccode\u003elatest\u003c/code\u003e tag, which can shift to newer images if not specified otherwise.\u003c/p\u003e\n"],["\u003cp\u003eImages can be anything, including text files, Docker images, or Helm charts, with container images containing everything needed to run in any environment, and they are pushed to and pulled from repositories.\u003c/p\u003e\n"],["\u003cp\u003eContainer images are built from layers, allowing for shared layers among images in the same registry to save storage space, and deleting an image does not immediately remove the layers.\u003c/p\u003e\n"],["\u003cp\u003eTags are used to specify image versions, with the \u003ccode\u003elatest\u003c/code\u003e tag being automatically added if no tag is specified, and using tags other than \u003ccode\u003elatest\u003c/code\u003e is recommended for releases to avoid confusion with more recent updates.\u003c/p\u003e\n"]]],[],null,["# Container concepts\n\nThis document introduces key concepts related to container images including\nregistries, repositories, and artifacts. Some basic information on how these\nconcepts apply to Artifact Registry and Container Registry\nis also included.\n\nArtifact Registry examples in this page primarily refer to Docker-format\nand `gcr.io` repositories. For more information, see\n[Supported formats](/artifact-registry/docs/supported-formats) and the\n[Repository overview](/artifact-registry/docs/repositories).\n\nRegistries\n----------\n\nA registry stores and distributes container images and artifacts organized by\nname within *repositories*. A registry may contain either a single repository\nor multiple repositories and can be public or private.\n\nRegistry services such as Docker Hub and Artifact Registry provide\noptions to create public or private repositories. When pulling public images it\nis important to understand the possible security concerns. Read about\n[dependency management](/artifact-registry/docs/dependencies) for more information on vulnerability\nmonitoring and reducing your dependency footprint.\nRegistries are organized into repositories which store individual container images. Artifact Registry lets you to create multiple repositories in a single project and associate a specific [regional or multi-regional location](/artifact-registry/docs/repo-locations) with each repository. Related repositories may be grouped by [labels](/artifact-registry/docs/creating-managing-labels).\n\nArtifact Registry repositories and image management\n---------------------------------------------------\n\nIn Artifact Registry Docker-format repositories, you can store multiple\ncontainer images with different names in the same repository. Each version of an\nimage is identified by its image *digest* and can be associated with a *tag* .\nTags can be mutable or immutable. For more information about container image\nversions and tags, see [Container image versions](/artifact-registry/docs/docker/names#versions).\nArtifact Registry typically refers to parts of the path to an image to identify the project, [regional or multi-regional location](/artifact-registry/docs/repo-locations), and name of the image along with the [tag](#tags) or [manifest digest](#manifests) to identify the correct version.\n\nFor example:\n\n\u003cbr /\u003e\n\n```\ndocker push us-west1-docker.pkg.dev/PROJECT/quickstart-docker-repo/quickstart-image:tag1\n```\n\n\u003cbr /\u003e\n\n- `us-west1` is the [location](/about/locations) of the repository\n- `docker.pkg.dev` is the hostname for Docker-format repositories.\n- \u003cvar translate=\"no\"\u003e\u003ccode translate=\"no\" dir=\"ltr\"\u003ePROJECT\u003c/code\u003e\u003c/var\u003e is the namespace created by your Google Cloud [project ID](/resource-manager/docs/creating-managing-projects#identifying_projects).\n- `quickstart-docker-repo` is the namespace under your project where you store images. In Artifact Registry, this part of the path is called the repository.\n- `quickstart-image` is the name for all versions of `quickstart-image` and is often referred to as *the image*.\n- `tag1` is the tag specifying the version of the image.\n\nImages\n------\n\nBoth artifacts and images can be stored within Artifact Registry. An\nartifact can be anything: a text file, a docker image, or a Helm chart, while an\nimage typically refers to a container image. Container images are packages of\nsoftware that contain all the necessary elements to run in any environment. Read\n[What are containers](/learn/what-are-containers) for more information.\n\nImages are *pushed* or uploaded to repositories and *pulled* or downloaded\nfrom repositories. In order to specify the correct image and version the unique\nregistry and artifact must be specified.\n\nFor more information on repository and image names in Artifact Registry,\nsee [Repository and image names](/artifact-registry/docs/docker/names).\n\n### Layers\n\nContainer images stored in repositories are constructed incrementally using\n*layers*. Different images can use some of the same layers. Layers are defined\nin different ways depending on the type of image. For example, each instruction\nin a Dockerfile corresponds to a layer in the Docker image. Within a registry,\nimages with common layers share those layers, increasing storage efficiency.\nFor security, layers are not shared across different registries.\n\nWhen you delete a container image, the layers aren't deleted immediately. Layers\nthat aren't referenced by any images in the registry are deleted daily.\n\n### Tags\n\nUsers add tags when pushing or pulling an image to a repository to specify the\nversion of an image. An image can have one or multiple tags, or no tags at all.\nIf you are using mutable tags, and you push an image twice with the same tag,\nthen the tag is removed from the first image and moved to the second, leaving\nthe first image without a tag. The un-tagged image is still accessible using its\n[manifest digests](#manifests).\n\nIf you are using immutable tags, then the following actions aren't permitted:\n\n- Delete a tagged image. Deleting untagged images is still permitted.\n- Remove a tag from an image.\n- Push an image with a tag that is already used by another version of the image in the repository.\n\nThe `latest` tag is a special tag appended when images are pushed without a tag.\n\nFor example:\n\n\u003cbr /\u003e\n\n```\ndocker push us-west1-docker.pkg.dev/my-project/my-repo/hello-app\n```\n\n\u003cbr /\u003e\n\npushes the image to `hello-app:latest`\n\n\u003cbr /\u003e\n\n```\ndocker pull us-west1-docker.pkg.dev/my-project/my-repo/hello-app\n```\n\n\u003cbr /\u003e\n\npulls the image `hello-app:latest`.\n\nIt is important to note that when an image is pushed to a repository with a tag\nother than `latest`, the `latest` tag is not added, therefore it is possible for\nthe `latest` image to be behind the most up to date changes. We recommended\nusing tags other than `latest` for releases.\n\n### Manifests\n\nImage Manifests uniquely identify and specify the layers within each image.\nManifests are identified by unique SHA-256 hashes called manifest digests.\nManifest digests are more reliable and secure than tags because in repositories\nwith mutable tags, multiple versions of the same image can be pushed to the same\ntag, leaving some images without tags, while each image is uniquely specified by\nits manifest digest.\n\nIf you use tools to scan or analyze images, results from these tools are only\nvalid for the image scanned. To ensure that you deploy the image that was\nscanned, you cannot rely on the tag because the image referred by the tag may\nchange.\n\nTo learn more about Artifact Registry specific tagging and manifests,\nread [Managing Images](/artifact-registry/docs/docker/manage-images) and [Using container Images](/architecture/using-container-images).\n\nWhat's next\n-----------\n\n- [Docker quickstart](/artifact-registry/docs/docker/quickstart)\n- [Work with container images](/artifact-registry/docs/docker)\n- [Helm quickstart](/artifact-registry/docs/helm/quickstart)\n- [Work with Helm charts](/artifact-registry/docs/helm)\n- Read about [DevOps](https://cloud.google.com/devops) and explore the [DORA research program](https://www.devops-research.com/research.html)."]]