Linking 2 interesting p2p building blocks just in case:
https://github.com/mudler/edgevpn https://www.iroh.computer/
Uncloud - Tool for deploying containerised apps across servers without k8s
171–180 of 189 posts
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#172I'm a docker swarm user, and this is the first alternative that looks interesting to me! Some questions I have based on my swarm usage: - do you plan to support secrets? - with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? - if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?
>with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? Yep, you define the mapping between the domain name and the internal container port as `x-ports: app.example.com:8000/https` in the compose file. Or you can specify a custom Caddy config for the service as `x-caddy: Caddyfile` which allows to customise it however you like. See https://uncloud.run/docs/conce…
My personal preference is to have the different stack isolated by default (+ intra-stack isolation possibility using networks).
I'm deploying Swarm and traefik as described here: https://dockerswarm.rocks/traefik/#create-the-docker-compose...
I like that I can put my containers to be exposed on the traefik-public network, and keep others like databases unreachable from traefik. This organisation of networks is very useful, allowing to make containers reachable across stacks, but also to keep some containers in a stack reachable only from other containers on the same network in that same stack.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#173Earlier quoted context omitted.
We have similar backgrounds, and I totally agree with your k8s sentiment. But I wonder what this solves? Because I stopped abusing k8s and started using more container hosts with quadlets instead, using Ansible or Terraform depending on what the situation calls for. It works just fine imho. The CI/CD pipeline triggers a podman auto-update command, and just like that all containers are running the latest version. So w…
Great setup! Where Uncloud helps is when you need containers across multiple machines to talk to each other. Your setup sounds like single-node or nodes that don't need to discover each other. If you ever need multi-node with service-to-service communication, that's where stitching together Ansible + Terraform + quadlets + some networking layer starts to get tedious. Uncloud tries to make that part simple out of the…
It's starting to sound a lot like k8s to me. :D
Technically I could allow my web proxy to discover my services today already, but I refuse to have Traefik (in my case) running as the same user as my services. I prefer to only let them talk over TCP/IP and configure them dynamically with Ansible instead.
It always amazed me that people used that feature in Traefik or Caddy, because it essentially requires your web proxy to have container access to all your other services. It seems a bit intimate to me, but maybe I'm old school.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#174Earlier quoted context omitted.
Those are all sub-par cloud technologies which perform very badly and do not scale at all. Some people would rather build their own solutions to do these things with fine-grain control and the ability to handle workloads more complex that a shopping cart website.
I've tried to refrain from commenting but your comment pushed me over the edge. I either want to dismiss your comment as ignorant that amazon is just a shopping cart or ignorant that you even need cloud technologies until you have 1000s of customers. But I must concede there's a chance you fall in that middle area and I'm wrong. It's < 5 percent. But yeah sure.. we have a scale problem and you're right you've identif…
Even kubectl slows down to a crawl with a thousand deployments on the same cluster.
The protocols are bad, as is the tech supporting them.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#175I'm a docker swarm user, and this is the first alternative that looks interesting to me! Some questions I have based on my swarm usage: - do you plan to support secrets? - with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? - if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?
Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 Compose configs are already supported and can be used to inject secrets as well, but there'll be no encryption at rest there in that case, so might not be ideal for everyone. Regarding questions 2 and 3, the short answers are "not at the moment" and "yes, for now", here's a relevant discussion that touches on both points: https:/…
Swarm is not far from my dream deploy solution, but here are some points that might be better, some of them being already better in uncloud I think:
- energy in the community is low, it's hard to find an active discussion channel of swarm users
- swarm does not support the complete compose file format. This is really annoying
- sometimes, deploys fail for unclear reasons (eg a network was not found, but why as it's defined in the compose file?) and work the next try. This is never lead to problems, but doesn't feel right
- working with authenticate/custom registries is somewhat cumbersome
- having to work with registries to have the same image deployed on all nodes is sometimes annoying. It could be cool to have images spreading across nodes.
- there's no contact between devs and users. I've just discovered uncloud and I've had more contact with its devs here than in years of using swarm!
- the firewalling is not always clear/clean
- logs accessibility (service vs container) and containers identification: when a container fails to start, it's sometimes harder than needed to debug (esp when it is because the image is not available)
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#176Earlier quoted context omitted.
Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 Compose configs are already supported and can be used to inject secrets as well, but there'll be no encryption at rest there in that case, so might not be ideal for everyone. Regarding questions 2 and 3, the short answers are "not at the moment" and "yes, for now", here's a relevant discussion that touches on both points: https:/…
Swarm is not far from my dream deploy solution, but here are some points that might be better, some of them being already better in uncloud I think: - energy in the community is low, it's hard to find an active discussion channel of swarm users - swarm does not support the complete compose file format. This is really annoying - sometimes, deploys fail for unclear reasons (eg a network was not found, but why as it's d…
Thanks for the detailed overview!
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#177I think this is pretty cool. Congrats on the project, might play with it later.
If you want something even simpler, something that doesn't run on your servers at all, you can look at Kamal: https://kamal-deploy.org
What I like about Kamal is that it's backed by a company that actually fully moved out of K8s and cloud, so every release is battle-tested first.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#178Very neat tool. Thank you for your efforts!
I am wondering how state replication works on the backend. The design mentions using crdt and a gossip proto, but I'm not sure what is actually implemented as it is a tad vague. I haven't dug into the code so forgive me if it is obvious or explained elsewhere.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#179Earlier quoted context omitted.
How many flawless, painless major version upgrades have you had with literally any flavor of k8s? Because in my experience, that’s always a science experiment that results in such pain people end up just sticking at their original deployed version while praying they don’t hit any critical bugs or security vulnerabilities.
I’ve run Kubernetes since 2018 and I can count on one hand the times there were major issues with an upgrade. Have sensible change management and read the release notes for breaking changes. The amount of breaking changes has also gone way down in recent years.
Same. I think maybe twice in that time frame we've had a breaking change, and those did warn us for several versions. Typically the only "fix" we need to apply is changing the API version on objects that have matured beyond beta.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#180Earlier quoted context omitted.
This is exactly how it works now. The Compose file is the declarative specification of your services you want to run. When you run 'uc deploy' command: - it reads the spec from your compose.yaml - inspects the current state of the services in the cluster - computes the diff and deployment plan to reconcile it - executes the plan after the confirmation Please see the docs and demo: https://uncloud.run/docs/guides/depl…
That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative. I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start. In fact coul…
> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer
In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe.
In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.