Add development container for usage with Podman #317
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch adds a development container for usage with Podman.
This new container provides a few improvements compared to the already
existing one:
The new container image is based on the official Debian Bullseye image
in the slim variant. The existing container is using a three years old
image based on Debian Stretch.
The new container image only contains a minimal set of Debian packages
which are needed to run ELBE from the Git sources.
The container image has a size of 329 MB.
The already existing image has a size of 1.15 GB.
To build and run the container image / instance Podman is used. The
main reason to switch from Docker to Podman - in this case - is the
usage of systemd inside the container.
With Docker it is not that easy to run systemd in a container. This
can be seen at the already existing container.
With Podman it is very easy to achieve this.
See
https://developers.redhat.com/blog/2019/04/24/how-to-run-systemd-in-a-container
for detailed information.
Right now there is one downside of the new container: the container
instance is started as rootful container in privileged mode.
Podman's rootless mode cannot be used, because the CAP_SYS_ADMIN
capability is needed which is only granted in rootful mode.
The privileged mode is used right now, because I wasn't able the create
and use an initvm without it. Dumb copying of the security settings
from the existing container was not working unfortunately.
This is something which should be optimized in the future.
Signed-off-by: Daniel Braunwarth [email protected]