From 301d2dd51e4b12ebbcc9df0f0c6dbc144055bbf8 Mon Sep 17 00:00:00 2001 From: zpyu Date: Wed, 31 Mar 2021 23:39:41 +0800 Subject: [PATCH 1/5] proposal for build multi arch images change the number info Signed-off-by: zpyu --- README.md | 2 +- proposals/new/multi-arch.md | 124 ++++++++++++++++++++++++++++++ workgroups/wg-multiarch/README.md | 2 +- 3 files changed, 126 insertions(+), 2 deletions(-) create mode 100644 proposals/new/multi-arch.md diff --git a/README.md b/README.md index 3e315247..e3d2dd2d 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ Workgroup is a virtual team of aggregating the efforts of all the interested par |[Scanning](./workgroups/wg-scanning/README.md)|The obejct of workgroup is centralizing and focusing efforts on supporting the ability of Harbor users to choose which container image scanner they want to use with Harbor directly|(Zach Hill@Anchore [zhill](https://github.com/zhill))|Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)) / Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))|Liz Rice@Aqua Security ([lizrice](https://github.com/lizrice)), Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)), Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| |[P2P Distribution](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p)|The objective of this working group is to aggregate efforts to discuss, design and finally deliver suitable P2P image distribution solutions for Harbor.|Fanjian Kong@Qihoo ([kofj](https://github.com/kofj))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[5 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)| |[Operator](./workgroups/wg-operator/README.md)|Aggregate the efforts from all the interested parties to discuss, design and finally deliver suitable Operator solutions for Harbor|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - | [14 Members](https://github.com/goharbor/community/blob/master/workgroups/wg-operator/README.md#members)|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - |[5 members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)| -|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[8 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)| +|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[12 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)| |[Performance](https://github.com/goharbor/community/tree/master/workgroups/wg-performance)|The purpose of this work group is to improve the performance and scalability of harbor in the use case of large data volumes.|ChenYu Zhang@Alauda ([chlins](https://github.com/chlins))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))/ Daniel Morinigo@Alauda ([danielfbm](https://github.com/danielfbm)) |[11 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-performance#members)| ## Structure diff --git a/proposals/new/multi-arch.md b/proposals/new/multi-arch.md new file mode 100644 index 00000000..903b6ba0 --- /dev/null +++ b/proposals/new/multi-arch.md @@ -0,0 +1,124 @@ +# Proposal: `Multi Arch Support` + +Author: `Zhipeng Yu / yuzp1996` + +Discussion: `none` + +## Background + +More and more companies need to support multi-architecture solutions, some of the more mainstream x86 and arm64 architectures, this proposal is to provide a solution to produce multi-architecture images + +## Plan + +When the release 2.3 of Harbor is released, the arm64 Harbor can be issued at the same time + +Release 2.3 of Harbor is tentatively scheduled to be released in mid-June 2021 + +## Target + +### Short Term Target + +We can provide support for different architectures in a different Harbor sub-projects. + +For example, in the harbor-arm repo, we can maintain the build logic and other related information for arm64 images + +### Long Term Target + +When the harbor is released, images of different architectures can be directly generated and push to registry. When deploying harbor, users do not need to distinguish the difference in architecture + +## Implementation + +### Glossary + +Upstream: github repository goharbor/harbor + +Downstream: github repository like harbor-arm harbor-loongson and so on + +### Upstream changes + +#### Goal + +Provides the ability to compile binary and image of a specific architecture based on environment variable parameters. (In the initial stage, the upstream only guarantees that the image of the amd64 architecture can be successfully built, and other versions are guaranteed by the corresponding downstream repository) + +#### Changes + +1. Increase the environment variable ARCH, the default is amd64, which can be overwritten during execution + +2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable ARCH, and place the generated binary in a directory named after the architecture, such as /make/photon/core/binary/amd64/core + +3. When the COPY instruction is executed in the Dockerfile, the binary address can be obtained according to the ARCH variable name, which can be /make/photon/core/binary/amd64/core + +4. Use docker buildx instead of docker build to build all the images, and determine the target architecture according to the specified parameter ARCH + +5. Determine the generated version name according to the environment variable ARCH name, if it is not amd64, we need to add the architecture name after the generated version number. For example v2.0.1-arm64 + +6. Add [Docker Buildx Action](https://github.com/marketplace/actions/docker-buildx) to the github aciton workflow to build a multi-architecture image. + +7. Add a file named adapter.sh, the content of the file is empty. Before executing the compile and build commands, please call adapter.sh scripts. This shell script file can be overwritten by downstream users, and downstream users can write their own modifications in this file, such as overriding the addresses of third-party dependencies or replacing Dockerfile. + +### Downstream changes + +#### Goal + +Maintain the build and test of an architecture images + +#### Change + +1. Introduce the harbor repository into the downstream repository through git Submodules + +2. Add a file named adapter.sh, responsible for making changes to areas that cannot be covered by upstream changes + +3. Add a Makefile (which can be called when performing github actions) to achieve such as overwriting adapter.sh or other functions + +4. Add github action files to maintain the build and test in them. The content of the github action should be modified based on the upstream github action, but it should be kept in sync at all times + +### Test + +We want to use the upstream test method to test, use docker-compose to deploy Harbor and then use the shell script to execute the test + +However, there are currently the following issues that need to be resolved + +1. During testing, docker-compose will be used to deploy Harbor and test, but it seems that docker-compose [only provides x86 binary files](https://github.com/docker/compose/releases), and we need to compile other versions by ourselves. + +2. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. + + +### Image strategy + +#### Repository + +The image will be hosted under the goharbor project of Docker Hub + +#### Tag + +Add the architecture name after the generated image version. For example： goharbor/harbor-core:v2.2.1-arm64 + + +### Related Implementation + +There are already some PRs and repository that have implemented this function, we can make full use of these contents + +Changes provided by this [PR](https://github.com/goharbor/harbor/pull/13788) can build amd64 and arm64 image simultaneously + +This repository https://github.com/querycap/harbor have created arm64 and amd64 image successfully + + + +## Development Iteration + +After several iterations, we need to ensure that the content in adapter.sh and github actions files in downstream repository is as small as possible，After each iteration, more code can be extracted and merge to upstream。 + +After the adapter.sh and github actions files of the downstream code disappear, we can no longer maintain the downstream repository. + + + +## Release + +When the goharbor/harbor is released, check out the same release branch under the downstream repository, and check the corresponding commit in git Submodules, execute the pipeline to generate the corresponding image and push it to the docker hub + +Readme.md or release notes needs to be updated in different branches to inform the images related information, such as location and corresponding tags + + +## Notify Users + +We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link. \ No newline at end of file diff --git a/workgroups/wg-multiarch/README.md b/workgroups/wg-multiarch/README.md index 17e42a2c..7ed39f23 100644 --- a/workgroups/wg-multiarch/README.md +++ b/workgroups/wg-multiarch/README.md @@ -12,7 +12,7 @@ The purpose of this working group is to enable Harbor to support multiple archit - ChenYu Zhang @Alauda ([chlins](https://github.com/chlins)) -- Daniel @Alauda ([danielfbm](https://github.com/danielfbm)) +- Daniel Filipe Bruehmueller Morinigo @Alauda ([danielfbm](https://github.com/danielfbm)) - JingTao Cheng @Alauda ([jtcheng](https://github.com/chengjingtao)) From c73be51e27031132ea77907a16593ad620998a2f Mon Sep 17 00:00:00 2001 From: zpyu Date: Wed, 14 Apr 2021 19:02:28 +0800 Subject: [PATCH 2/5] modify the proposal after meeting --- proposals/new/multi-arch.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/proposals/new/multi-arch.md b/proposals/new/multi-arch.md index 903b6ba0..9c6eae6f 100644 --- a/proposals/new/multi-arch.md +++ b/proposals/new/multi-arch.md @@ -44,17 +44,9 @@ Provides the ability to compile binary and image of a specific architecture base 1. Increase the environment variable ARCH, the default is amd64, which can be overwritten during execution -2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable ARCH, and place the generated binary in a directory named after the architecture, such as /make/photon/core/binary/amd64/core +2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable ARCH -3. When the COPY instruction is executed in the Dockerfile, the binary address can be obtained according to the ARCH variable name, which can be /make/photon/core/binary/amd64/core - -4. Use docker buildx instead of docker build to build all the images, and determine the target architecture according to the specified parameter ARCH - -5. Determine the generated version name according to the environment variable ARCH name, if it is not amd64, we need to add the architecture name after the generated version number. For example v2.0.1-arm64 - -6. Add [Docker Buildx Action](https://github.com/marketplace/actions/docker-buildx) to the github aciton workflow to build a multi-architecture image. - -7. Add a file named adapter.sh, the content of the file is empty. Before executing the compile and build commands, please call adapter.sh scripts. This shell script file can be overwritten by downstream users, and downstream users can write their own modifications in this file, such as overriding the addresses of third-party dependencies or replacing Dockerfile. +3. Add a file named adapter.sh, the content of the file is empty. Before executing compile and build commands, please call adapter.sh scripts. This shell script file can be overwritten by downstream users, and downstream users can write their own modifications in this file, such as overriding the addresses of third-party dependencies or replacing Dockerfile. ### Downstream changes @@ -70,7 +62,9 @@ Maintain the build and test of an architecture images 3. Add a Makefile (which can be called when performing github actions) to achieve such as overwriting adapter.sh or other functions -4. Add github action files to maintain the build and test in them. The content of the github action should be modified based on the upstream github action, but it should be kept in sync at all times +4. Add Dockerfile if necessary + +5. Add github action files to maintain the build and test in them. The content of the github action should be modified based on the upstream github action, but it should be kept in sync at all times ### Test @@ -78,7 +72,7 @@ We want to use the upstream test method to test, use docker-compose to deploy Ha However, there are currently the following issues that need to be resolved -1. During testing, docker-compose will be used to deploy Harbor and test, but it seems that docker-compose [only provides x86 binary files](https://github.com/docker/compose/releases), and we need to compile other versions by ourselves. +1. During testing, docker-compose will be used to deploy Harbor and test, but it seems that docker-compose [only provides x86 binary files](https://github.com/docker/compose/releases), and we need to compile other versions by ourselves. We can try to install docker-compose with pip 2. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. @@ -121,4 +115,9 @@ Readme.md or release notes needs to be updated in different branches to inform t ## Notify Users -We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link. \ No newline at end of file +We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link. + + +## Block Item + +1. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. \ No newline at end of file From e6dccd56a6a2defcaf141b9be6719c2b5a46b3de Mon Sep 17 00:00:00 2001 From: zpyu Date: Wed, 21 Apr 2021 18:41:38 +0800 Subject: [PATCH 3/5] add member ZhuBo and change ARCH to GOARCH --- README.md | 2 +- proposals/new/multi-arch.md | 4 ++-- workgroups/wg-multiarch/README.md | 2 ++ 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index e3d2dd2d..52695085 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ Workgroup is a virtual team of aggregating the efforts of all the interested par |[Scanning](./workgroups/wg-scanning/README.md)|The obejct of workgroup is centralizing and focusing efforts on supporting the ability of Harbor users to choose which container image scanner they want to use with Harbor directly|(Zach Hill@Anchore [zhill](https://github.com/zhill))|Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)) / Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))|Liz Rice@Aqua Security ([lizrice](https://github.com/lizrice)), Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)), Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| |[P2P Distribution](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p)|The objective of this working group is to aggregate efforts to discuss, design and finally deliver suitable P2P image distribution solutions for Harbor.|Fanjian Kong@Qihoo ([kofj](https://github.com/kofj))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[5 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)| |[Operator](./workgroups/wg-operator/README.md)|Aggregate the efforts from all the interested parties to discuss, design and finally deliver suitable Operator solutions for Harbor|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - | [14 Members](https://github.com/goharbor/community/blob/master/workgroups/wg-operator/README.md#members)|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - |[5 members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)| -|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[12 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)| +|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[13 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)| |[Performance](https://github.com/goharbor/community/tree/master/workgroups/wg-performance)|The purpose of this work group is to improve the performance and scalability of harbor in the use case of large data volumes.|ChenYu Zhang@Alauda ([chlins](https://github.com/chlins))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))/ Daniel Morinigo@Alauda ([danielfbm](https://github.com/danielfbm)) |[11 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-performance#members)| ## Structure diff --git a/proposals/new/multi-arch.md b/proposals/new/multi-arch.md index 9c6eae6f..18e39c08 100644 --- a/proposals/new/multi-arch.md +++ b/proposals/new/multi-arch.md @@ -42,9 +42,9 @@ Provides the ability to compile binary and image of a specific architecture base #### Changes -1. Increase the environment variable ARCH, the default is amd64, which can be overwritten during execution +1. Increase the environment variable GOARCH, the default is amd64, which can be overwritten during execution -2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable ARCH +2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable GOARCH 3. Add a file named adapter.sh, the content of the file is empty. Before executing compile and build commands, please call adapter.sh scripts. This shell script file can be overwritten by downstream users, and downstream users can write their own modifications in this file, such as overriding the addresses of third-party dependencies or replacing Dockerfile. diff --git a/workgroups/wg-multiarch/README.md b/workgroups/wg-multiarch/README.md index 7ed39f23..f356aa59 100644 --- a/workgroups/wg-multiarch/README.md +++ b/workgroups/wg-multiarch/README.md @@ -18,6 +18,8 @@ The purpose of this working group is to enable Harbor to support multiple archit - ZhiPeng Yu @Alauda ([yuzp1996](https://github.com/yuzp1996)) +- Bo Zhu @Alauda ([Jeremy-boo](https://github.com/Jeremy-boo)) + - WenLong Zhang@Loongson ([zhangwenlong8911](https://github.com/zhangwenlong8911)) - JingYun Hua@Loongson ([huajingyun01](https://github.com/huajingyun01)) From 95f1485e838edf597b51bfdebdd42c42706ae6c0 Mon Sep 17 00:00:00 2001 From: zpyu Date: Wed, 28 Apr 2021 10:28:48 +0800 Subject: [PATCH 4/5] modify proposal for multi arch --- proposals/new/multi-arch.md | 156 ++++++++++++++++++++++++------------ 1 file changed, 105 insertions(+), 51 deletions(-) diff --git a/proposals/new/multi-arch.md b/proposals/new/multi-arch.md index 18e39c08..60d03210 100644 --- a/proposals/new/multi-arch.md +++ b/proposals/new/multi-arch.md @@ -1,74 +1,116 @@ -# Proposal: `Multi Arch Support` +# Proposal: `Harbor Build Supports Multiple Architectures` -Author: `Zhipeng Yu / yuzp1996` +Author: `Zhipeng Yu / yuzp1996` and `bo zhu / Jeremy-boo` Discussion: `none` ## Background -More and more companies need to support multi-architecture solutions, some of the more mainstream x86 and arm64 architectures, this proposal is to provide a solution to produce multi-architecture images +At present, more and more companies need harbor to support multi-architecture construction. Some of the more mainstream ones are x86 and arm64 architectures. This proposal is to provide a solution for generating multi-architecture mirroring. ## Plan -When the release 2.3 of Harbor is released, the arm64 Harbor can be issued at the same time +When Habor releases version 2.3, support for arm64 Harbor image construction can be released at the same time -Release 2.3 of Harbor is tentatively scheduled to be released in mid-June 2021 +Harbor version 2.3 is tentatively scheduled to be released in mid-June 2021, so we must complete the development and testing of Harbor's multi-architecture construction before the end of May. -## Target +## Architecture Maturity Model -### Short Term Target +In order to provider a **short-term** and **long-term** process to introduce and iterate a new architecture into Harbor ecosystem a maturity model is proposed below -We can provide support for different architectures in a different Harbor sub-projects. +### Overview -For example, in the harbor-arm repo, we can maintain the build logic and other related information for arm64 images +#### Glossary -### Long Term Target +Upstream: github repository go-harbor/harbor -When the harbor is released, images of different architectures can be directly generated and push to registry. When deploying harbor, users do not need to distinguish the difference in architecture +Downstream: github repository like harbor-arm harbor-loongson and so on. -## Implementation +Short-term: We can provide support for different architectures in different Harbor sub-projects. +For example, in harbor-arm, we can maintain the construction logic of arm64 mirroring and other related information -### Glossary +Long-term: Harbor-arm keeps the synchronization update with goharbor/harbor. When goharbor/harbor updates a version, harbor-arm follows the update and then pushes the mirror image to the mirror warehouse to provide users with multi-architecture support. -Upstream: github repository goharbor/harbor +#### Jobs For Upstream -Downstream: github repository like harbor-arm harbor-loongson and so on +1. Increase the environment variable GOARCH, the default is amd64, which can be overridden by specifying a specific value during execution, like arm64 and so on. -### Upstream changes +2. When executing make compile to generate binary files, it can generate binary files of different architectures according to the environment variable GOARCH -#### Goal +3. Upstream version update and downstream synchronization issues. -Provides the ability to compile binary and image of a specific architecture based on environment variable parameters. (In the initial stage, the upstream only guarantees that the image of the amd64 architecture can be successfully built, and other versions are guaranteed by the corresponding downstream repository) + Scheme selection: -#### Changes + 1. Change the upstream github action workflow and add an action: After the upstream master branch merges with pr, a message is sent to notify the downstream that a build update needs to be performed. -1. Increase the environment variable GOARCH, the default is amd64, which can be overwritten during execution + 2. The downstream actively pulls the version through timed tasks, and judges whether it needs to be built and updated by comparing with its own version (currently the downstream adopts this kind of plan to update and build). -2. When executing make compile to generate binary, it can generate binary of different architectures according to the environment variable GOARCH +#### Jobs For Downstream -3. Add a file named adapter.sh, the content of the file is empty. Before executing compile and build commands, please call adapter.sh scripts. This shell script file can be overwritten by downstream users, and downstream users can write their own modifications in this file, such as overriding the addresses of third-party dependencies or replacing Dockerfile. +1. Add a github action, responsible for building and testing related matters (in theory, it is consistent with the upstream github action process, just modify specific environment variables and dependent parameters, such as building an arm64 image through docker buildx). -### Downstream changes +2. Add a file named adapter.sh, which is mainly responsible for covering the basic parameters and dependency related matters that need to build a multi-arch mirroring. -#### Goal +3. Add a Makefile (which can be called when performing github actions) to achieve, such as overwriting adapter.sh or other functions. -Maintain the build and test of an architecture images +4. Add Dockerfile if necessary -#### Change +#### Risk +Upstream modifications may affect downstream construction -1. Introduce the harbor repository into the downstream repository through git Submodules +1. Upstream changed the Dockerfile. -2. Add a file named adapter.sh, responsible for making changes to areas that cannot be covered by upstream changes +2. Upstream changed the build dependency package. -3. Add a Makefile (which can be called when performing github actions) to achieve such as overwriting adapter.sh or other functions +3. There are other situations... -4. Add Dockerfile if necessary +### Dev + +#### Requisites +The new architecture uses a dedicated repository to maintain all the necessary files and scripts to build Harbor in its target architecture. + +It should be able to build Harbor's master branch and push the resulting docker images to Harbor's org in `DockerHub` using the target architecture as suffix: `goharbor/harbor-core-arm64` + +#### Suggested Implementation + +**Repository structure:** + +- `Makefile`: Maintain its own list of commands to be used during the build process + +- `.github`: Maintain project workflow + +- `make`: Maintain scripts required for the project construction phase + +- `src`: Pull goharbor/harbor's master branch code logic, if necessary + +- `VERSION`: harbor-arm version number + +- `README.md`: harbor-arm readme + +- `CHANGELOG.md`: harbor-arm changelog + + +**Block Item:** +- 1. confirm harbor-arm image address. + +- 2. goharbor/harbor Developer guide. + +- 3. Harbor upgrade and pg compatibility issues. + +- 4. Can it be merged into the master branch in version 2.3? About goharbor/harbor increase the GOARCH parameter to support multi-architecture mirror construction pr. + +- 5. Harbor upgrade pg incompatibility problem. -5. Add github action files to maintain the build and test in them. The content of the github action should be modified based on the upstream github action, but it should be kept in sync at all times ### Test -We want to use the upstream test method to test, use docker-compose to deploy Harbor and then use the shell script to execute the test +#### Requisites + +It is necessary to develop an arm image test plan and an arm architecture test machine to determine whether the built harbor-arm image can run normally on the arm machine. + +#### Suggested Implementation + +We hope to be able to use the goharbor/harbor official test plan for test verification, provided that the official can provide a multi-architecture unified test plan. However, there are currently the following issues that need to be resolved @@ -76,48 +118,60 @@ However, there are currently the following issues that need to be resolved 2. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. +**Block Item:** +- 1. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. -### Image strategy +- 2. Can harbor officials provide official test solutions and support different architecture modes? -#### Repository +- 3. arm test machine problem. -The image will be hosted under the goharbor project of Docker Hub -#### Tag +### Alpha release -Add the architecture name after the generated image version. For example： goharbor/harbor-core:v2.2.1-arm64 +#### Requisites +Requires upstream goharbor/harbor to support GOARCH parameters to build harbor binary files and downstream harbor-arm to replace GOARCH parameters to build harbor-arm images and push them to Harbor's org in `DockerHub`. -### Related Implementation +#### Suggested Implementation -There are already some PRs and repository that have implemented this function, we can make full use of these contents +- 1. harbor-arm repo executes local build tasks regularly, pulls goharbor/harbor's master branch code, if there is an update, executes local build logic to update the image version. -Changes provided by this [PR](https://github.com/goharbor/harbor/pull/13788) can build amd64 and arm64 image simultaneously -This repository https://github.com/querycap/harbor have created arm64 and amd64 image successfully +- 2. After the successful build, the harbor-arm repo will update the documents such as `changelog.md` and `readme.md`. -## Development Iteration +### Beta release -After several iterations, we need to ensure that the content in adapter.sh and github actions files in downstream repository is as small as possible，After each iteration, more code can be extracted and merge to upstream。 +#### Requisites -After the adapter.sh and github actions files of the downstream code disappear, we can no longer maintain the downstream repository. +After the harbor-arm architecture image has been running stably for a period of time (for example, 2 months), the harbor-arm can consider upgrading the image to the beta version based on the modified version +#### Suggested Implementation +... -## Release +### Ultimate goal -When the goharbor/harbor is released, check out the same release branch under the downstream repository, and check the corresponding commit in git Submodules, execute the pipeline to generate the corresponding image and push it to the docker hub +The harbor-arm sub-project is accompanied by the iteration of the goharbor/harbor, and finally hopes to be able to support the support of harbor multi-architecture image in the goharbor/harbor project, thus discarding the harbor-arm sub-project. -Readme.md or release notes needs to be updated in different branches to inform the images related information, such as location and corresponding tags +### Related Implementation +There are already some PRs and repository that have implemented this function, we can make full use of these contents -## Notify Users +Changes provided by this [PR](https://github.com/goharbor/harbor/pull/13788) can build amd64 and arm64 image simultaneously -We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link. +This repository https://github.com/querycap/harbor have created arm64 and amd64 image successfully -## Block Item +## Development Iteration + +After several iterations, we need to ensure that the content in adapter.sh and github actions files in downstream repository is as small as possible，After each iteration, more code can be extracted and merge to upstream。 + +After the adapter.sh and github actions files of the downstream code disappear, we can no longer maintain the downstream repository. + + +## Notify Users + +We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link. -1. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. \ No newline at end of file From f4cb2ad4c9b4bcd9e1a6a1630550be5df9772407 Mon Sep 17 00:00:00 2001 From: Jeremy-boo Date: Thu, 29 Apr 2021 14:58:43 +0800 Subject: [PATCH 5/5] update proposal for multi arch --- proposals/new/multi-arch.md | 98 +++++++++++++++++++++---------------- 1 file changed, 55 insertions(+), 43 deletions(-) diff --git a/proposals/new/multi-arch.md b/proposals/new/multi-arch.md index 60d03210..6c344520 100644 --- a/proposals/new/multi-arch.md +++ b/proposals/new/multi-arch.md @@ -20,6 +20,13 @@ In order to provider a **short-term** and **long-term** process to introduce and ### Overview +| **Level** | **Description** | **Goals** | **Challenges** | +| :----: | :----: | :----: | :-----: | +| Dev | Introduce a new architecture into the ecosystem as independent repo and images | - Build the upstream's master branch code
- Introduce development practices | - Build platform and code
- Upstream changes trigger downstream build | +| Test | Uses Harbor's standard testing procedures to test the new architectures version | - Validate the new architecture's artifacts making sure it conforms to Harbor's standard test suite
- Ensure upstream master code have at least a daily build and test | - Infrastructure to deploy and run tests | +| Release | - Infrastructure to deploy and run tests | - Make sure release candidates and other release builds on upstream can execute successfully on downstream
- Run release tests in the new architecture |- Sync with Harbor release timing| + + #### Glossary Upstream: github repository go-harbor/harbor @@ -31,6 +38,31 @@ For example, in harbor-arm, we can maintain the construction logic of arm64 mirr Long-term: Harbor-arm keeps the synchronization update with goharbor/harbor. When goharbor/harbor updates a version, harbor-arm follows the update and then pushes the mirror image to the mirror warehouse to provide users with multi-architecture support. + + +#### Risk + +Upstream modifications may affect downstream construction + +1. Upstream changed the Dockerfile. + +2. Upstream changed the build dependency package. + +3. Changes in architecture: Removing or adding new components? + +4. Any compatibility braking changes + +5. other situations + +### Dev + +#### Requisites +The new architecture uses a dedicated repository to maintain all the necessary files and scripts to build Harbor in its target architecture. + +It should be able to build Harbor's master branch and push the resulting docker images to Harbor's org in `DockerHub` using the target architecture as suffix: `goharbor/harbor-core-arm64` + +#### Suggested Implementation + #### Jobs For Upstream 1. Increase the environment variable GOARCH, the default is amd64, which can be overridden by specifying a specific value during execution, like arm64 and so on. @@ -55,24 +87,6 @@ Long-term: Harbor-arm keeps the synchronization update with goharbor/harbor. Whe 4. Add Dockerfile if necessary -#### Risk -Upstream modifications may affect downstream construction - -1. Upstream changed the Dockerfile. - -2. Upstream changed the build dependency package. - -3. There are other situations... - -### Dev - -#### Requisites -The new architecture uses a dedicated repository to maintain all the necessary files and scripts to build Harbor in its target architecture. - -It should be able to build Harbor's master branch and push the resulting docker images to Harbor's org in `DockerHub` using the target architecture as suffix: `goharbor/harbor-core-arm64` - -#### Suggested Implementation - **Repository structure:** - `Makefile`: Maintain its own list of commands to be used during the build process @@ -89,24 +103,31 @@ It should be able to build Harbor's master branch and push the resulting docker - `CHANGELOG.md`: harbor-arm changelog +**Harbor-SubProject Image Tag:** + +The harbor sub-project will use the same Harbor's org address as goharbor/harbor, and distinguish them by different tags + +like harbor-arm: `goharbor/harbor-core:v2.1.3-arm` -**Block Item:** -- 1. confirm harbor-arm image address. +tips: Wang Yan will provide credentials inside Goharbor's DockerHub org -- 2. goharbor/harbor Developer guide. -- 3. Harbor upgrade and pg compatibility issues. +**Dev possible blocking Item:** -- 4. Can it be merged into the master branch in version 2.3? About goharbor/harbor increase the GOARCH parameter to support multi-architecture mirror construction pr. +- 1. Harbor components compatibility issues. Postgres database compatbiility when changing version making an upgrade rollout impossible. -- 5. Harbor upgrade pg incompatibility problem. +- 2. Build process for new architecture. + +- 3. Possible necessary upstream Makefile changes. ### Test #### Requisites -It is necessary to develop an arm image test plan and an arm architecture test machine to determine whether the built harbor-arm image can run normally on the arm machine. +1. Harbor standard conformance testing in the new architecture. + +2. Different harbor images need to provide machine support of different architectures. #### Suggested Implementation @@ -118,42 +139,33 @@ However, there are currently the following issues that need to be resolved 2. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. -**Block Item:** +**Test possible blocking items:** - 1. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests. -- 2. Can harbor officials provide official test solutions and support different architecture modes? +- 2. Test machine problem. -- 3. arm test machine problem. +- 3. Executing deployment and testing automatically either daily or with each upstream master commit -### Alpha release +### Release #### Requisites -Requires upstream goharbor/harbor to support GOARCH parameters to build harbor binary files and downstream harbor-arm to replace GOARCH parameters to build harbor-arm images and push them to Harbor's org in `DockerHub`. +Requires upstream goharbor/harbor to support GOARCH parameters to build harbor binary files and downstream harbor-multi sub-project to replace GOARCH parameters to build harbor-multi-Architecture images and push them to Harbor's org in `DockerHub`. #### Suggested Implementation -- 1. harbor-arm repo executes local build tasks regularly, pulls goharbor/harbor's master branch code, if there is an update, executes local build logic to update the image version. - +- 1. harbor-multi sub-project repo executes local build tasks regularly, pulls goharbor/harbor's master branch code, if there is an update, executes local build logic to update the image version. -- 2. After the successful build, the harbor-arm repo will update the documents such as `changelog.md` and `readme.md`. +- 2. After the successful build, the harbor sub-project repo will update the documents such as `changelog.md` and `readme.md`. +- 3. Sync with Harbor release timing. -### Beta release - -#### Requisites - -After the harbor-arm architecture image has been running stably for a period of time (for example, 2 months), the harbor-arm can consider upgrading the image to the beta version based on the modified version - -#### Suggested Implementation - -... ### Ultimate goal -The harbor-arm sub-project is accompanied by the iteration of the goharbor/harbor, and finally hopes to be able to support the support of harbor multi-architecture image in the goharbor/harbor project, thus discarding the harbor-arm sub-project. +The harbor-multi sub-project is accompanied by the iteration of the goharbor/harbor, and finally hopes to be able to support the support of harbor multi-architecture image in the goharbor/harbor project, thus discarding the harbor-multi sub-project. ### Related Implementation