This topic describes terms that are related to container images to help you use Container Registry.

container image
A container image is a standard form of an application package. You can use a Dockerfile to package an application and the environments on which the application depends to a container image, push the container image to an image repository, pull the container image in a test or production environment, and then start containers.
Container Registry instance
If you want to create your own private images, you must first create a Container Registry instance and then create an image repository on the instance. You must log on to the Container Registry instance before you can manage images in the container repository. After you modify an image, you can push the image to the image repository again. Alternatively, you can use the image build feature to generate an image in your data center and then push the image to the image repository.
Addresses of container images

Example: address of a public image

Address of a public image on a Container Registry Enterprise Edition instance:

Address of a public image on a Container Registry Personal Edition instance:

  • instance: the name of the Container Registry Enterprise Edition instance. You can specify a domain name for the Container Registry Enterprise Edition instance. You can use the domain name to access the instance from all regions. For more information, see Use a custom domain name to access a Container Registry Enterprise Edition instance.
  • namespace: the name of the namespace.
  • repository: the name of the image repository. Container Registry Personal Edition supports only tier-1 repository names. Container Registry Enterprise Edition supports multi-tier repository names. Example: agent/client/prod.
  • v1: the image tag. This parameter is optional. Default value: latest.
A Dockerfile is a text document that is used to build an image. The Dockerfile contains the instructions and descriptions that are required to build an image. Tools such as Docker can automatically build container images by reading the instructions in a Dockerfile.
OCI standard
The Open Container Initiative (OCI) standard contains the following specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The OCI Image Specification unifies the container image format that is used by various container tools. As a result, standard container images can be used in various container software and environments.
OCI artifact
Container Registry can host container images. You can also package various types of data such as Helm charts and Cloud Native Application Bundles (CNAB) artifacts to OCI compliant artifacts based on the structure such as OCI manifests and OCI indexes that are defined in the OCI Artifact specification. This way, different artifacts can be stored, managed, and distributed by Container Registry in a centralized manner. Container Registry Enterprise Edition can host OCI artifacts. For more information, see Push and pull a custom OCI artifact.
Helm Chart
  • Helm is a package manager that is used to manage charts and the releases of the charts.
  • A chart is a collection of files that describe a related set of Kubernetes resources. A chart contains images, dependencies, and resource definitions that are required to run an application. A chart can be a collection of files that describe WordPress and MySQL resources or a collection of resource description files for an etcd cluster.

Container Registry Enterprise Edition can host Helm charts. For more information, see Push and pull Helm charts.

cloud-native delivery chain
Cloud-native delivery chains allow you to combine tasks such as image building, image scanning, image geo-replication, and image distribution in a single delivery chain. Cloud-native delivery chains are secure and can be monitored and traced. You can use cloud-native delivery chains to distribute, scan, and deploy images around the world by submitting only changes to the source code. Container Registry Enterprise Edition supports cloud-native delivery chains. For more information, see Create a delivery chain
RAM-based access control
Resource Access Management (RAM) is an identity and access control service that is provided by Alibaba Cloud. Multiple RAM users can be created within an Alibaba Cloud account. RAM users can represent employees, systems, and applications of an enterprise.
RAM user
A RAM user is a physical identity that has a fixed ID and credential information. A RAM user can represent a person or an application. You can grant different image permissions to different RAM users. For more information, see Configure policies for RAM users to access Container Registry.
Object Storage Service (OSS) is a secure, cost-effective, and highly reliable Alibaba Cloud storage service that allows you to store large volumes of unstructured data. OSS supports RESTful API operations that are independent of the OSS console. You can store and access data from all applications anytime and anywhere.
OSS Bucket
A bucket is a container that is used to store objects in OSS. All objects are stored in buckets. You can configure various attributes for a bucket, including the region, access control list (ACL), and storage class. You can create buckets of different storage classes to store your data. Container Registry Enterprise Edition can host container images in OSS buckets. You can create custom OSS buckets. For more information, see Use RAM to grant permissions to access custom OSS buckets.