sysbox VS crc

You are probably referring to Sysbox (https://github.com/nestybox/sysbox), which I believe will meet your requirements (systemd, inner containers, security, etc).

Btw, Sysbox is already supported in Docker-Desktop (business tier only), so you can easily do what you want with this instruction:

$ docker run -it --rm -e SYSBOX_SYSCONT_MODE=TRUE nestybox/ubuntu-focal-systemd-docker:latest bash

Disclaimer: I'm Sysbox's co-creator and currently working for Docker.

One project in this space that looked quite promising to me is sysbox[0]. I've used them once for a gitlab runner set-up similar to what is described in their blog[1].

It's currently working great and I have not had any major crashes/incidents for at least the past 8 months.

[0]: https://github.com/nestybox/sysbox

[1]: https://blog.nestybox.com/2020/10/21/gitlab-dind.html

Today, things are very different. Docker-in-Docker has a more secure and safe approach with rootless containers and freemium tools like sysbox. Tools like sysbox let you run Docker-in-Docker without the -privileged flag and optimizes specific scenarios, like running multiple nodes of a Kubernetes cluster as ordinary containers.

Right now I am going with sysbox rootless containers. https://github.com/nestybox/sysbox

We’ve been using Sysbox (https://github.com/nestybox/sysbox) for our Buildkite based CI/CD setup, allows docker-in-docker without privileged containers. Paired with careful IAM/STS design we’ve ended up with isolated job containers with their own IAM roles limited to least-privilege.

A good alternative to the VM approach is to use Kubernetes + Sysbox (a next-gen "runc", free, open-source).

But nowadays there is an option to run such software in containers securely. It's called Sysbox, and it's a new "runc" (the piece of software that creates the containers). I am one of the developers, so I am biased, but I think you'll find it helpful.

The issue is currently being worked on here is the link with the workaround.

Yessss . Just incase Git hub releases: https://github.com/crc-org/crc/releases

You can try running https://github.com/crc-org/crc with the podman preset (!) to test it. It would not be exactly the same how podman machine will use it eventualky, but might help to give an idea of performance or issues we can imorove on first. We have seen a lot of users being more than content as it also works in a vpn environment. Note that the CRC tool primarily aims at OpenShift deployment... This is a different preset (resource intensive). Only available as an installer with our tray (sorry about this).

The driver we use is https://github.com/crc-org/vfkit and I am sure Christophe could share a method to just run the VM with our driver. HMU by email if you prefer.

CodeReady Containers which allows you to spin up a reduced OpenShift node in a single VM on a desktop/laptop for getting familiar with the platform. It disables quite a few operators so it's not a full experience, but enough for a developer to get going. It doesn't have the lightest requirements but it works for the most part. By default it's recommended to have 4 cores, 12GB of memory and the disk expands to 35GB. These can be tweaked through the setup, though.

I'm having issues as described in https://github.com/code-ready/crc/issues/2945

GitHub - code-ready/crc: Red Hat CodeReady Containers is a tool that manages a local OpenShift 4.x cluster optimized for testing and development purposes

Appears to be possible but definitely more on the DiY side. https://github.com/code-ready/crc/issues/2480