Ansible is next on my list of things to learn.

I don't think I'll need to dedicate all of my compute space to K8s probably just half for now.

Ansible is next on my list of things to learn.

Ansible is y2k tech brought to you in 2010. Its workarounds for its many problems bring problems of their own. I'd recommend mgmtconfig, but it's a deep pool if you're just getting into it. Try Chef(cinc.sh) or saltstack, but keep mgmtconfig on the radar when you want to switch from 2010 tech to 2020 tech.

Wow, huge disagree on saltstack and chef being ahead of Ansible. I've used all 3 in production (and even Puppet) and watched Ansible absolutely surge onto the scene and displace everyone else in the enterprise space in a scant few years.

Ansible is just so much lower overhead and so much easier to understand and make changes to. It's dominating the configuration management space for a reason. And nearly all of the self hosted/homelab space is active in Ansible and have tons of well baked playbooks.

My issue with mgmt.config is that it bills itself as an api-driven "modern" orchestrator, but as soon as you don't have systemd on clients, it becomes insanely complicated to blast out simple changes.

Mgmt.config also claims to be "easy", but you have to learn MCL's weird syntax, which the issue I have with chef and its use of ruby.

Yes, ansible is relatively simple, but it runs on anything (including being supported on actual arm64) and I daresay that layering roles and modules makes ansible quite powerful.

It's kind of like nagios... Nagios sucks. But it has such a massive library of monitoring tricks and tools that it will be around forever.

have to learn MCL’s weird syntax

You skewer two apps for syntax, but not Ansible's fucking YAML? Dood. I'm building out a layered declarative config at the day-job, and it's just page after page with python's indentation fixation and powershell's bipolar expressions. This is better for you?

I’ve used all 3 in production (and even Puppet) and watched Ansible absolutely surge onto the scene and displace everyone else in the enterprise space in a scant few years.

Popular isn't always better. See: Betamax/VHS, Blu-ray vs HDDVD, skype/MSSkype, everything vs Teams, everything vs Outlook, everything vs Azure. Ansible is accessible like DUPLO is accessible, man, and with the payola like Blu-ray got and the pressuring like what shot systemd into the frame, of course it would appeal to the C-suite.

Throwing a few-thousand at Ansible/AAP and the jagged edges pop out -- and we have a team of three that is dedicated to Nagios and AAP. And it's never not glacially slow -- orders of magnitude slower than absolutely everything.

Yeah, similar sized environments here too, but had good experiences with Ansible. Saw Chef struggle at even smaller scales. And Puppet. And Saltstack. But I've also seen all of them succeed too. Like most things it depends on how you run it. Nothing is a perfect solution. But I think Ansible has few game breaking tradeoffs for it's advantages.

Omg, get over it. You haven't discovered the holy grail of automation or we'd all be using it. yaml is the devil I know. Sue me.

I've been through these orchestration tools (not very much at MCL I'll admit) and in the end there is always something that's a pain in the ass.

Chef's integration with vault sucks and recipes can become role hell.
Puppet needs agents and the initial setup is awful.
Ansible doesn't do well where ssh can't go, and it touches stuff when it makes changes, which isn't fun for the guy reviewing FIM.
I'm sure MCL has some quirk that makes working with it nasty.

We've gone down the route of using ipam as an intermediary to collect basic configs and act as a repo for orchestration, and let me tell you, APIs aren't the silver bullet. Updates to DNS records aren't exactly fun when they don't work because a client's stack is a snowflake combo of pinned packages.

So forgive me if I remain skeptical that yet another orchestration platform has "solved" it the way you're describing.

I've been hearing this for 30 years and heard the promise from a few players like Altiris, canonical (landscape), and many devs with bespoke scripts.

They all suck in some unique way.

That's a sick little rack.

Absolutely follow through with K8S, I recently did this and it's definitely worth it.

Running the workers in VMs is a little wasteful. But it's simplifies your hardware and your backups. My home lab version is 3 VMs in a Proxmox, The idea is, after it's built and working I can just move those VMs wholesale to other boxes. But realistically, adding workers to K8S is pretty brain dead simple, and draining and migrating the old worker nodes another skill you should be learning.

You could throw Debian on everything and deploy all your software through Ansible.

Don't lose sight of the goal. Get k8s running, push through longhorn, get some pods up in full tolerant mode, learn the networking, The engress the DNS, load balancing, proxies.

Exactly how you do it is less important than the act of doing it and learning kubectl.

https://www.surfboard.com/products/cable-modems/sb6190/