Decouple Registry Login and Build Multi‑Arch Images with Alibaba Cloud Flow

Background

Previous Alibaba Cloud Flow image‑building steps had two major limitations:

Only one registry could be logged in per step, so a FROM image and the target image could not reside in different private registries.

Build cache was stored on OSS with a 5 GB size limit, causing failures for large caches and long upload times.

Enhanced Capabilities

Decoupled registry login and build/push: Separate steps allow independent logins to multiple registries, enabling different source and target registries.

Flexible cache management with Docker Buildx: Choose a remote cache stored in a registry (no size limit) or a local cache on a private build machine.

Multi‑architecture builds: Adding a --platform argument lets Buildx produce amd64 and arm64 images in a single run, sharing the same image tag.

Configuration Requirements

Set the build environment to Specify Container Build . For private build machines, select the Default VM Environment .

Example Scenario

Two Alibaba Cloud accounts are used:

Account A base image (private):

registry.cn-beijing.aliyuncs.com/hub-mirrors/openjdk:8-jdk-alpine

Account B target application image (private):

registry.cn-hangzhou.aliyuncs.com/yunxiao-demo/app1

Dockerfile (source repository:

https://atomgit.com/flow-example/spring-boot/blob/master/Dockerfile5

)

# Base image from account A, target image will be pushed to account B
FROM registry.cn-beijing.aliyuncs.com/hub-mirrors/openjdk:8-jdk-alpine

# Verify cache effectiveness
COPY deploy.sh deploy.sh

# Force cache miss for the JAR (each build produces a new JAR)
COPY target/application.jar app.jar

ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

A preceding Java build step must generate target/application.jar.

Old Flow Issue

The previous step combined docker login and docker build, binding the build to a single registry. When the base and target images belong to different accounts, the build fails.

New Flow

Separate login steps are added before the build step. Logs show two distinct login actions, after which the build can pull from the source registry and push to the target registry.

Remote Cache Usage

Selecting “Remote Cache” stores the cache in the target registry under the tag flow-docker-build-cache, e.g.:

registry.cn-hangzhou.aliyuncs.com/yunxiao-demo/app1:flow-docker-build-cache

Subsequent builds reuse this cache, skipping unchanged layers. For cross‑region builds, a VPC registry address can accelerate cache transfer, e.g.:

registry-vpc.cn-beijing.aliyuncs.com/hub-mirrors/openjdk:app1-flow-cache

When using a VPC cache, update both the login URL and the FROM line in the Dockerfile to the VPC address.

Local Cache Option

On private build machines, selecting “Local Cache” lets Docker use the daemon’s local storage. Running the build twice shows cached layers in the log, confirming local reuse.

Multi‑Architecture Build

Add the following parameter under “More Build Parameters”: --platform linux/amd64,linux/arm64 Buildx creates a manifest‑list image. The resulting tag, for example:

registry.cn-hangzhou.aliyuncs.com/yunxiao-demo/app1:2024-09-19-12-24-56

Pulling this tag on an amd64 host retrieves the amd64 image; pulling on an arm64 host retrieves the arm64 image.

Key References

Source‑based step implementation (repository): https://atomgit.com/flow-step Docker Buildx project:

https://github.com/docker/buildx