Add ability to run VM like containers in Cloudron via Sysbox
-
-
@mehdi said in Why do we have to push an image to a registry?:
https://git.cloudron.io/cloudron/box/-/commit/546e38132510e29792323a9947ac7cdf9aa55c98
The patch is in a commit in the
masterbranch, so it will be in the next release
I only realized that after I added the patch cause I had to copy and paste from master code. I just got confused because he said "patch" - but I'm happy this is in master. I know you're a developer so it could help you too in the right scenario. And IIRC, you are one of the few that knows how to work with
boxcode. -
-
@robi said in Why do we have to push an image to a registry?:
Can't wait for Sysbox integration so you can have a dev cloudron running on any prod Cloudron in a container, completely isolated.
What, you're kidding me, that would help so much with
boxcode changes. I've been making all of my box code changes insshviananoand...well, that method leaves something to be desired with how many changes all the files went through.It's this "Sysbox integration" planned? Still not sure exactly what Sysbox is, but if it allows me to contribute more easily to Cloudron
boxcode, I'M INNNN!!! -
Yes, I posted about it.
-
It is not planned, I believe, as the devs have not given their opinion in the matter.
Also, one could technically already create a Cloudron-in-cloudron app today. The limit is not the containers, as you can run docker-in-docker. The limit is that it would be an infrastructure nightmare, like which cloudron should expose which ports on the main public IP, and such. Sysbox would not help at all in this matter.
-
I do not think Cloudron should move to Sysbox.
- It is not necessary for cloudron apps to run "full systems" instead of just an app inside the container. I do not see any usecase for this
- ~350 github stars vs ~7300 => it's less maintained, there's less community : let's stick to the regular runc everyone uses, it will be easier to solve problems when they arise
-
@mehdi said in Add ability to run VMs in containers in Cloudron via Sysbox:
The limit is that it would be an infrastructure nightmare, like which cloudron should expose which ports on the main public IP, and such.
Well, running Cloudron inside of Cloudron as an app would just massively speed up development. That would be my only reason, so
wouldn't care at all about security. Just development speed. -
@robi What does sysbox allow for beyond @mehdi's suggestion of just adjusting Cloudron itself into having the ability to be inside it's own container - which for me would allow for box code contributions to use the same development flow as my app development flow - so I'd contribute more to the project, given it is open-source.
I don't think I'd need something like Sysbox if that's all I want it for, right?
-
Yeah, I reread this and I see sysbox of just being needless overhead when Cloudron can just be adapted as an app (to easier develop on, it the developers ever alright that). Reminds me of the whole "you can only emulate the Apple OS on Apple Hardware" thing. But it would be cool if I could alter Cloudron a little bit to give it the ability to run inside another Cloudron. The dev benefits alone, so much more speedy for box changes. At least for external contributors. I don't have a build flow for
boxso if we're ever able to use our normalcloudron updatefor it, I'll be contributing a lot more to this project with feature forks. -
Who doesn't want strongly isolated containers without having to run actual VMs?
Nestybox empowers containers to act as virtual servers capable of running the same workloads as VMs (e.g., Systemd, Docker, Kubernetes, and even legacy apps).
Currently this requires unsecure privileged containers plus complicated Docker images with tricky entrypoints and custom volume mounts.
No more.
Nestybox enables you to do this using:- Simple Docker commands
- Simple Docker images
- Strongly Isolated Containers
- No Hardware Virtualization (VMs)
Use Cases:
Kubernetes-in-Docker- Running Kubernetes clusters inside containers is very useful for development, testing, and CI/CD.
- It avoids the need for heavy and costly VMs or cloud-based clusters.
- There exist a few tools to run Kubernetes-in-Docker. However these use complex container images and very unsecure privileged containers.
- Nestybox fixes this, enabling you to deploy the cluster in containers using strong isolation and very simple container images that you fully control.
Lightweight VM
- Sysbox makes it easy to use containers as lightweight VMs. For example, a container image can include systemd, ssh, a Docker daemon, preloaded inner container images, etc. You have full root access inside the container, but no capabilities outside of it.
- You can pack 2x as many containers as VMs on the same machine and get the same performance. And you can provision them 10x faster than VMs.
Docker-in-Docker
- It's often useful to run Docker inside a container for development, testing, and CI/CD.
- Up to now, the only way to do this was to use very unsecure privileged containers or exposing the host's Docker socket into a container. Neither is ideal.
- Nestybox removes these limitations, enabling you to run Docker inside a container with total isolation from the host.
- You can even preload inner container images into the outer container using a Dockerfile or Docker commit.
Legacy Apps
- With Nestybox, legacy apps may be lift-and-shifted into containers, enabling them to operate within cloud-native frameworks without resorting to VMs. This voids the need for re-architecting such applications.
-
-
-
-
-
