Build multi-architecture container images

Step 1: Prepare your project

Prepare the source code repository for your image build. For demonstration purposes, you can create a project by using the following Go file and Dockerfile.

// Save as hello.go
package main
import (
        "fmt"
        "runtime"
)
func main() {
        fmt.Printf("Hello, %s!\n", runtime.GOARCH)
}

FROM golang:alpine AS builder
RUN mkdir /app
ADD . /app/
WORKDIR /app
RUN go build -o hello hello.go
FROM alpine
RUN mkdir /app
WORKDIR /app
COPY --from=builder /app/hello .
CMD ["./hello"]

Step 2: Create an image repository

Create an image repository and link it to a source code repository. The system pushes all image builds triggered from the source code repository to this image 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, choose 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 configuration wizard, set Code Source, Build Settings, and Build Rules, and click Create Repository.

   Parameter	Description
   Code Source	The source code provider.
   Build Settings	Automatically Build Images When Code Changes: Triggers a build rule when you commit code to a branch. Build With Servers Deployed Outside Chinese Mainland: builds the image in a data center outside the Chinese mainland and pushes the image to the specified region. Select this option if your Dockerfile needs to download files from sites outside the Chinese mainland and the cross-border network connection is unstable. Build Without Cache: forces a fresh pull of the base image for every build. Selecting this option may increase image build times.

   On the Repositories page, click the target image repository. If Build appears in the left-side navigation pane, the image repository is successfully linked to the source code repository.

Step 3: Create a multi-arch build rule

For this demonstration, we use linux/amd64 and linux/arm64 as the build architectures.

1. Log on to the Container Registry console.

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

3. In the left-side navigation pane, choose 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, set the parameters and click Next.

   Parameter	Description
   Type	The type of source code to build from. Valid values: Branch and Tag.
   Branch/Tag	Select or enter a branch or tag. Regular expressions are supported. For example, if you use the regular expression release-(?<imageTag>\w*), a code change in the release-v1 branch automatically triggers a build for an image with the tag v1. For more information, see Appendix: Named capturing groups for regular expressions. Note After you set a regular expression, only automated builds are triggered. You cannot manually trigger an immediate build.
   Dockerfile Directory	The path to the Dockerfile, relative to the repository root. For example, if the Dockerfile is in the root directory, enter /.
   Dockerfile Filename	The name of the Dockerfile. The default value is Dockerfile.

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

   Note

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

   Parameter	Description
   Image Version	The image tag, such as latest. This supports named capturing groups to use content captured from the Branch/Tag setting.
   Build Time	The time when the source code is pushed, in UTC+8. Supported formats are YYYYMMDD and YYYYMMDDHHMM. Examples: 20201015 and 202010151613. Note This parameter is optional. If you select this parameter, only automated builds are supported and you cannot manually trigger an immediate build.
   Commit ID	The commit ID of the latest code push. By default, the first 6 characters are used. You can use the slider to adjust the length. Note This parameter is optional. If you select this parameter, only automated builds are supported and you cannot manually trigger an immediate build.

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

   Parameter	Description
   Build Architecture	Select the build architectures. Builds for the selected architectures run in parallel, and the resulting images are associated with a single image tag.
   Build Parameters	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, which allows a single Dockerfile to produce different image variations.

10. Trigger the build rule.

    You can trigger the build rule in two ways:

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

    • Push code to the main branch of your source code repository.

    Note

    • To cancel a running build task, go to the Build page. In the Build Log section, find the target task and click Cancel in the Actions column.

    • To view the log of a build task, go to the Build page. In the Build Log section, find the target task and click Log in the Actions column.

    In the left navigation bar, click Image Version. You can see the built image, which indicates that the build is successful.

Step 4: Verify the build result

1. After the build is complete, go to the management page of the target repository and click Image Version in the left-side navigation pane to view the built images for the target tag.

   In the digest list for the image tag, you can see that the main tag includes images for both linux/amd64 and linux/arm64, which confirms a successful multi-arch build.

2. Verify the image on machines with linux/amd64 and linux/arm64 architectures.

   • On a machine with the linux/amd64 architecture, run the following command:

     docker run --rm xxx-registry.cn-hangzhou.cr.aliyuncs.com/test/golang-test:main

     The expected output:

     Hello, amd64!

   • On a machine with the linux/arm64 architecture, run the following command:

     docker run --rm xxx-registry.cn-hangzhou.cr.aliyuncs.com/test/golang-test:main

     The expected output:

     Hello, arm64!

   The results show that the built image can be used on machines with different architectures.

Appendix: Named capturing groups

Named capturing groups

A capturing group saves the content matched by a subexpression within a regular expression. You can reference this group later, either inside or outside the regular expression. Groups can be numbered or explicitly named. This appendix provides a brief introduction to named capturing groups.

The general format for a named capturing group is as follows:

(?<name>Expression)

You can use a named capturing group to convert release-11-2-10 into 11.2.10. The corresponding regular expression is as follows:

release-(?<major>\d*)-(?<minor>\d*)-(?<version>\d*) 

When this regular expression matches release-11-2-10, it automatically stores the matched subexpressions in the groups named major, minor, and version. You can then use the following template to generate the string 11.2.10:

${major}.${minor}.${version}