473001be55
* vpn: ship our own container image The container image used in the VPN chart should be reproducible and stable. We're sticking close to the original nixery.dev version by building the image with nix ourselves, and then publishing the single layer from the result with Bazel OCI rules. The resulting image should be handled similar to s3proxy: it's built as a part of the Constellation release process and then consumed from a Helm chart in our registry. Co-authored-by: Malte Poll <1780588+malt3@users.noreply.github.com> |
||
---|---|---|
.. | ||
vpn | ||
libvirtd_base.nix | ||
README.md |
Containerized libvirt
To avoid dependency issues with the libvirt setup of the host, we provide a containerized libvirt instance. If no libvirt connection string is provided in the Constellation config file during create, this container is deployed to provide a libvirt daemon for orchestrating Constellation nodes in QEMU.
The container will listen for libvirt connections on localhost:16599
.
Connecting to the libvirt daemon running in the container and manage the deployment using virsh
run the following:
virsh -c "qemu+tcp://localhost:16599/system"
Container image
Update the base image (ghcr.io/edgelesssys/constellation/libvirtd-base
):
nix build .#libvirtd_base
cat result | gunzip > libvirtd_base.tar
crane push libvirtd_base.tar ghcr.io/edgelesssys/constellation/libvirtd-base
Push the final image to your own registry (ghcr.io/<USERNAME>/constellation/libvirtd
):
bazel run //bazel/release:libvirt_push
A container of the image is automatically started by the CLI. You can also run the image manually using the following command:
docker run -it --rm \
--network host \
--privileged true \
ghcr.io/edgelesssys/constellation/libvirt:latest