-
Notifications
You must be signed in to change notification settings - Fork 1.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
(WIP) ✨ speed up container image builds #4289
base: master
Are you sure you want to change the base?
(WIP) ✨ speed up container image builds #4289
Conversation
Signed-off-by: Mateus Oliveira <msouzaol@redhat.com>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mateusoliveira43 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @mateusoliveira43. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
- $(CONTAINER_TOOL) buildx create --name project-builder | ||
$(CONTAINER_TOOL) buildx use project-builder | ||
- $(CONTAINER_TOOL) buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross . | ||
- $(CONTAINER_TOOL) buildx build --push --platform=$(PLATFORMS) --tag ${IMG} . | ||
- $(CONTAINER_TOOL) buildx rm project-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.
This code was added to ensure it functions as expected, specifically enabling Docker to generate images with support for all the platforms listed above. Could you confirm that everything will continue to work as intended after your changes?
To move forward, could we please add CI tests? We could create a new GitHub workflow (like build) that builds a sample, triggers this target, and verifies that the generated image supports all required platforms. What do you think? Does this make sense?
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.
sure, CI approach is good, will see how to create a test for it
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 just want to share with you that it is implemented as it is because, as far as I remember, the suggestion you are making here did not work well. So, for any changes here, we really need to properly ensure and with a CI so that we can ensure that we have no regressions.
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.
created separate PR for CI #4381
my idea is merge that one first (ensure buildx commands works in master branch), then check that this change does not break the job
what you think?
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.
Did you run it manually?
Did you check that the final image has all platforms?
If so, can you please add in the description?
Then I was thinking we might not need the CI.. we could skip that
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 can test (my primary machine does not have docker to test, but I have another one that has it) and post results
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 was the one who originally implemented this code, and I recall attempting the approach you proposed here. It didn’t work across all scenarios, which is why the solution ended up being the Dockerfile.cross.
I tried to locate the comments from the original PR (link) that explain why we use Dockerfile.cross to provide more context, but I couldn’t find them quickly. However, I’m confident that the proposed changes won’t address all requirements and could potentially break existing functionality.
For these reasons, I don’t think we should make this change.
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 found this https://github.com/hadolint/hadolint/wiki/DL3029 that would also go against these changes 😬
investigated that and the rule is only for fixed platforms
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.
So, I think we do not need to worry about make docker-buildx
command with this change. Basically this changes Dockerfile
to be equal to the Dockerfile.cross
that would be created by the command
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.
First we will need a GitHub Action to validate those changes.
So, it blocks this one.
I hope that you do not mind, I add WIP to title of the PR to clarify that it still in WIP
no problem @camilamacedo86 I am busy this week, but next week I will be able to finish this PR :) |
@@ -1,5 +1,6 @@ | |||
# Build the manager binary | |||
FROM golang:1.22 AS builder | |||
FROM --platform=${BUILDPLATFORM} golang:1.22 AS 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.
I believe we cannot proceed with these changes. If I run the build on a Mac, it won't work properly when deploying to the cluster, correct? The Dockerfile is also used for the docker-build target, so this impacts more than just docker-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.
So my intention with this change is exactly this scenario with docker-build
command
In the project I work, we build Linux images for developing, but some developers use MAC
We added this change to our Dockerfile to speed up the builds there for non Linux users
Why the changes were made
When building a container image for different arch than you are on, if
--platform=${BUILDPLATFORM}
is not inFROM
statement in Dockerfile, build will take longer.On a project I work, we build container images for testing in clusters that can either be amd64 or arm64. So, sometimes the developer is on the same arch they need to build, sometimes not.
docker-buildx
could fix the problem, but would build an unnecessary extra arch (for delivering the product, it does make sense to create all archs possible, but for developing, just building teh arch you need make developemt cycle faster).How to test the changes made
Run
docker-build docker-push
anddocker-buildx
commands and check if they still work (and are not slower).