I never finished it, but I had a lot of fun documenting a basic-ass K8S (well, K3S) setup that costs about 20€/mo on Hetzner.

You don't really learn about sysadmin through it, or even about docker that much, but you get an idea of how you might easily run a few different things on a server while only needing to know YAML, and not some custom DSL like chef or puppet.

> only needing to know YAML, and not some custom DSL like chef or puppet.

YAML may be a known syntax, but the use of it still requires domain specific knowledge, and is still a domain specific language expressing those domain specific concepts, as to what the expected keys and values are allowed to be and how they are interpreted.

YAML isn’t the DSL, it’s just the language used to express declarative config because the tooling is ubiquitous and it’s rare that anyone uses it as anything more than a nicer version of JSON.

For Kubernetes, it’s CRDs that are written in YAML and they conform to a specification.

I did something similar between jobs—built a k8s "cluster" on my home Linux box using kops+qemu. It didn't make me an experienced admin, but it was really enlightening and fun! Projects like these are a great way to learn.

Ansible?

> But everyone these days is either seen as too smart or too dumb

Vert succinct and poetic way to describe so much these days in this space.

Like everything in tech, it's all about tradeoffs and understanding how you want to scale your business. Of the three startups I've been at, 2 of them adopted k8s early on and 1 of which didn't. Of the two that adopted k8s, one I would say k8s was our key differentiator in terms of our GTM motion and how our platform powered the business. $MM customer needs a setup running as close to their current infra's region for just about any reason, yeah sure we can spin that up in a week. This was often the key bit that allowed us to take customers from our key competitors before the competitor even knew we were in play. The 2nd one..... giant waste of money that gave me a decent pay check.

The third startup that opted _not_ to adopt k8s is stuck at $100M in revenue and can't land customers fast enough to offset churn. This is entirely because the COO has held the mentality "k8s bad, amirite?" and stuck with a patchwork of ansible scripts to manage configuring VM farms that ran our stack. Years of tech debt piled up and every new $MM customer coming in that needs to run in a specific region for $reasons, takes 6 months to setup and cost so much that we'd lose money on the deal. I genuinely believe this startup would be closer to $500M in revenue in the years since I've left had they invested in migrating from containers running in VM's to k8s. But instead they had to lay off 30% of their staff and get another round of funding, and are stagnating.

You don’t need k8s to scale. Can you make other poor choices? Sure.

I have found that people who are adamant haters of k8s, usually truly do not understand k8s or the issues it solves.

It's not for everyone - but having a knee-jerk allergic reaction to anything k8s is silly.

That said - k8s isn't just about scaling, or for "web scale" companies. If you are a person that believes that, it means you are the type of person I am talking about.

I don’t hate k8s, I hate that everyone blindly adopts it without understanding the complexity it adds. I understand it well enough to know YAGNI for most applications. Get over yourself, just because you disagree with me doesn’t mean I’m stupid.

It seems you don't really understand it at all. That's the problem.

NB, did the first company manage their own k8s clusters, or used cloud provider's controllers?

Your basically-absolutist stance is about as unenlightened as the one that you’re arguing against.

Sorry for being pandentic but you don't learn much by looking at the inside of a radio because it's mostly electronic components except for the knobs, antenna, dial. Without understanding how the the electronics work, you're just looking at parts. Mechanical parts like a bicycle, much easier to reason. Not knowing your background, can you build a radio if giving a box of parts? I certainly can't.

Maybe he's talking about a crystal radio? Those are relatively trivial to put together.

I don’t think you’re being pedantic. You’re just making a weird assumption that the radio itself is the only resource. I learned a ton from this as a kid. And I learned from Radio Shack. You stare at it, you go research, you try to fix it, you fail. Talk to someone who knows stuff. Repeat until it works or you work on a new one.

It’s really no different than how I taught myself to fix a chain or replace a spoke. Or know to use WD-40 to clean, but then apply an oil to keep stuff lubricated and protected.

With the internet, it’s a lot easier. I can look up spec sheets just googling component markings and see the sample circuits.

I’ve stared at the Linux kernel a ton. I messed with some stuff. I couldn’t write a kernel myself, but I program better from doing it and I can troubleshoot things easier knowing the components and topology.

Off the top of my head, I can fumble around and make a crappy amplifier from parts in my closet, or write a crappy FAT-like file system. I’d probably struggle a bit with a nice new bike. I think gear shifters and stuff are a lot fancier than an old 10 speed.

Well said. I agree completely.

I don't live my life entirely on the command line either, but GUIs for Docker are just an interesting niche to me, for which I just don't understand what the ven diagram is between people that want Docker containers running locally, know that that's what they want, and know how it all works, but then don't want to do the small handful of commands at the prompt needed to get it running...

I would have assumed the same, but Docker makes ~100m ARR on docker desktop so it’s def not niche.

https://sacra.com/research/docker-plg-pivot/

Docker Desktop includes the easy to run Docker Engine / Docker Machine. I think is fair to assume that most of the revenue is not from users that want a GUI but from users that want a stable Docker Engine experience.

Anecdotal, but my experience, as someone who gives DevOps professional services for many organizations, is that windows users that need containers know that they are called Docker and just download that. Must of them absolutely need GUI. Most of them doesn't know that Docker Desktop requires license, and I convert them to Rancher Desktop.

Nothing wrong with paying for good software.

just because it costs money, doesn't mean it's good software.

That seems like a non sequitur.

It's nearly a crime when a government pay with tax money for product that is in low usage and have zero advantage over the free alternative.

How do I install and run docker containers on windows without docker desktop? I’ve made attempts in the past but never actually succeeded, and just enddd up using docker desktop.

Step 1. Uninstall docker Desktop completely (and images and builds and storage and containers) and reboot. Step 2. Install Rancher Desktop.

If you also need docker emulation with podman too

Step 3. Install Podman Step 4. Install Podman Desktop.

Now a. Either work with Rancher Desktop (open it) and Docker is available also in cmd line (docker, docker ccompose , etc) b. Or Start Podman Desktop to configure Podman (or just use comandline to configure)

Now in cmd you not only have docker and friends but also podman and friends

Bonus, you have Kubernetes tools too and you are FOSS.

Happy composing :-)

PS: I think you cannot start both. I have both installed and never looked back. Windows 10 x64 PRO

I use non Linux systems for which docker desktop was the best way to have docker running without having to do much work.

I don't necessarily want docker containers running locally as some hobbyist, they might be just part of the process, and if the gui helps me move through that process efficiently without having to add more commands to my memory, I'm happy about that. CLIs are great, but when nearly everything has one, those small amount of commands become quite a lot in aggregate.

there are ways to minimize memorization, most important:

1. keep log, docs, records of whatever you are doing. most commands are repetitive.

2. copilot or chatgpt, they help a lot with command lines and simple utilities

3. amazon Q sucks in comparison.

4. it used to be google, but now LLMs do it better. less scrolling and ads/spam.

Yes, either all that above or just GUI for rare occasions.

yes, when it's possible. but guis may not exist or may be not better than console, like in case of ffmpeg. the best, of course, is smart assistant who can take verbal commands. either human or llm.

but my post was about doing complex tasks in general. try to offload. another advise for developers is to write comments, even in your small hobby projects. this way you don't have to memorize it all. this was learned hard way. i usually also have a separate documentation with plans, ideas, algorithms, useful info. remind: this is for hobby projects.

and important thing: touch typing is must have. this makes it all much easier

I do think these are good suggestions for anyone getting started with CLIs. Initially they struck me as a bit redundant, but only because the point I meant to make was that because I've already been doing most of that for ages, I'm happy to delegate that to a good gui if one comes along, since that is both more enjoyable, less error prone (mostly), and less tedious. Notes, comments, and LLM generated commands are lovely, but needing to rely on them less, particularly in situations where you can perform some common subset of tasks with better information layout, interface, and progress/state feedback, is worth paying for sometimes.

FFMpeg is a good example though of one I'm happy to just have my notes on, but since I do literally only ever use it for one or two types of tasks, I'm happy to have that sit behind the scenes. Others might use it in many versatile ways, for which I'd be grateful to have those options readily available in my terminal.

Life is full of many things to do and so not everyone have the luxury to priorities logging ones life for everything they do. 2 or GUI are very feasible option for busy people.

you don't have to "prioritize logging" to have logs, calling this a "luxury" is quite bizarre. You can simply use tools that do bash history search, or one of the many copy-paste memorizer tools, and you'll save many hours out of those "many things to do" simply by typing ctrl+s. Some people are busy simply because they want to.

My preferred solution is to have a GUI, then I don't need to do anything extra to remember CLI commands.

relatedly, I prefer using the github app instead of using the CLI.

Frontenders that need to run backends in my experience are such a cohort.

I use Docker Desktop on both my macbooks, despite shunning IDEs in favour of a decent text editor and the command line. I use it for 2 reasons: to manage the Linux VM, and to twiddle the occasional setting. For running the containers themselves, or running `system prune` when everything gets cluttered up, I use the CLI.

Orbstack is absolutely worth the money on MacOS, fwiw

Same reason, don't fight every time need docker upgraded, on Linux I simply use docker package but in windows and Mac docker desktop is my go to route, but I'm trying podman desktop, I use fedora and sometimes I used podman until stopped because the Nvidia, same reason always does not fight over my tooling

I agree on the docker / podman, but for Kubernetes, Lens is is really useful. It isn't a substitute for knowing the command line but can be much quicker.

Your false assumption is that most of its users know what is Docker and how it works.

The problem is, I forget the commands all the time, because I use them on rare occasions. It gets the how this shit worked moment off your shoulder.

GUIs excel at exploring. Exploring is a very very large part of what I do when running containers locally.

> want Docker containers running locally, know that that's what they want, and know how it all works, but then don't want to do the small handful of commands at the prompt needed to get it running

Consider the case of a team of people collaborating on a software stack - the prototypical use case includes Docker Compose at the simplest and a full K8s stack at the extreme. There is quite often a minimum of 3 containers here; frontend, API/Backend and a database server. If you start to add observability tools, async/batch/event execution, caching, automated integration testing, etc, the number of "layers" in the stack grows quickly. In addition, each component may have unique per-environment or even per-user customizations.

Often one ore two people will manage the stack itself and provide instructions on how to get the whole thing working for others using a specific defined selection of easy to use tools that essentially offer minimal prerequisite knowledge to use

"Install X, run Y, get to work."

It saves a lot of time for the intern on the UI team who just wants to add a component to one page and test it locally and not also have to learn how to deploy the entire stack from scratch.

I don’t get why people need Kubernetes integrations. Kind works just fine. You run it from the terminal and it starts a “cluster” as one or more containers. You can define port bindings and volume mounts via the yaml config. Job done.

Also, nice work on Container Desktop!

Poorly documented is one possibility. Also if you find an issue with anything that's not "testing k8s" the devs will tell you you're not supposed to use it for that.

>> Kubernetes is planned - my devops wants me to add it badly!

Do you mean the Podman "Kubernetes like" functionality (e.g. podman play kube..) or Kubernetes itself?

> It explains all it does behind the scenes if you enable the developer console. It can help one learn so at a certain moment one understands and automates with scripts and specs.

An excellent way to learn indeed! Good luck with your project.

This looks really slick! Quick question for you: the site mentions that other engines are planned. I'm curious what those might be. I would guess something like directly interfacing with containerd or kata, but would love to know more. If I could request one, it would be to directly use systemd, since it now covers all the necessary features to run containers quite nicely.

Incus looks promising, see here https://linuxcontainers.org/incus

As for systemd, podman is amazing https://docs.redhat.com/en/documentation/red_hat_enterprise_...