Rework docker images build #10505
Rework docker images build #10505
Conversation
There was a problem hiding this comment.
Note: Commits from 5cd9ab2...20f28ec are cherry-picked from the Icinga DB repository.
Instead of copying all of this into this repository, have you considered creating a dedicated action for it that can be included using something like uses: Icinga/build-and-upload-container-image which could then be shared between all our projects?
There was a problem hiding this comment.
As we already talked about this last week, AFIA Jolien is working on something similar to deduplicate such GHAs in a central repository, but I think @lippserd can say more about this, so I didn’t even try to do this yet.
There was a problem hiding this comment.
We are currently in the process of creating common PHP workflows. It wouldn't overcomplicate things now and just keep the cherry-picked commits.
There was a problem hiding this comment.
How does it overcomplicate things? The current docker-icinga2 repo does that, i.e. we know how to do this so I wouldn't expect this to be a big deal. Once this is also included in support/* branches, making changes will be even more annoying.
There was a problem hiding this comment.
How does it overcomplicate things?
He didn't say that it would overcomplicate things but it wouldn’t for now, so keeping the cherry-picked commits for now. At least that’s how I understood the comment.
There was a problem hiding this comment.
How does it overcomplicate things?
He didn't say that it would overcomplicate things but it wouldn’t for now, so keeping the cherry-picked commits for now. At least that’s how I understood the comment.
Yes, I had no intention of never doing it, just not now.
There was a problem hiding this comment.
"Just not now" as in "not as part of this PR" or "keep it in this PR until we are generally happy with the general state of the PR and then create that external action as part of this PR"? (I'd lean towards the latter.)
There was a problem hiding this comment.
Personally, I would create the action after the PR has been merged. A few things still need to be checked, e.g. the naming of the steps. Also, the action should not only be used for Icinga 2 but also for Icinga DB, Icinga for Kubernetes and Icinga Notifications. I would not want to check now whether the action covers all use cases.
If it has to be done as part of this PR, then it should also be changed in the mentioned repos right away.
There was a problem hiding this comment.
It doesn't work with Docker Desktop on M3:
➜ icinga2 git:(docker-v2) docker run --rm -itv my-new-vol-4:/data -e ICINGA_MASTER=1 docker.io/icinga/icinga2:test
[2025-07-22 09:34:31] information/DockerEntrypoint: Icinga 2 Docker entrypoint script started.
[2025-07-22 09:34:31] information/DockerEntrypoint: Running Icinga 2 node setup command...
information/cli: Checking in existing certificates for common name '41c044b13034'...
information/cli: Certificates not yet generated. Running 'api setup' now.
information/cli: Generating new CA.
critical/Application: Error: Function call 'mkdir' for file '/data/var/lib/icinga2/ca' failed with error code 13, 'Permission denied'
Additional information is available in '/data/var/log/icinga2/crash/report.1753176871.799910'
/usr/local/bin/docker-entrypoint.sh: line 115: 16 Aborted icinga2 "${nodeSetup[@]}"
➜ icinga2 git:(docker-v2)
Is not architecture specific :) but thanks anyway for testing! I was thinking |
tools/container/docker-entrypoint.sh
Outdated
| "error") | ||
| color="\033[1;31m" # Red | ||
| ;; |
There was a problem hiding this comment.
| "error") | |
| color="\033[1;31m" # Red | |
| ;; |
This workflow builds and publishes container images directly from this repository. Here is a summary of its initial setup for reference: The Build and Publish Container Image workflow builds container images and pushes them to both GitHub Container Registry (GHCR) and Docker Hub. It sets up QEMU and Docker Buildx for cross-platform builds, and builds the container images using the Containerfile. Upon pushes to the main branch or when releases are published, it logs into GHCR and Docker Hub using credentials from GitHub secrets, tags and pushes the images to both registries, and generates and pushes signed build provenance attestations to each registry. The workflow also triggers for pull requests to the main branch, verifying only the image build.
Without further investigation, this only seems to push the image with the digest as a tag, which only pollutes the registry.
Use the checkout action explicitly to fetch all tags, rather than relying on docker/build-push-action's implicit checkout. This allows us to implement custom logic for tagging as 'latest' and with the appropriate major version when applicable.
…able To ensure the workflow is reusable across our repositories, it must support releasing from different release trains, such as when issuing bugfix or security releases for older versions alongside newer ones. This change introduces custom logic to determine when to apply the latest tag and major version tags. The docker/metadata-action unconditionally applies these tags, which could override existing greater tags. The new logic compares the current release tag against all existing tags using semantic versioning rules, a feature not inherently provided by docker/metadata-action.
Previously, the https://github.com/Icinga/docker-icinga2 repository was used to build the Docker images for Icinga 2. However, due to its various design flaws, the resulted images had limited usability and required a lot of manual tweaking to make something useful out of them. This commit now follows our new principles of building Docker images from the Icinga DB repository, and replaces the old separate repository with this one. It makes use of the newest Docker BuildKit features to build the images in a more efficient way, while also granting users full flexibility to easily extend or modify the images as they see fit without any issues.
This PR is similar to the changes made in the Icinga DB repository. This allows for more flexibility and consistency in building processes of the docker images as opposed to the previous method from the
docker-icinga2repository. The previously usedDockerfilehas been renamed toContainerfileand the build process has been updated accordingly to make use of the Docker BuildKit caching capabilities. This change is expected to improve the build performance and allows for better layer caching, which drastically reduces the build time for subsequent builds on local machines.As opposed to the previous behaviour, the current build process doesn't require a path to the source code to be passed
to the
docker buildcommand. Instead, the source code is bind mounted into the container at build time, more importantlyit doesn't require you to commit any changes made locally, but it simply uses the current state of the source code directory.
It's mounted as a
readonlyinto the container, so no changes can be made to the source code from within the container.Apart from that, this PR also automatically fixes various issues from the previous repository, such as:
/datadirectory at build time. This eliminates the need for subsequent initialization steps by the container entrypoint script to copy the files around. As a result, the container entrypoint script has been dramatically simplified and now only contains the necessary steps to run aicinga2 node setupcommand if needed. This also means that users can now simply mount their own configuration files into the/datawithout any issues.docker-icinga2repository. If a user wants to configure the container further, they can simply mount their own configuration files into the/datadirectory.This PR also includes a
For-Container.mdfile that contains the necessary information for users to set up the container and use it effectively. It provides a comprehensive guide on how to run the container, including the necessary environment variables, and how to mount configuration files. This file is intended to be a replacement for theREADME.mdfile in thedocker-icinga2repository.Note: Commits from 5cd9ab2...20f28ec are cherry-picked from the Icinga DB repository.
See pushed images on Docker Hub.
See pushed images on GHCR.