tontony
Joined 3 years ago
Karma
55
Submissions
15
Member since
Dec 1
Email: [email protected]
View on Hacker NewsRecent submissions
Comment · 6 months ago
That's fair; good solution.
Comment · 6 months ago
Compose is great, but a couple things always created friction for me when using it for non-local setups:
* Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline.
* Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worms.
* Boilerplate needed to expose your services with TLS
Uncloud [1] fixed all those issues for me and is (mostly) Compose-compatible.
Comment · 11 months ago
Thanks for the detailed overview!
Comment · 11 months ago
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://github.com/psviderski/uncloud/discussions/94
Speaking of Swarm and your experience with it: in your opinion, is there anything that Swarm lacks or makes difficult, that tools like Uncloud could conceptually "fix"?
Comment · 11 months ago
Sure, but it all boils down to trust at the end of the day.
Why would you trust a third-party Debian repository (that e.g. has a different user namespace and no identity linking to GitHub) more than running something from evidently the same user from GitHub, in this specific case?
I'm not arguing that a repository is nice because versioning, signing, version yanking, etc, and I do agree that the process should be more transparent and verifiable for people who care about it.
Comment · 11 months ago
> What if you want to manage multiple/distinct clusters
Uncloud supports having multiple contexts (think - clusters) in the same configuration file, or you can also use separate config files (via --uncloud-config attribute).
Comment · 11 months ago
Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?
Comment · 11 months ago
Nomad still has a tangible learning curve, which (in my very biased opinion) is almost non-existent with Uncloud assuming the user has already heard about Docker and Compose.
Comment · 11 months ago
Uncloud is not a Kubernetes distribution and doesn't use K8s primitives (although there are of course some similarities). It's closer to Compose/Swarm in how you declare and manage your services. Which has pros and cons depending on what you need and what your (or your team's) experience with Kubernetes is.
Comment · 1 year ago
Totally valid approach if that works for you, the docker context feature is indeed nice.
But if we're talking about hosts that run production-like workloads, using them to perform potentially cpu-/io-intensive build processes might be undesirable. A dedicated build host and context can help mitigate this, but then you again face the challenge of transferring the built images to the production machine, that's where the unregistry approach should help.
Comment · 1 year ago
A few thoughts/ideas on using this in Kubernetes are discussed in this issue: https://github.com/psviderski/unregistry/issues/4; generally, should be possible with the same idea, but with some tweaking.
Also have a look at https://spegel.dev/, it's basically a daemonset running in your k8s cluster that implements a (mirror) registry using locally cached images and peer-to-peer communication.
Comment · 1 year ago
> What I do is host the thing on a cheap cloud server until it grows enough
Curious, do you use anything specific (like Compose) for that single-server phase?