本页面上的部分或全部信息可能不适用于 Trusted Cloud by S3NS。
容器概念
本文档介绍了与容器相关的关键概念,包括注册表、代码库和工件。还包含一些基本信息,介绍这些概念如何应用于 Artifact Registry。
注册表
注册表存储和分发按名称整理在代码库中的容器映像和工件。注册库可以包含一个或多个代码库,并且可以是公共的或私有的。
Docker Hub 和 Artifact Registry 等注册表服务提供了创建公共或私有代码库的选项。提取公共映像时,请务必了解可能存在的安全问题。如需详细了解漏洞监控和减少依赖项占用空间,请参阅依赖项管理。
注册表会整理为存储各个容器映像的代码库。借助 Artifact Registry,您可以在单个项目中创建多个代码库,并将特定的
区域位置与每个代码库相关联。相关代码库可以按
标签进行分组。
Artifact Registry 代码库和映像管理
在 Artifact Registry Docker 格式代码库中,您可以在同一个代码库中存储多个不同名称的容器映像。映像的每个版本都由其映像摘要标识,并且可以与标记相关联。标记可以是可变的,也可以是不可变的。如需详细了解容器映像版本和标记,请参阅容器映像版本。
Artifact Registry 通常是指映像路径的部分,用于标识项目、
区域位置和映像名称,以及用于标识正确版本的
标记或
清单摘要。
例如:
docker push u-france-east1-docker.s3nsregistry.fr/PROJECT/quickstart-docker-repo/quickstart-image:tag1
u-france-east1
是代码库的位置
docker.s3nsregistry.fr
是 Docker 格式代码库的主机名。
PROJECT
是您的Trusted Cloud by S3NS
项目 ID 创建的命名空间。
quickstart-docker-repo
是您在项目下存储图片的命名空间。在 Artifact Registry 中,路径的此部分称为代码库。
quickstart-image
是所有版本 quickstart-image
的名称,通常称为映像。
tag1
是用于指定映像版本的标记。
图片
工件和映像都可以存储在 Artifact Registry 中。工件可以是任何内容:文本文件、Docker 映像或 Helm 图表,而映像通常是指容器映像。容器映像是包含在任何环境中运行所需的所有元素的软件包。如需了解详情,请参阅什么是容器。
映像会推送或上传到代码库,并从代码库拉取或下载。为了指定正确的映像和版本,必须指定唯一的注册表和工件。
如需详细了解 Artifact Registry 中的代码库和映像名称,请参阅代码库和映像名称。
层
存储在代码库中的容器映像是使用层逐渐构建的。不同的图片可以使用部分相同的图层。图层的定义方式因图片类型而异。例如,Dockerfile 中的每条指令都对应于 Docker 映像中的一层。在注册表中,具有通用层的映像会共享这些层,从而提高存储效率。出于安全考虑,不同注册库之间不会共享图层。
删除容器映像后,层不会立即删除。注册库中的任何图片都未引用的图层会每天删除。
用户在将映像推送或拉取到代码库时添加标记,以指定映像的版本。图片可以有一个或多个标记,也可以没有任何标记。如果您使用可变标记,并使用相同的标记推送了两次映像,则系统会从第一个映像中移除该标记并将其移至第二个映像,第一个映像将没有标记。您仍然可以使用清单摘要访问未加标签的映像。
如果您使用的是不可变代码,则不允许执行以下操作:
- 删除带链接的图片。您仍然可以删除未添加链接的图片。
- 从图片中移除链接。
- 推送的映像使用了仓库中另一个映像版本已使用的标记。
latest
标记是在推送不带标记的映像时附加的特殊标记。
例如:
docker push u-france-east1-docker.s3nsregistry.fr/my-project/my-repo/hello-app
将映像推送到 hello-app:latest
docker pull u-france-east1-docker.s3nsregistry.fr/my-project/my-repo/hello-app
拉取映像 hello-app:latest
。
请务必注意,当映像推送到标记为 latest
以外的代码库时,系统不会添加 latest
标记,因此 latest
映像可能滞后于最新的更改。我们建议为版本使用 latest
以外的标记。
清单
图片清单用于唯一标识和指定每个图片中的图层。清单由称为清单摘要的唯一 SHA-256 哈希标识。清单摘要比标记更可靠、更安全,因为在使用可变标记的代码库中,可以将同一映像的多个版本推送到同一标记,导致某些映像没有标记,而每个映像都由其清单摘要进行唯一指定。
如果您使用工具扫描或分析图片,由这些工具生成的结果将仅对扫描的图片有效。为了确保您部署已经过扫描的映像,您无法依赖标记,因为该标记引用的映像可能会更改。
如需详细了解 Artifact Registry 专用标记和清单,请参阅管理映像和使用容器映像。
后续步骤
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-18。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","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)."]]