Rework docker images build

[yhabteab]

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-icinga2 repository. The previously used Dockerfile has been renamed to Containerfile and 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 build command. Instead, the source code is bind mounted into the container at build time, more importantly
it 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 readonly into 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:

• There's now no intermediate locations for the config files, they are placed directly into the /data directory 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 a icinga2 node setup command if needed. This also means that users can now simply mount their own configuration files into the /data without any issues.
• Since most of the issues in the legacy repository are about mounting issues or missing necessary env variables to additionally configure the container, this PR effectively removes the need for most of them. The only required environment variables are the ones that are already supported and documented in the docker-icinga2 repository. If a user wants to configure the container further, they can simply mount their own configuration files into the /data directory.

This PR also includes a For-Container.md file 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 the README.md file in the docker-icinga2 repository.

Note: Commits from 5cd9ab2...20f28ec are cherry-picked from the Icinga DB repository.

See pushed images on Docker Hub.
See pushed images on GHCR.

[Al2Klimov]

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)

[yhabteab]

It doesn't work with Docker Desktop on M3:

Is not architecture specific :) but thanks anyway for testing! I was thinking /usr/lib/icinga2/prepare-dirs would actually fix all Icinga 2 related directories but not its only purpose is to fix the /var/run, /var/cache etc. directories. With the last commit it should work normally now.

**

OP addressed review

[yhabteab]

Sorry, for the force pushes! Just wanted to test the concurrency rules! I won't push anything now unless someone says otherwise.

[yhabteab]

Just rebased it and changed the CMake build type flag from ReleaseWithDebInfo -> RelWithDebInfo.

[yhabteab]

What exactly do you mean by the same thing?

Same thing as they constantly push that file to docker hub on every push to the main branch.

I've just noticed that I already changed that as your requested https://github.com/Icinga/github-actions/pull/8/files#diff-08d154f5dd3b5d03f02345316d0fe31c3e57b8e7d2125c6f6520cb9de447fd74R193 🤦‍♂️

[julianbrost]

For Icinga DB, the changes were merged just a few days before the new version was released.

In general, my question aim towards getting a better overview over all the changes to have a foundation for deciding what the best merge strategy for this change would be.

So that's basically part of the question if merging this PR should be tied to some release schedule or not.

[julianbrost]

Soft approval: change-wise this PR is fine for me, but I'm not formally approving it as I don't want it merged just yet until:

• There's positive feedback from @jschmidt-icinga that the the build args in the current state work for his use case.
• We've agreed on how we want to release this.

Regarding the latter, my suggestion would be as follows:

1. Merge this PR.
2. Subsequently, announce upcoming changes to our Icinga 2 container images, with the current snapshot builds under the edge tag being a preview (blog post anyone?)
3. Maybe keep the last master-tagged image for 2-4 weeks, so that any users have time to switch over, but then remove it so that anyone who tries to pull from it notices its gone. (Note: users includes icinga-testing)
4. Ensure that Icinga/github-actions#8 is merged before the next step (until then, merge order isn't relevant).
5. Eventually, release Icinga 2.16.0 based on the new build process.
6. For the time being, keep the builds for 2.15.x (and earlier) using the existing build process. Switching that over can then be considered at a later point.

[jschmidt-icinga]

I've tested this with my workflow and everything works as expected. I'm able to mount my (partial) config directories into the container, certs are writable and while I would have liked to have CMAKE_CXX_FLAGS as an arg, I can live without it for now.

[yhabteab]

Wait 😞! Just noticed that I'm installing boost-dev libraries in the final image as well.

[yhabteab]

Too much copy-pasted from the previous build steps. The final image installs the non-dev version of the boost libraries now and removes the superfluous boost-test library as well.

[julianbrost]

First attempt failed because this repo didn't yet have access to the renamed token secret. I've allowed the repo to access the secret and restarted the job.

[julianbrost]

Now it ran successfully and there are docker.io/icinga/icinga2:edge (or just icinga/icinga2:edge) and ghcr.io/icinga/icinga2:edge as intended. 🎉