11–20 of 57 posts
This is a fantastic idea. I can imagine using this to pull in any manual changes I might have made to the server because I’m not the most disciplined person.
If you are using a Debian-like or Fedora-like workstation, it's also really useful to 'ansibilize' your desktop OS in case you need to reinstall :)
Very cool! Managing ones boxes as cattle and not pets almost always seems like a better idea in retrospect but historically it is easier said than done. Moreover, I like the idea of being able to diff a box's actual state from a current Ansible system to verify that it actually is as configured for further parity between deployed/planned.
I'm pondering adding some sort of `--enforce` argument to make it re-apply a 'golden' harvest state if you really want to be strictly against drift. For now, it's notifications only though.
https://asciinema.org/a/765293
Enroll will automatically make use of jinjaturtle if it's on the $PATH, to generate templates.
This makes me think of the now defunct https://github.com/SUSE/machinery
Indeed! I'm showing my age, but I do remember using this with Puppet and it was one of my inspirations :D (no commits in nearly 13 years, ouch) https://github.com/devstructure/blueprint
I just saved the state of my WSL2 instance, pushed it to github. Amazingly simple.
FWIW, I was required to add the --harvest, which your quick start seems to be missing?
ie I used:
uvx enroll single-shot --harvest ./harvest --out ./ansible
Even with a tool, people will still have to understand the output, enough that they can spot situations like "this part doesn't make sense at all", "that bit isn't static", "holy crud, there's an unsecured secret", "this part suggests a dependency on this other server we didn't know was involved, and which the tool doesn't investigate".
Very cool. I just saved the state of my WSL2 instance, pushed it to github. Amazingly simple. FWIW, I was required to add the --harvest, which your quick start seems to be missing? ie I used: uvx enroll single-shot --harvest ./harvest --out ./ansible
Indeed when using single-shot, unless you're using the --remote modes (in which case, the harvest is pulled down to a machine-generated path locally), indeed you need to supply the path to the harvest so that the 'manifest' part under the hood, knows what to use.
(By contrast, if you are using just the 'enroll harvest' command by itself, and omit the --out option, it will by default store the harvest in a random directory in ~/.cache/enroll/harvest/xxxxxxx)
Thanks for trying it out!