-
Notifications
You must be signed in to change notification settings - Fork 347
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
Docker Push Github Action #83
Conversation
Testing out the make target
|
Dockerfile
Outdated
COPY . /workspace | ||
|
||
# Build | ||
RUN make build |
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 build here again but not use artifact from build and test?
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.
keeping the Dockerfile
mutually exclusive from the CI flow so a
- dev can run
make docker-build
ordocker build .
to build images and test them quickly - above flow eliminates volume mounts to share artifacts etc
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 feel this is a bad practice: we are releasing a build which is not tested in the same environment.
buildx doesn't need volume mounts anyway, it is just ADD
file?
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 disagree here, the workflow for pushing docker images would also run some form of e2e (which doesn't exist today) using the same image before pushing the image
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.
The other disadvantage of this is we are going to use QEMU for future arm64 (and other) build which is way slower and hard to workaround. It is better to split the build and docker packaging.
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.
prefer if we first tried the simpler way of building linux/arm64
using QEMU, quantified the slowness in CI, and then deleted the QEMU step in favor of a self hosted ARM runner
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 have moved over the job as a step into the main workflow, we could further optimize this logic by retagging instead of relying on the build cache layers
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 don't need even a self hosted ARM runner, Go cross compile works great without hassle, just need to copy the binary from local machine (or downloaded artifacts), instead of force docker build run Go build.
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.
cool, lets consider adding that as a follow up PR
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.
raised #93 so this conversation can continue there and can unblock this PR
See also: #89 |
* Use the buildx based GHA https://github.com/docker/buildx * Add `make` targets for docker build and push Relates to envoyproxy#75 Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
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.
One question but otherwise LGTM; re: the open threads, IMO we can always tackle later if we want, but this gets us started.
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
uses: docker/setup-qemu-action@v2 |
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 think we can drop this since we're only building a single arch now and when we add support for multi-arch images we can use Go's native cross-compilation
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.
based on the comments, added linux/arm64
to enable envoy-gateway
images to run on arm64
as well (e.g. M1 Macbooks)
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Codecov Report
@@ Coverage Diff @@
## main #83 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 5 5
=========================================
Hits 5 5 Continue to review full report at Codecov.
|
# Use distroless as minimal base image to package the manager binary | ||
# Refer to https://github.com/GoogleContainerTools/distroless for more details | ||
FROM --platform=$BUILDPLATFORM gcr.io/distroless/static:nonroot | ||
ARG TARGETPLATFORM |
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.
Suggest defaulting this arg to linux/amd64
so it just works for a regular docker build
invocation:
ARG TARGETPLATFORM | |
ARG TARGETPLATFORM=linux/amd64 |
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 will never work for a docker build .
invocation now :)
=> ERROR [2/2] COPY linux/amd64/envoy-gateway /usr/local/bin/
since the Dockerfile is only a means for packaging the binary and the binary is built on the host , relates to http://github.com/envoyproxy/gateway/issues/93
Instead we need to rely on make docker-build
now
As for TARGETPLATFORM=linux/amd64
, we dont need this, by default it picks the right value
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.
If I run make docker-build
as is, then docker run
the image, I get exec /usr/local/bin/envoy-gateway: no such file or directory
. If I add the default I suggested, then do the same, I get Manages Envoy Proxy as a standalone or Kubernetes-based application gateway
as expected.
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 is environment dependent, if you did docker buildx install
then your docker build
is buildx otherwise it's not. Though defaults to linux/amd64 doesn't do right thing for M1 mac users whose docker is linux/arm64.
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.
Actually, set environment DOCKER_BUILDKIT=1 in the Makefile should make thing work? @skriss
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.
Yep, understood, was just trying to have this work OOTB for the most environments. Since you're against the default, let's document the buildx
requirement in https://github.com/envoyproxy/gateway/blob/main/CONTRIBUTING.md.
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
xref #63 |
make
targets for docker build and pushRelates to #75
Signed-off-by: Arko Dasgupta arko@tetrate.io