Zta77

Joined 2 years ago

Karma
55
Submissions
24
Member since
Jan 12
Hacker, tinkerer, creator of Lightwhale.

https://lightwhale.asklandd.dk/--prhn

View on Hacker News

Recent submissions

Comment · 6 months ago
Comment · 6 months ago
Comment · 6 months ago
I'm biased, but I could see Lightwhale play a key role in this setup. You could start small, two nodes with Lightwhale in a Docker Swarm cluster. Run your server in a container. Leverage Swarm's load balancing to distribute connections to the nodes. You go l can even experiment with this in Proxmox and run the Lightwhale nodes as VMs if you like.

You get a minimum effort OS to host your game on, and the option to distribute it.

Comment · 6 months ago
Comment · 6 months ago
I do the opposite:

My workstation is where I work, fiddle with things, experiment. It 's a workbench in the context of software development. So I need to be able to modify and configure everything, install things, uninstall them again. A can't use a workbench wrapped in cellophane.

I want my server stable and fixed. I don't care about the OS, I don't want to configure it, update it, and otherwise maintain it. It's just a platform to run the Docker Engine and my containers.

Comment · 6 months ago
Hi, thanks for taking interested in my project!

I assumes you've visited the Lightwhale website and at least read the headlines:

"No maintenance headaches. Just boot and focus on what matters!"

and the first section, including:

"Lightwhale lowers the entry barrier, removes tedious administration tasks, and opens a friction-free path to productivity"

But maybe you dismissed as being empty buzzwords, or didn't quite believe it, so you want an explanation. That's perfectly okay, allow me to elaborate:

So, if you've already gone though the process of partitioning, installing, and configuring a general purpose operating system, and then ran that "one line" that added the docker repository, installed docker, docker-compose, and buildx, and presumably also added yourself to the docker user group, then I'd say you've got a head start compared to a clean, bare-metal box. True, you're now off to the races.

Of course, all this work and time invested in your system comes with a tax called maintenance.

Everything you just installed is live. And now your job is to keep everything safe and sound. Not just the files in $HOME and /etc/, but also /usr/bin/docker, /usr/bin/bash, /lib/libc.so, and even /usr/bin/[. But that's just the rootfs. You also have to groom your boot partition. Even the partition table and MBR. I know, your installer and package manager handles that for you. But nevertheless, all this is writable and either imposes an attack surface, is at risk of daily butter fingers breaking things, or lives on a filesystem that may introduce silent bitrot or on a media that can fail. But that's not the end of it. If do a good job, your server will live a long and happy life. And eventually, you get to experience something remarkable: It dies. I'm not talking about the hardware suffering a fatal crash, no; I'm taking about Canonical deciding that your version of Ubuntu is now suddenly going into End Of Life. You now have choices to make: Should you upgrade and leave your system at the mercy of the numerous upgrade scripts? Should you reinstall to get a clean slate, repeat everything mentioned above, and try to migrate your data configuration, containers, volumes, etc? Or maybe just leave the OS there dead; afterall, you're only interested in your docker containers and they're unaffected, so that seems like a valid path. Except every time you log in, it's like stepping over a dead body in the doorway, and that doesn't feel quite right.

Of course, if you find these administration tasks fun and interesting that's perfectly okay. And honestly, I can absolutely relate to that, because I've been doing it as a hobby since forever, and I enjoyed myself. Until I reached a point where the installer and maintenance didn't interest me as much as just running the software.

Now, look back at my taglines above, and I hope you can see how Lightwhale can benefit you in setting up a home server:

If you want less tedious administration and maintenance, but instead like a friction-free path to just boot and run your software, then Lightwhale is worth a try.

Comment · 6 months ago
Correct, it's only terminal. Lightwhale provides only the bare necessities for you to deploy what you need. So instead of dictating a UI, you're free to choose what you like, be it Portainer, Dockhand, Komodo or something else.

Lightwhale is perhaps more of an "expert system" compare to consumer products that come preconfigured with a UI. On the other hand, if you want to try a server where you are in full control, Lightwhale it is the easiest way to get a pure Docker server up and running.

Comment · 6 months ago
Me too. What do you mean?
Comment · 6 months ago
Yes, sorry. I don't use the master branch, and Bitbucket doesn't easily let me delete it. But wait, you confirmed that "3.0" isn't there, but somehow missed that "3.0.0" is? =)
Comment · 6 months ago
I think you're missing the point.

Of course you can choose a general purpose Linux dist. But you'll still have to go through the extra work of partitioning the disk, installing the system, selecting packages, possibly follow some other guide to install Docker Engine, Docker Compose, Docker Buildx, and doing that thing with the docker group. At that point you'll pretty much have what Lightwhale provides out of the box. Except you'll be left with a system that isn't immutable, and where system and data is entangled on one filesystem. And if that's your thing, you should do definitely that. But...

If you just want to run your containers, then Lightwhale is best in class.

Comment · 6 months ago
I don't have a recommended or official way. But you could look into using `btrfs send` to send the data filesystem subvolume to a backup host, preferably initiated from the backup host, e.g. by ssh into the Lightwhale server and do the send. And there's always rsync.

One nice thing to keep in mind, is that all data that is ever written in Lightwhale, exists in /mnt/lightwhale-data/lightwhale-state. Data is not entangled with the rest of the system in the rootfs.

The tricky part perhaps is that you should sync all container data to disk prior to taking the backup (or snapshot) to be sure you have a clean state. And the only safe way I can think if, is to stop all containers first. But I think this goes for every Docker Engine.

Comment · 6 months ago
Exactly!
Comment · 6 months ago
Comment · 6 months ago
Hello!

I went with Btrfs for persistence, and automated some things around that. For example, if you give Lightwhale two magic disks, it will automatically create a Btrfs RAID1. During persistence setup it will also create a few default subvolumes to fully support snapshots and rollback of the entire data filesystem. (Remember, the rootfs of the OS is still immutable, and is never part of the data filesystem). Besides snapshots and RAID, Btrfs has checksums which I think is a must.

I've heard lots of nice things about zfs, and I know it does snapshots and checksum too. But also that it eats huge amounts of memory for breakfast. I may not be updated on this, but I faintly remember some licensing issues, that potentially could cause problem if zfs was baked into an ISO like Lightwhale. Those are the main reasons why I'm reluctant to zfs and chose Btrfs.

But you're absolutely right, I have taken some radical choices with this dist. But most are deliberate and by design =)

Comment · 6 months ago
Lightwhale comes with docker compose too! And docker buildx and git for good measure. This means you can clone your git repo, and docker compose up your stack immediately.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton