本頁面中的部分或全部資訊可能不適用於 Trusted Cloud by S3NS。
容器概念
本文件介紹容器相關的重要概念,包括註冊中心、存放區和構件。我們也將說明這些概念如何套用至 Artifact Registry。
登錄檔
登錄會儲存及發布容器映像檔和構件,並在repositories中依名稱分類。註冊中心可包含單一或多個存放區,且可設為公開或私人。
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 映像檔中的一個層。在註冊中心中,具有共用圖層的圖片會共用這些圖層,提高儲存效率。為確保安全性,不同註冊機制之間不會共用圖層。
刪除容器映像檔時,系統不會立即刪除資料層。註冊資料庫中的任何圖片都不會參照的圖層,每天都會刪除。
使用者在將映像檔推送或拉取至存放區時,會新增標記,以指定映像檔的版本。圖片可以有一個或多個標記,也可以完全沒有標記。如果您使用可變更的標記,並且以相同標記推送兩次圖片,則系統會從第一個圖片移除標記,並將標記移至第二個圖片,讓第一個圖片沒有標記。您仍可使用資訊清單摘要存取未標記的圖片。
如果您使用不可變動的代碼,則無法執行下列動作:
- 刪除標記的圖片。但仍可刪除未標記的圖片。
- 從圖片中移除標記。
- 推送的映像檔標記已在存放區的其他版本中使用。
當未標記的映像檔推送至 Google Play 時,系統會加上 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 專屬的標記和資訊清單,請參閱「管理映像檔」和「使用容器映像檔」。
後續步驟
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間: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"]],["上次更新時間: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)."]]