-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
added multi arch images builds support for make file #2611
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2611 +/- ##
=======================================
Coverage 95.73% 95.73%
=======================================
Files 216 216
Lines 9588 9588
=======================================
Hits 9179 9179
Misses 336 336
Partials 73 73
Continue to review full report at Codecov.
|
59b3b49
to
58c6a9b
Compare
@Ashmita152 would you like to take a look and review this PR? |
Hi @jpkrohling sure I will try this PR today. |
# run a local registry for base images push | ||
# have to do this for multi-arch images | ||
# multi arch images could not --load | ||
docker run -d -p 5000:5000 --name registry registry:2 |
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 not sure but I'll prefer to push the base image to dockerhub under our organisation instead of starting our own docker-registry in every CI/CD run. That will remove all localhost:5000 too.
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. I'm actually wondering if we need docker buildx
at all, given that buildah
can also generate multi-arch images:
https://www.youtube.com/watch?v=SYJgkkjqd7s
From what I understand, we don't need qemu or a virtual machine to perform the build, given that we can produce our binaries for the target architectures anyway...
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.
@Ashmita152 CI could be enhanced in next.
- We need
make create-baseimg-debugimg
before other images build.- here is a important port. docker images in host can not store multi-arch image, but a registry could. (why we need to push base images to somewhere)
- Now in ci, no access to docker.io/jaegertracing for PR. May publish base images in other ci job
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.
@jpkrohling need to research for this.
Without qemu
, RUN apk add ca
may not be executable.
Means the base images will not be created.
it could be upgrade in future once this ready containers/buildah#1590.
Now I think we have to use buildx
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.
Right, forgot about the RUN apk add ca
command. Other than that, it would just work, right?
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.
it may cause a secure issue in PR
Why would it? We should have those as secrets in Travis and they are suppressed from the output in the CI.
seems Docker username & password not provided for PR
If you set the appropriate env vars in the Travis job for your fork, it should work. You'd have to override the namespace, so that it won't attempt to push to docker.io/jaegertracing/all-in-one
, but quay.io/youraccount/all-in-one
.
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.
Why would it? We should have those as secrets in Travis and they are suppressed from the output in the CI.
But i could create some PR and just added some docker push
to overwrite published images of docker.io/jaegertracing
. it not set, the PR may not pass bacause of base image pushing failed.
So I prefer use a local registry
as the said https://github.com/docker/build-push-action#local-registry
for testing purposes, like PR testings.
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.
Or could we create another namespace docker.io/jaegertracing-dev
or quay.io/jaegertracing-dev
docker.io/jaegertracing
only for master branch
docker.io/jaegertracing-dev
for testing of PRs or other branches.
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.
You'd still have to override the namespace to jaegertracing-dev
... So, at least for now, you can override to your Dockerhub/Quay namespace.
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.
in my fork i could override to my Dockerhub/Quay namespace.
but in PRs of jaegertracing
, need namespace jaegertracing-dev
to receive images from PRs.
Without a local registry. base images need to pushing to Dockerhub/Quay in PRs.
One thing I noticed that if we run
Reference: https://docs.docker.com/buildx/working-with-buildx/#set-buildx-as-the-default-builder Thought it would be interesting. |
This feature is for local switch for different projects. Flags of
|
is any plan about this? if you don't want to mv to buildx by default. we could refactor Makefile like this https://github.com/kiali/kiali/blob/master/make/Makefile.container.mk#L54-L61 For local registry in CI, we could split the base images publishing to another CI workflow. |
I refactor again. only change is the final publishing # build all binaries for multi-arch
make build-binaries-linux-archs # enable BUILDX_PUSH=true to switch buildx and build && push for multi-arch
DOCKER_NAMESPACE="jaegertracing" make dockerx-push For multi namespace or multi tags, we could (in another PR) updates all
Then we could just run
|
92a485d
to
ee921d2
Compare
a341799
to
66a4599
Compare
Makefile
Outdated
@@ -390,6 +405,10 @@ docker-push: | |||
docker push $(DOCKER_NAMESPACE)/jaeger-$$component ; \ | |||
done | |||
|
|||
.PHONY: dockerx-push | |||
dockerx-push: setup-buildx-builder | |||
BUILDX_PUSH=true $(MAKE) docker-images-only |
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.
Var before command becomes env var, after command it becomes make var. Do you want $(MAKE) docker-images-only BUILDX_PUSH=true
?
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.
env var could overwrites make var BUILDX_PUSH
when define with ?=
.
will same as $(MAKE) docker-images-only BUILDX_PUSH=true
.
i will update this for style.
TARGET_ARCHS ?= amd64 arm64 | ||
|
||
BUILDX_PUSH ?= false | ||
DOCKER_BUILD ?= docker build --build-arg=TARGETARCH=$(GOARCH) |
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.
TARGETARCH is defined here but not in L76. How does it work, especially if the default value is removed from all Dockerfiles?
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.
Also, wouldn't this line be immediately evaluated with the current value of $(GOARCH) ?
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.
TARGETARCH is a platform args, which will be auto pass to Dockerfile when we use buildx.
https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope
nope. here not use :=
, so $(GOARCH)
as a ref value, will be evaluated when $(DOCKER_BUILD)
used.
Makefile
Outdated
DOCKER_BUILD = DOCKER_CLI_EXPERIMENTAL="enabled" docker buildx build --builder=jaeger-builder --push $(foreach arch,${TARGET_ARCHS},--platform=linux/${arch}) | ||
endif | ||
|
||
# make sure variables could pass to includes |
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.
what is the meaning of this 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.
make sure sub makefiles could use the make variables defined in root makefile
.
how about this?
91f3ec0
to
f3e27fe
Compare
are these warnings expected? https://github.com/jaegertracing/jaeger/pull/2611/checks?check_run_id=1483365080#step:11:375 |
This doesn't look good either, pulling all-in-one while trying to build it (cc @Ashmita152 ) |
@@ -390,6 +405,10 @@ docker-push: | |||
docker push $(DOCKER_NAMESPACE)/jaeger-$$component ; \ | |||
done | |||
|
|||
.PHONY: dockerx-push | |||
dockerx-push: setup-buildx-builder |
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 a WIP? The all-in-one build is only doing amd64, I assume because BUILDX_PUSH=false by default. Wouldn't we want x-platform build to be the default, rather than having a separate target?
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.
all-in-one
is not in make docker
, so i haven't add it in make dockerx-push
now all-in-one
split into another job.
we could do all-in-one
next to support multi-arch
just because there is no |
@@ -63,8 +63,8 @@ repo=jaegertracing/all-in-one-debug | |||
docker build -f cmd/all-in-one/Dockerfile \ | |||
--target debug \ | |||
--tag $repo:latest cmd/all-in-one \ | |||
--build-arg base_image=localhost/baseimg:1.0.0-alpine-3.12 \ | |||
--build-arg debug_image=localhost/debugimg:1.0.0-golang-1.15-alpine \ |
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.
fixed #2611 (comment)
we may move this into makefile too.
this part is not easy to maintain when base image updates (cc @Ashmita152)
no idea why es testing failed. |
739170c
to
76d9a7c
Compare
Sharing something I've read this weekend: https://carlosbecker.com/posts/multi-platform-docker-images-goreleaser-gh-actions/ |
with it will be more complex for publishing workflow, especially publishing after migrated github actions, setup buildx will be very easy |
a2f6c04
to
6fedb81
Compare
Signed-off-by: Morlay <[email protected]>
Signed-off-by: Morlay <[email protected]>
waiting for a little long. I have to setup workflow to release most versioned jaeger images with some hacks |
Any update on this ? |
Yes, I think we should close this in favor of #2948, which is about to be merged. |
Signed-off-by: Morlay [email protected]
Which problem is this PR solving?
Short description of the changes
make build-binaries-linux-archs
for all binaries for multi archdocker build
todocker buildx build
for jaeger imagesTARGETARCH
local run(need buildx installed)
images https://hub.docker.com/u/querycapjaegertracing
upstream
cassandra
not provides390x
image, so now justamd64 & arm64
first.This PR should
make docker
and current ci flow. (switch to buildx but still build for amd64 only)Next PRs will add
make docker-images-all-in-one