How does Cloudron work? What does it do? etc :)

[girish]

@jdaviescoates Thanks, file.pizza delivered! I have re-uploaded to https://videos.cloudron.io/videos/watch/206fc4b7-9641-4453-8be0-67450f2574b1

[jdaviescoates]

@girish I have a small question about this video I've been meaning to ask for ages... somewhere you mention that Cloudron uses "Linux containers" - does that basically just mean Docker? or does Cloudron also use some other form of Linux containerization too? thanks!

[nebulon]

@jdaviescoates all apps and services use docker for containerization currently. When we started, we had ideas of allow this to maybe change that, as Cloudron acts as an abstraction on top of such lower-level features. In the end so far there was no real reason for supporting other containerization methods. Also it would cause mostly unnecessary extra work for little benefit, still we try to not expose containerization specifics to apps to stay portable as much as possible for the future.

[girish]

@jdaviescoates The linux kernel has various built-in features/system calls like 'cgroups' (provides cpu/ram/resource isolation), namespaces (pid/ipc/mounts), overlay filesystem etc. These things apply to 'process'es.

'Container' is a term and not some feature of the kernel as such. It brings all the above system calls together along with bundling/packaging aspect to help create containerized "apps". Apps can be desktop UI, web apps, daemons, anything.

Docker is one implementation of the 'container' concept. When creating a implementation (just like how you design a language), you have to decide style/structure/format. We have this Dockerfile that explains how to put deps together, how to configure things, how to push the final build image to the cloud and pull down this image and deploy it on another server etc.

Other implementations exist which are in various states - rocket, OpenVZ(?), LXC, snap, containerd, cri-o off my head.

When we started, Docker was the de-facto implementation. These days there are more options and in theory we can switch to another one without affecting end users (though it's a lot of work). Also, when we started, we had no 'custom apps'. Changing the run time will break custom apps, so I think we are married to Docker until that project lives.

[girish]

Forgot to mention sandstom.io, which implements containers by itself and does not use docker.

[robi]

@girish said in How does Cloudron work? What does it do? etc :

Changing the run time will break custom apps, so I think we are married to Docker until that project lives.

That's not quite true.. remember Nestybox?
Their runtime called "sysbox" is a drop in replacement for runc which docker uses by default.

[girish]

@robi From what I remember, sysbox was like a backend to docker, it doesn't replace docker. Unlike the other things I mentioned which will replace docker.

[robi]

@girish you should take a look at it again.

[girish]

@robi Would be interesting to know what systemd-detect-virt prints for nestybox

[girish]

I just found that https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html has quite a nice list of container and vm technologies.

[robi]

@girish said in How does Cloudron work? What does it do? etc :

@robi Would be interesting to know what systemd-detect-virt prints for nestybox

That's easy to test, just change one line in the docker config or specify it on the CLI and bring up a container using sysbox, then run the tool.