Skip to content
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

Unpack Flyway in a separate build step #150

Closed
wants to merge 1 commit into from

Conversation

TheSench
Copy link

@TheSench TheSench commented Aug 9, 2024

Adding the .tar.gz file in one layer and unpacking it in a second layer adds a lot of bloat to the image size.

Moving the unpacking and permissions to a separate build step allows the final Flyway image to be much smaller (from 627MB to 447MB on my machine).

Adding the .tar.gz file in one layer and unpacking it in a second layer adds a lot of bloat to the image size.

Moving the unpacking and permissions to a separate build step allows the final Flyway image to be much smaller (from 627MB to 447Mb on my machine).
Copy link
Author

@TheSench TheSench left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation notes:


ARG FLYWAY_VERSION

COPY --from=unpack /flyway /flyway
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

All that the original steps did was copy the .tar.gz into the container, unpack it, and set permissions on it. We can simply do all of that in a build stage and then copy the resulting files into this container to avoid the cost of the extra layers.

##################################################
# Step 1 - unpack Flyway
##################################################
FROM eclipse-temurin:17-jre-jammy
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

I originally picked this image to ensure that users were exactly the same between the build image and the production image.

Now that I look at this a second time, I see that we're not changing ownership of any files, so that shouldn't actually matter. We could use a much smaller image like alpine here, but since the actual flyway image also uses this as its base, this is more efficient from a layers-downloaded perspective because this doesn't add any additional layers that we weren't already downloading for the flyway stage.

@Barry-RG
Copy link
Contributor

Thank you for your PR. I am currently looking at a wider optimization of the docker images in Flyway and something similar to this is in the works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants