Nothing I said had anything to do with capabilities (and I certainly didn't want to make you feel like you need to justify yourself). Well, I suppose being able to "maintain" what you've set up would fall into that category so please let me clarify myself. I don't believe you were part of the conversation jmpalacios had about a VCS server, but I mentioned it here, so I'll use this an example (of a larger system--please add salt as necessary). jmpalacios installed "gitlab" (-i.e. git(1) plus other stuff) I installed git(1) (-i.e., no gui: I interact via ssh(1)). My stance is that mine would last longer than his because there are fewer moving parts (this is up for you to determine). However, I may be spewing garbage here.
Hey
JohnK! Up for another heated debate?
Just kidding
I very much appreciate your minimalistic approach, but I guess that, same as with GitLab vs. plain git + ssh + scripts glue, I guess my choice for going with Ansible and Bastille in this case essentially boils down to 1) an attempt to minimize the amount of work that I'd have to do all by myself (progressively factoring up common functionality, abstracting it properly, state management, appropriate abstractions for said state, hook APIs, etc., etc., and that's just off the top of my head as I'm writing this sentence), and 2) minimizing bus factor: of course I don't expect my wife to know how to roll up her sleeves, hook up her SSH key (I already lost her there), and fire up an Ansible playbook, but I can only hope that, should I drop dead tomorrow (hopefully after I've finished my work on these roles!), it'll be easier for her to find someone who'll grok that as opposed to a bunch of home-made, possibly poorly documented custom scripts.
As far as deployment templates being a lot of work, why not open them up for others to use/help? I mean, I'm doing much the same (creating automation solutions for myself) and we're using different methods but there is probably more people doing it your way than mine.
I do intend to share this code with the community, but I still have some more work to do before I feel comfortable doing so. I'm sure it'll receive its fair share of criticism, but at least I want it to be in a position where I'll be able to justify the design decision I made (even if those change as a result of said criticism, hopefully constructive), which in my view means rolling back my sandbox VM back to a pristine state, running the entire playbook on it without
any intervention , and producing a fully operational server on the other side. That's already mostly in place for roles:
- Bootstrap: installs Python, sets up key-based SSH authentication, etc.
- Patch: applies any pending OS-level patches.
- Boot: applies customizable boot-time settings (kernel modules, loader settings, etc.).
- Runtime: applies customizable runtime configurations (system security, sysctl's, etc.).
- Network: configuration of "base" interfaces, VLANs, bridges, resolver, etc.
- Monitoring: collectd, smartd, watchdog, blocklistd, notifications of various events to customizable channels, etc.
- ZFS: data pools importing, boot-time encrypted datasets unlocking, notifications for ZFS events via devd integration, zrepl-based snapshotting & replication with customizable schedules and delegation to an unprivileged user (including configuration of the replication target host), etc.
- Users: creating NAS users & groups, setting up mail forwarding for them, etc.
- Bastille: configuration of Bastille-based jails deployment.
- vm-bhyve: Configuration of vm-byhyve based virtualization.
I'm still lacking some refactoring for some those to play better together, plus a "hardware tuning" role that will take care of setting up things like powerd & IPMI settings, perhaps, plus some new Bastille templates for NFS & SMB servers that I still haven't had a chance to put together. So, yeah, a
lot of work already done and still left to do, and that is if I'm not missing anything, which I wouldn't rule out
