Container Registry:Build container images with an Enterprise Edition instance

Step 1: Connect to a source code platform

Step 2: Create a namespace

1. Log on to the Container Registry console.

2. In the top navigation bar, select a region.

3. In the left-side navigation pane, click Instances.

4. On the Instances page, click the target Enterprise Edition instance.

5. In the left-side navigation pane, choose Repository > Namespace.

6. On the Namespace page, click Create Namespace.

7. In the Create Namespace pane, enter a Namespace name, turn Automatically Create Repository On or Off, and then click Confirm.

   If you turn Automatically Create Repository On, configure the following parameters:

   Parameter	Description
   Repository Type	Public: By default, users must log on to the Enterprise Edition instance to pull public images. If you want to allow anonymous pulls, enable the anonymous pull setting for the instance. Because unauthorized users can pull images from public repositories, we recommend that you set your repositories to Private to ensure data security. Private: Users must log on to the Enterprise Edition instance and have pull permissions to pull private images.
   Immutable Image Tags	Specifies whether image tags can be Flexible. If enabled, all image tags in this repository except for latest cannot be overwritten. This ensures the consistency of container image versions.
   Accelerated Image	Specifies whether to Off the repository. If you select this option, an accelerated image tag with the _accelerated suffix is automatically generated in this repository.

Step 3: Create an image repository

Create an image repository and connect it to a source code repository. This repository stores all images built from the connected source code repository.

1. Log on to the Container Registry console.

2. In the top navigation bar, select a region.

3. In the left-side navigation pane, click Instances.

4. On the Instances page, click the Enterprise Edition instance that you want to manage.

5. In the left-side navigation pane of the instance details page, choose Repository > Repositories.

6. On the Repositories page, click Create Repository.

7. In the Repository Info wizard, configure Namespace, Repository Name, Repository Type, Image Version, Accelerated Image, Summary, and Description. Then, click Next.

8. In the Code Source step, select a Code Source, configure the Build Settings and Build Rules, and then click Create Repository.

   Parameter	Description
   Code source	Select a code source.
   Build settings	Automatically Build Images When Code Changes: If you enable this option, an image build is automatically triggered when code is committed to a branch. Build With Servers Deployed Outside Chinese Mainland: If this option is enabled, the build process uses accelerated links to pull data from overseas sources. You can enable Build With Servers Deployed Outside Chinese Mainland if your project uses GitHub or Bitbucket as the code source, or if your Dockerfile downloads files from overseas and you experience cross-border network instability. Build Without Cache: If this option is enabled, the base image is forcibly re-pulled for each image build, which may increase build time. You can disable Build Without Cache to accelerate image builds.

   Click the target image repository on the Repositories page. If Build appears in the left-side navigation pane, the image repository is successfully connected to the source code repository.

Step 4: Build an image

1. Log on to the Container Registry console.

2. In the top navigation bar, select a region.

3. In the left-side navigation pane, click Instances.

4. On the Instances page, click the Enterprise Edition instance that you want to manage.

5. In the left-side navigation pane of the instance details page, choose Repository > Repositories.

6. On the Repositories page, find the target repository and click Manage in the Actions column.

7. In the left-side navigation pane, click Build. In the Build Rules section, click Add Build Rule. In the Build Information step, configure the parameters and then click Next.

   Parameter	Description
   Type	The type of source code reference to use. Valid values: Branch and Tag.
   Branch/Tag	Select or enter a branch or tag. Regular expressions are supported. If the regular expression is release-(?<imageTag>\w*), a code change on a branch named release-v1 triggers an automatic build of an image tagged v1. Manual builds are not supported. For more information, see Named capturing groups in regular expressions. Note If you set a regular expression, only automatic builds are supported. Manual builds are not supported.
   Build Context Directory	The directory that contains the Dockerfile. The path is relative to the root directory of the selected branch or tag. For example, if your branch is master and your Dockerfile is in the root of the master branch, set the directory to /.
   Dockerfile Filename	The name of the Dockerfile. The default is Dockerfile.

8. In the Image Version step, configure the parameters, click Save, and then click Next.

   Note

   You can click Add Configuration to add up to three image tags.

   Parameter	Description
   Image Version	The image tag, such as latest. You can use named capturing groups to use content captured in the Branch/Tag setting.
   Build Time	The time (UTC+8) when the source code is pushed. Two formats are available, such as 20201015 and 202010151613. Note This parameter is optional. If you select this parameter, only automatic builds are supported. Manual builds are not supported.
   Commit ID	The ID of the latest commit. By default, the first six characters are used. You can move the slider to set the number of characters. Note This parameter is optional. If you select this parameter, only automatic builds are supported. Manual builds are not supported.

9. In the Build Configurations step, configure the build parameters and then click Confirm.

   Parameter	Description
   Build Architecture	Select one or more build architectures. Parallel builds are supported, which results in a single image tag that corresponds to multiple architecture-specific images.
   Build Parameters	The runtime arguments for the image build, specified as case-sensitive key-value pairs. You can set up to 20 build arguments. These arguments can modify environment variables in the Dockerfile, allowing the same Dockerfile to produce different results.

10. Trigger the build rule.

    You can trigger the build rule in one of the following ways:

    • On the Build page, in the Build Rules section, find the target build rule and click Build in the Actions column.

    • Commit code to the configured branch of the source code repository to trigger an image build.

    Note

    • On the Build page, in the Build Log section, find the target build task and click Cancel in the Actions column to cancel the build task.

    • On the Build page, in the Build Log section, find the target build task and click Log in the Actions column to view the logs of the build process.

    In the left-side navigation pane, click Image Version. If the built image is displayed, the build was successful.

Example 1: Build from a fixed branch

An image build is triggered when the source code on the main branch changes or you manually start an immediate build. The working directory for the build is /, and the build uses the file named Dockerfile in this directory. The image tag generated after the build is complete is latest. The build rule is shown in the figure below.

Example 2: Build from a regex-matched branch

An image build is triggered when the source code of a branch that starts with release- changes. The working directory is /, and the build file is the Dockerfile in the working directory.

For example, if code changes on the release-v1 branch, the regular expression release-(?<imageTag>\w*) captures v1 from the branch name into the imageTag variable, which is then used as the image tag. After the build is complete, the resulting image tag is v1-202010151625-d4ef3dc3b77a011a5779eec7efdd45. The build rule is shown in the following figure.

Related operations