Improvements to Docker file #2504
Conversation
This changes the Dockerfile quite radically, so that Openfire is built within Docker rather than outside of it. This should simplify building the image, and also make the results more repeatable. In order to maximize the use of the cache while keeping the image size under control, this uses three stages. The first stage locates and extracts all the POM files and any JAR files. This stage will be re-run on any change, but it short. The second stage takes the output of the first stage and gathers dependencies. These will be cached, unless the output of the first stage (ie, the dependency information) changes. Then it copies in the full source, and builds it. Finally, the runtime container is setup much as it was before, except that the runtime files are copied from the build stage rather than the filesystem directly. The result is that a repeat build of the docker image now takes about two minutes, but can trivially be done on any docker platform (even without Java installed locally). Notes: * The build stage should be able to run the `mvn package` in offline mode, but maven (being maven) wants to download more during this stage. * The `.dockerignore` file has of course been changed, but someone who understands Java better than I might well improve it further.
|
Thanks for this! I'm not Docker-savvy enough to review this properly. @Fishbowler @Fank can you have a look please? Assuming that this builds Openfire from source, it may be able to leverage the Maven wrapper that's part of the repository ( |
|
Oooh, another experiential one. |
I wouldn't think you'd want to try and avoid the hit there - once you start running Java, I think you want the latest possible. You could use something else for the extraction stage, but that would end up dominated by fetching the container anyway, which is why I chose to use the same one throughout. |
That looks like full cache. The better test is an arbitrary change (comment will do) in a source file, which is more typical developer experience. I imagine we could make things faster by examining which packages are changed most frequently, and see if we could cache the build for some fo the less frequently changed ones, but that seems quite complex. |
Also build skeleton runtime as a distinct stage
|
Summary of those additional commits:
TODO list, all can/should be done post-merge:
|
We could consider publishing built images via the GitHub Packages system, which can act as a Docker registry. (That doesn't seem to require additional secrets). We've experimented recently with that in this project: https://github.com/XMPP-Interop-Testing/smack-sint-server-extensions/blob/main/.github/workflows/docker.yml |
|
The more recent changes introduced a new problem: |
|
I've popped on another commit for you to look at - it's got the groups, and moves the sudo install down to the last container, as its needed for the entrypoint. I don't think there's a way to move this any earlier, unless we want to layer it? |
| echo "is_publishable_branch=true" >> $GITHUB_OUTPUT | ||
| if [[ ${{ github.ref }} == 'refs/heads/main' ]]; then | ||
| echo "is_publishable_branch=true" >> "${GITHUB_OUTPUT}" | ||
| echo "branch_tag=latest" >> "${GITHUB_OUTPUT}" |
There was a problem hiding this comment.
Would we want latest pointing at the tip of main? We consider it unstable.
Would we be better having main be main or bleeding_edge or unstable or testing or something, and work out how to match the latest release with latest?
This changes the Dockerfile quite radically, so that Openfire is built within Docker rather than outside of it. This should simplify building the image, and also make the results more repeatable.
In order to maximize the use of the cache while keeping the image size under control, this uses three stages:
The result is that a repeat build of the docker image now takes about two minutes, but can trivially be done on any docker platform (even without Java installed locally).
Notes:
mvn packagein offline mode, but maven (being maven) wants to download more during this stage..dockerignorefile has of course been changed, but someone who understands Java better than I might well improve it further.