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