alt Hacker NewsShow HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt
Happy new year folks!
This tool was born out of a situation where I had 'inherited' a bunch of servers that were not under any form of config management. Oh, the horror...
Enroll 'harvests' system information such as what packages are installed, what services are running, what files have 'differed' from their out-of-the-box defaults, and what other custom snowflake data might exist.
The harvest state data can be kept as its own sort of SBOM, but also can be converted in a mere second or two into fully-functional Ansible roles/playbooks/inventory.
It can be run remotely over SSH or locally on the machine. Debian and Redhat-like systems are supported.
There is also a 'diff' mode to detect drift over time. (Years ago I used Puppet instead of Ansible and miss the agent/server model where it would check in and re-align to the expected state, in case people were being silly and side-stepping the config management altogether). For now, diff mode doesn't 'enforce' but is just capable of notification (webhook, email, stdout) if changes occur.
Since making the tool, I've found that it's even useful for systems where you already have in Ansible, in that it can detect stuff you forgot to put into Ansible in the first place. I'm now starting to use it as a 'DR strategy' of sorts: still favoring my normal Ansible roles day-to-day (they are more bespoke and easier to read), but running enroll with '--dangerous --sops' in the background periodically as a 'dragnet' catch-all, just in case I ever need it.
Bonus: it also can use my other tool JinjaTurtle, which converts native config files into Jinja2 templates / Ansible vars. That one too was born out of frustration, converting a massive TOML file into Ansible :)
Anyway, hope it's useful to someone other than me! The website has some demos and more documentation. Have fun every(any)-one.
Comments
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.
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.
Bravo, I will play with it. I haven't played with ansible till now but I know that its related to automation.
If something can make ansible easier for me to try out like this tool while being pragmatic, I will give this a try someday thank you!
How accurate does this tool end up becoming though? Like can I just run some bunch of commands to setup a server and then use this with ansible?
Would this end up being a good use for it or would I just re-invent something similar to cloud-init on wrong abstraction. (On all fairness, one thing troubling me about cloud-init is that I would need to probably have a list of all commands that I want to run and all changes which sometimes if history command might have some issues or you do end up writing files etc. ends up being a little messy)
I haven't played that much with both cloud-init and ansible either but I am super interested to know more about enroll and others as well as I found it really cool!
Genuenly the thing i've been dreaming about for a while. Nice work.
This makes me think of the now defunct https://github.com/SUSE/machinery
I have quite a few machines that were constructed using Ansible ... When I get a chance, I'll reverse then and compare the results to the IaC that created them
This looks like a great way to learn Ansible too. Instead of learning alongside random examples, you can setup your server and see how it would look like in Ansible.
Awesome stuff!