-
Notifications
You must be signed in to change notification settings - Fork 6.6k
try to enable cross build for arm64 docker image #8015
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
change base image to adoptopenjdk/openjdk11:jre, to support multiple platforms: linux/amd64 and linux/arm64
change base image to adoptopenjdk/openjdk11:jre to support multiple platforms: linux/amd64 and linux/arm64
prepare for raising pull request
# Conflicts: # Makefile # docker/oap/Dockerfile.oap
|
Could you squash your commits? It seems too many. @kezhenxu94 @hanahmily @JaredTan95 Could you take a look at this change? I am not familiar with this part of change. |
kezhenxu94
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This patch seems to be far from ready status, I think this kind of changes can be verified locally, @mis98zb
| - name: Build docker image | ||
| run: | | ||
| make docker || make docker | ||
| make docker.push || make docker.push |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder, this should not be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker buildx has an option '--push', with it docker will directly push the result docker image to the docker repository.
So as I remove this command.
However, I'm not sure if this version of docker image can be pushed to skywalking's repository.
After getting permission from your side, I'll add the '--push' option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are various repositories. Check here, https://github.com/orgs/apache/packages?repo_name=skywalking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker buildx has an option '--push', with it docker will directly push the result docker image to the docker repository. So as I remove this command.
Nice, if that's the case, we can remove this command but need to be able to switch the --push option in make command so we can build locally with pushing.
However, I'm not sure if this version of docker image can be pushed to skywalking's repository. After getting permission from your side, I'll add the '--push' option.
Yes we can push this new (arm) Docker images, with some prefixes or suffixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
And FYI, docker buildx does not add prefix or suffix on the tag...
It makes a manifest contains all specified platforms and push it to docker repository, so as one tag contains multiple architecture images.
Just like below:
TAG
11.0.11-jre
Last pushed3 months agobydoijanky
DIGEST OS/ARCH COMPRESSED SIZE
50029fa89b65 windows/amd64 5.88 GB
f416d2a5a8c2 windows/amd64 2.54 GB
ccc36e4a72d1 linux/amd64 115.02 MB
2b8329599393 linux/arm64/v8 112.8 MB
You can find this on https://registry.hub.docker.com/_/openjdk?tab=tags&page=1&name=11.0.11-jre
When docker client pull image, it will automatically choose the one with same arch as local.
Is this acceptable for skywalking?
Otherwise I can change to build one platform a time with different tags.
btw, personally I don't prefer this way... :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only working for arm? Or apply to all x86?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I used '--platform linux/arm64,linux/amd64', it is working for both x86 and arm64.
If it is needed to separate x86 and arm64, I can change the makefile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hanahmily @kezhenxu94 What do you prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am feeling at least we should separate GHA repo push(x86 only) and release docker repo(x86 and arm) for official release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushing arm Docker images to GHCR may cost some storage but it's convenient if users want to try arm Docker images, I'm OK to separate or not
|
pushed to my docker hub repository, (^0^)v https://hub.docker.com/repository/docker/mis98zb/ui/tags?page=1&ordering=last_updated both linux/arm64 and linux/amd64 are avalible. I'll have a simple test on my Raspberry Pi |
| ifeq ($(PUSH_DOCKER_IMAGE), true) | ||
| ifneq (DOCKER_REPOSITORY_TOKEN,) | ||
| DOCKER_LOGIN_CMD=docker login -u $(DOCKER_REPOSITORY_USER) -p $(DOCKER_REPOSITORY_TOKEN) | ||
| endif | ||
| DOCKER_PUSH_OPTION=--push | ||
| DOCKER_PUSH_CMD=docker push $(HUB)/$(3):$(TAG) | ||
| endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't want to have this because login can be EASILY done only once in user's PC and this is kind of out of our scope, also, requiring users to pass a secret into our script is not accepted somehow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. Let's not touch the privacy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you are right.
I add this optional login step is just because it be called by github workflow, which is run on a remote vm and I cannot login manually.
In fact, I wondered why there is no login step previously, and how does docker-publish workflow work...
if needed, I can move the login step to docker-publisher, or any other possible place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mis98zb here is how we login in workflow
skywalking/.github/workflows/publish-docker.yaml
Lines 49 to 54 in c9b28e4
| - name: Log in to the Container registry | |
| uses: docker/[email protected] | |
| with: | |
| registry: ${{ env.HUB }} | |
| username: ${{ github.actor }} | |
| password: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mis98zb Take this as a reference and remove the login step in our makefile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok.
May I know where can I set these variables?
So as I can have a test on my forked repository...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are available in your GH Action in default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok.
May I know where can I set these variables? So as I can have a test on my forked repository...
They are available by default, provided by GitHub Action. the only thing you need to do is to modify these lines to test in your forked repo (ghcr.io/apache/skywalking to ghcr.io/mis98zb/skywalking )
| HUB: ghcr.io/apache/skywalking |
| if: github.repository == 'apache/skywalking' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it.
thank you so much!!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I close this for testing on my forked repository, will reopen soon.
| - name: Build docker image | ||
| run: | | ||
| make docker || make docker | ||
| make docker.push || make docker.push |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushing arm Docker images to GHCR may cost some storage but it's convenient if users want to try arm Docker images, I'm OK to separate or not
|
docker push is still separated from build. |
|
Any update about this PR? |
|
some E2E test failed with building test docker image (not the oap/ui image). btw, the oap/ui images pushed to docker hub can work on my local docker environment... |
Of course it can. What is the issue about this? |
hehe, I mean, I've tested the pushed oap/ui images local and they started up without error. however, E2E failed with biulding test docker image. |
|
That is the point of e2e. Usually there are some pre-setup in your local env, which makes every steps working well. But running in the e2e env could expose these missing steps. |
|
E2E.java succeeded meanwhile E2E.js failed. |
|
Closing in favor of #8141 |
If this is non-trivial feature, paste the links/URLs to the design doc.
Update the documentation to include this new feature.
Tests(including UT, IT, E2E) are added to verify the new feature.
If it's UI related, attach the screenshots below.
If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
Update the
CHANGESlog.