>>> 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? Thanks, Grant
