Proposal: Arm64 Support and Multi-Architecture Image Publishing for Harbor

[ranimandepudi]

Tested and confirmed: Harbor functions fully on both Arm64 and Amd64 platforms, including the UI, API, registry, and multi-architecture artifact handling.

As the author of this contribution from Arm, I welcome any feedback, collaboration, or questions from the Harbor community.

Thank you to the community for your continued support. Arm ambassadors are always ready to support Harbor.

Related PR in the main Harbor repository: goharbor/harbor#21982

[stonezdj]

@ranimandepudi bitnami has already built arm images for Harbor, it is open-sourced in https://github.com/bitnami/containers/tree/main/bitnami, and images is available in https://hub.docker.com/r/bitnami/harbor-core, maybe you could reference it.

[ranimandepudi]

@ranimandepudi bitnami has already built arm images for Harbor, it is open-sourced in https://github.com/bitnami/containers/tree/main/bitnami, and images is available in https://hub.docker.com/r/bitnami/harbor-core, maybe you could reference it.

Thanks for sharing this @stonezdj !

Just to clarify — the changes I proposed in the PR are focused solely on enabling multi-arch Docker image builds without impacting existing functionality. Since Photon OS already supports both amd64 and arm64, my patch preserves the current behavior while adding support for Arm builds in a clean and upstream-friendly way.

[OrlinVasilev]

@ranimandepudi can you link the PR in the main repository for the changes!
I find it super useful if we as a project can provide our arm64 arch images! +1

[OrlinVasilev]

@ranimandepudi can you please fix your DCO

[OrlinVasilev]

I think it's a MUST have!

[ranimandepudi]

@OrlinVasilev Thank you for your support! I have made the updates based on your comments. Please let me know if any further changes are needed.

[ranimandepudi]

@wy65701436 — Could you please review it and let me know if anything needs to be updated ?
Also, you can check this PR: https://github.com/goharbor/harbor/pull/21982/files
which doesn’t have a CI pipeline. However, if you pull the PR and test it — since there are no functional changes — it should work fine on both Arm and Amd instances.

I have the CI pipeline changes in my local, can push them once this is tested !!

[ranimandepudi]

@wy65701436 @Vad1mo
Can we move this forward ??

[MinerYang]

Hi @ranimandepudi ,

By reviewing this proposal and the PR. Besides what we have discussed above(though some of them are still unresolved), I have a few other details that might need mentioned here

• I believe we should identify all the binray that needs by harbor and its source during the building process. e.g. While we build trivy-adapter, it actually needs 2 binaries, one is Trivy itself, which we always download from upstream, another is for trivy-adpater, it could choose to be built from src or downloading from upstream https://github.com/goharbor/harbor-scanner-trivy, In this case, we should consider to have a arm64 version of it as well.
• There are few comments added in old PR Harbor on Multi-arch (arm64 & amd64) harbor#21825 by @bitsf which still have the same problems in the new one. As you were saying in the proposal it would not block the current build, so basically we don't want change any image name, build tag and all other staff if not necessary.
• From a overall perspective, I prefer we have a structure design to refine our whole build process.
  i. first having an agreement on how should all the go build binaries adopt for arm64 and amd64 build process, e.g.should the GOARCH and the GOOS been passed explicitly?
  ii. then how do we refine and build all the Dockerfile.base, Dockerfile etc..
  iii. How does the git action and our nightly e2e well tested the harbor instance deployed by these multi-arch images. There's might be more subtle issue will occur like python or Node.js native extensions may fail when running more specific robot cases. We need thorough investigation and a robust test structure to support it.

[ranimandepudi]

Is it possible to further detail the current flowchart by specifying branches for different conditions and the final actions to be executed? Additionally, could you summarize the points that need to be changed at present, and clarify whether there are any outstanding items in the current plan that will need to be addressed in phase 2?

If we release it as sandbox and people use it, I think we can address if any challenges come up ! But I can add the phase 1 and 2 plan in the proposal

[reasonerjt]

If we release it as sandbox and people use it, I think we can address if any challenges come up ! But I can add the phase 1 and 2 plan in the proposal

For sandboxing, you can fork Harbor and release it in your forked repo. I suggest we need to ensure the quality of the change before it's merged and released.

[Schwitzd]

Trilled to have also arm64 image, then I can switch from Bitnami chart

[bupd]

lgtm

[chlins]

I suggest we divide this task into two phases. In Phase 1, we will update the relevant build scripts and introduce a new pipeline for ARM. This will allow us to run unit tests, end-to-end tests, and ensure the entire workflow operates on ARM. However, no deliverables will be shipped to Harbor users during this phase; users who wish to try it in advance can build and test it locally. Once Phase 1 is complete, we will proceed to Phase 2, where we will focus on building both ARM and AMD images and releasing them to users, including the necessary updates for docker-compose and Helm. How do you think? @ranimandepudi

[wy65701436]

Hi @ranimandepudi

I had an offline discussion with @chlins — we're aligned to move forward with Harbor ARM support. I have just two general comments on the proposal:

1. Development Phases

   Could we clearly define the phases in the proposal as follows?

•     Phase 1: Complete code implementation and add a new CI pipeline for ARM validation.
  

•     Phase 2: Publish ARM images with a multi-arch index; ship both online and offline installers.
  

•     Phase 3: Validate the Helm chat, and publish it if necessary.
  

2. Architecture Parameter
   Please clarify that we’ll use a single parameter to specify the architecture. The CI pipeline should be able to set this parameter to build for a specific architecture or both.

   The data flow would look like this (simplified for trivy):

   Arch => make => compile (needed for core, jobservice, registryctl; not needed for Trivy)
   => make build -e ARCH=**
   => _build_trivy
   => builder.sh
   => Dockerfile.binary

Let me know if this makes sense or needs further refinement.

[wy65701436]

Hi @ranimandepudi

I had an offline discussion with @chlins — we're aligned to move forward with Harbor ARM support. I have just two general comments on the proposal:

1. Development Phases
   Could we clearly define the phases in the proposal as follows?


* ```
      Phase 1: Complete code implementation and add a new CI pipeline for ARM validation.
  ```

* ```
      Phase 2: Publish ARM images with a multi-arch index; ship both online and offline installers.
  ```

* ```
      Phase 3: Validate the Helm chat, and publish it if necessary.
  ```


2. Architecture Parameter
   Please clarify that we’ll use a single parameter to specify the architecture. The CI pipeline should be able to set this parameter to build for a specific architecture or both.
   The data flow would look like this (simplified for trivy):
   Arch => make => compile (needed for core, jobservice, registryctl; not needed for Trivy)
   => make build -e ARCH=**
   => _build_trivy
   => builder.sh
   => Dockerfile.binary

Let me know if this makes sense or needs further refinement.

@ranimandepudi Can we address those comments so we can move forward with the implementation? Please let me know if you have any concerns.

[ranimandepudi]

@stonezdj @MinerYang @wy65701436 @OrlinVasilev
I have updated the file. Please check and let me know if there is something for discussion before merging it !!

[chlins]

@ranimandepudi Please fix the DCO as well.

[ranimandepudi]

@chlins @OrlinVasilev @wy65701436 @OrlinVasilev I have updated the PR according to the comments. Let me know if anything to be updated !! Thanks

[chlins]

lgtm

[wy65701436]

@ranimandepudi please help to fix the DCO, thanks.

[wy65701436]

lgtm

[bupd]

lgtm