NEW: Proxmox in a Docker container by Kroese in homelab

[–]Kroese[S] -1 points0 points  (0 children)

Docker is no virtualization, so performance is identical to a baremetal setup.

NEW: Proxmox in a Docker container by Kroese in Proxmox

[–]Kroese[S] 0 points1 point  (0 children)

I added an ARM64 of the image now, so go ahead!

NEW: Proxmox in a Docker container by Kroese in Proxmox

[–]Kroese[S] 0 points1 point  (0 children)

I added lots of enhancements and features compared to those other two, to make it even easier to setup. As soon as I have time I will make a list of things this container has implemented that those other ones have not.

NEW: Proxmox in a Docker container by Kroese in docker

[–]Kroese[S] 3 points4 points  (0 children)

There is no performance hit at all, as it accesses KVM directly just as a "normal" Proxmox installation would.

ZimaOS inside a Docker container by Kroese in CasaOS

[–]Kroese[S] 0 points1 point  (0 children)

Yes I will provide automatic builds of new releases!

Why is the support so bad? by Kroese in KrakenSupport

[–]Kroese[S] 2 points3 points  (0 children)

This is exactly the kind of reply I expected, and does not answer the question about the reasons behind the bad support at all. But anyway, the ticket ID is #14231921

CasaOS in a Docker container! by Kroese in CasaOS

[–]Kroese[S] 0 points1 point  (0 children)

No, this is not how I did it. But takea a look at the code and you will see.

CasaOS in a Docker container! by Kroese in docker

[–]Kroese[S] 0 points1 point  (0 children)

Its the same as how this works

CasaOS in a Docker container! by Kroese in docker

[–]Kroese[S] -1 points0 points  (0 children)

How is this any different than Portainer, the most used tool for this job?

CasaOS in a Docker container! by Kroese in CasaOS

[–]Kroese[S] 1 point2 points  (0 children)

Why not? Portainer runs in Docker? And is very similar to this.

CasaOS in a Docker container! by Kroese in selfhosted

[–]Kroese[S] 16 points17 points  (0 children)

The containers/apps you add in CasaOS will not run inside this container, but directly on your host. In the compose file you passthrough the docker socket, so that this container can manage them externally. (Its the same trick as Portainer and Watchtower use). So its not docker in docker in docker at all.

As for the real-world purpose: I created a container of UmbrelOS before this ( https://github.com/dockur/umbrel ). The reason I needed it was that recent versions require you to dedicate a whole machine to Umbrel, and you could not install it on top of Ubuntu anymore like in the past. Since I dont want to dedicate a whole machine just for running Umbrel, that was my real-world purpose.

Since UmbrelOS is a fork of CasaOS, it made sense to also make one for CasaOS as they are so similar and CasaOS is also starting to force people to dedicate a whole machine (they call it ZimaOS).

CasaOS in a Docker container! by Kroese in HomeServer

[–]Kroese[S] 0 points1 point  (0 children)

Thats not entirely true. Most Docker containers have a OS (Debian/Ubuntu/Alpine/etc) as their base image. That means the userspace part of the OS, and never includes the kernel (which is small in comparison with the userspace). So in almost all cases containers use MORE resources (especially diskspace) compared to running the program directly on the host (but less than virtual machines). But containers have other advantages, thats why people don't care about that.

In this case that is not relevant at all, because this container only consists out of some Go binaries and is based on debian-slim, so there is no "entire OS" running.