As a happy user of coolify, what’s the difference between these two?
Even coolify lets you add as many machines as you want and then manage docker containers in all machines from one coolify installation.
Uncloud - Tool for deploying containerised apps across servers without k8s
41–50 of 189 posts
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#42Earlier quoted context omitted.
Thank you for the suggestion! I’m working full time on this, yes. Funding from my savings at the moment and don’t have plans for any external funding or VC. For monetisation, considering building a self-hosted and managed (SaaS) webUI for managing remote clusters and apps on them with value-added PaaS-like features.
That sounds interesting, maybe I could help on the business side of things somehow. I'll email you my calendar link.
Awesome, will reach out!
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#43Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…
haha, uncloud does have a control plane: the mind of the person running "uc" CLI commands
> I’m building Uncloud after years of managing Kubernetes
did you manage Kubernetes, or did you make the fateful mistake of managing microk8s?
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#44Earlier quoted context omitted.
There is an open issue that confirms enabling ipv6 for containers works: https://github.com/psviderski/uncloud/issues/126 But this hasn’t been enabled by default. What specifically do you mean by ipv6 support?
> What specifically do you mean by ipv6 support? This question does not make sense. This is equivalent to asking "What specifically do you mean by ipv4 support" These days both protocols must be supported, and if there is a blocker it should be clearly mentioned.
How do you want to allocate ipv6 addresses to containers? Turns out there are lots of answers. Some people even want to do ipv6 NAT.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#45How does this compare to something like Dokku?
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#46Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…
Thanks for the both great tools. just i didn't understand one thing ? the request flow, imaging we have 10 servers where we choose this request goes to server 1 and the other goes to 7 for example. and since its zero down time, how it says server 5 is updating so till it gets up no request should go there.
I think there are two different cases here. Not sure which one you’re talking about.
1. External requests, e.g. from the internet via the reverse proxy (Caddy) running in the cluster.
The rollout works on the container, not the server level. Each container registers itself in Caddy so it knows which containers to forward and distribute requests to.
When doing a rollout, a new version of container is started first, registers in caddy, then the old one is removed. This is repeated for each service container. This way, at any time there are running containers that serve requests.
It doesn’t say any server that requests shouldn’t go there. It just updates upstreams in the caddy config to send requests to the containers that are up and healthy.
2. Service to service requests within the cluster. In this case, a service DNS name is resolved to a list of IP addresses (running containers). And the client decides which one to send a request to or whether to distribute requests among them.
When the service is updated, the client needs to resolve the name again to get the up-to-date list of IPs. Many http clients handle this automatically so using http://service-name as an endpoint typically just works. But zero downtime should still be handled by the client in this case.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#47Earlier quoted context omitted.
Nomad is great, but you will still end up with a control plane.
Isn't Nomad pretty much dead now?
They had quite a few release in the last year so it's not dead that's for sure, but unclear how many new customers they are able to sign up. And with IBM in charge, it's also unclear at what moment they will loose interest.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#48Having spent most of my career in kubernetes (usually managed by cloud), I always wonder when I see things like this, what is the use case or benefit of not having a control plane? To me, the control plane is the primary feature of kubernetes and one I would not want to go without. I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few h…
Try it on bare metal where you're managing the distributed storage and the hardware and the network and the upgrades too :)
Why would you want to do that though?
On cloud, in my experience, you are mostly paying for compute with managed kubernetes instances. The overhead and price is almost never kubernetes itself, but the compute and storage you are provisioning, which, thanks to the control plane, you have complete control over. what am i missing?
I wouldn’t dare try to with a small shop try to self host a production kubernetes solution unless i was under duress. But I just dont see what the control plane has to do with it. It’s the feature that makes kubernetes worth it.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#49Earlier quoted context omitted.
100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.
Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
But that's not what anyone is arguing here, nor what (to me it seems at least) uncloud is about. It's about simpler HA multinode setup with a single/low double digit containers.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#50Having spent most of my career in kubernetes (usually managed by cloud), I always wonder when I see things like this, what is the use case or benefit of not having a control plane? To me, the control plane is the primary feature of kubernetes and one I would not want to go without. I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few h…
Try it on bare metal where you're managing the distributed storage and the hardware and the network and the upgrades too :)
Tinkerbell / MetalKube, ClusterAPI, Rook, Cilium?
A control plane makes controlling machines easier, that's the point of a control plane.