On 05/09/2017 02:01, Grant wrote: >>>> This is exactly the use-case ansible was designed for: declarative, >>>> idempotent, predictable management of a fleet of machines that may or >>>> may not be around when you feel like updating something (so it catches >>>> up later), and needs only sshd and python to do it's magic :-) >>> >>> ansible does sound pretty cool. I'll check it out if I outgrow my >>> script but as long as I can keep using Dell XPS 13 laptops I don't >>> think it will have any trouble scaling. >> >> >> Allow me a few moments to convince you more :-) >> >> Maybe you don't need it right this minute, but your current method will >> become less and less workable with time, and when you feel that maybe >> you ought to do it differently, you might remember this conversation. >> >> ansible works like you do - ssh's into a host, and does what needs >> doing. It figures out what to do the same way you do, by having a clear >> picture of what should be and making the host that way. It's very much >> like a proxy for you. >> >> The difference comes in when you observe that with ansible you don't >> have to deal with the details of HOW to do something (the shipped >> modules already deal with all of that), you only concern yourself with >> WHAT you want to accomplish. >> >> If you only use ansible to basically run ssh in a for loop, then it's a >> waste of the setup effort. But let's say Dell retire or change those >> XPS13s dramatically. 4 of yours wear out, and you buy 8 Precisions. >> Bugger, they have different hardware and the chipset running the SSDs >> has a different drive. The GPU, the wifi NIC, these things all drift >> with time. Then you figure you want 2 management Precisions, plus >> your's, the wife's and the workshop manager's laptops need extra stuff; >> and the plebs can stay the same on the XPS. >> >> And your script gets out of hand real quick (we've all been there). How >> do you detect that some is a Precision and do appropriate actions in a >> nasty script? It's not easy. >> Ansible does all that for you upfront out the box. It always knows what >> it's working on (thanks to a module called setup) and catering for >> inevitable differences is trivial to handle. With none of the downsides >> to copying entire tree structures around (like copying way too many >> files you didn't intend to. Like /var/run...) > > > It truly sounds great but the devil is in the details in my particular > environment. If I feel like I'm outgrowing my script (and maybe even > if I don't) I'll dig into ansible. How big of a duty is the > implementation?
Implementation is easy, it's just another Python app with a config file. Then there's some associated work around getting your SSH setup the way you want it with the correct users and passwords and keys and enough access control that you feel safe. Nothing new there, you likely already have all that already. If not, well ssh isn't exactly new to you :-) The bulk of the work is in thinking and planning what you want to achieve. You have to have a very clear picture of the end goal so you can build towards it; this part is exactly like thinking your way through code you intend to write. This part depends on how complex your stuff is and how many exceptions you have to the rule. You're the only one that knows if the result will be worth while, so like all new toys I suppose the best approach is to tinker with it a bit, see if you like it, then decide if you think it worthwhile to proceed. -- Alan McKinnon [email protected]
