1 |
On 17/09/2014 09:07, Tomas Mozes wrote: |
2 |
> On 2014-09-16 22:43, Alan McKinnon wrote: |
3 |
>> Anyone here used ansible and at least one of puppet/chef? |
4 |
>> |
5 |
>> What are your thoughts? |
6 |
>> |
7 |
>> I've made several attempts over the years to get puppet going but never |
8 |
>> really got it off the ground. Chef I stay away from (likely due to the |
9 |
>> first demo of it I saw and how badly that went....) |
10 |
>> |
11 |
>> Puppet seems to me a good product for a large site with 1000 hosts. |
12 |
>> Not so much for ~20 or so. Plus puppet's language and configs get large |
13 |
>> and hard to keep track of - lots and lots of directory trees with many |
14 |
>> things mentioning other things. (Nagios has the same problem if you |
15 |
>> start keeping host, services, groups and commands in many different |
16 |
>> files) |
17 |
>> |
18 |
>> I've stumbled upon ansible, it seems much better than puppet for |
19 |
>> smallish sites with good odds I might even keep the whole thing in my |
20 |
>> head at any one time :-) |
21 |
>> |
22 |
>> Anyone care to share experiences? |
23 |
> |
24 |
> We use ansible. |
25 |
> |
26 |
> I like it because you don't need any agents to install, just the ssh |
27 |
> keys and python, which is mandatory on gentoo anyway. We use a |
28 |
> minimalistic script that bootstraps machines (xen-domU) and then |
29 |
> everything else is configured via ansible. Since version 1.6 there is |
30 |
> the portage module to install software and you can do pretty stuff with |
31 |
> replace/lineinfile/template/copy modules. |
32 |
> |
33 |
> The roles are a good way of keeping your systems equal. We have a common |
34 |
> role for all gentoo machines, then roles specific for dom0 and domU |
35 |
> machines and then the actual roles of a project (project-app for |
36 |
> application server of a project). You can even more abstract it to have |
37 |
> a common application server or a common database, but since you can |
38 |
> include other playbooks, we don't use it that way (also to not get lost |
39 |
> in too many levels of abstractions). |
40 |
> |
41 |
> For upgrades you either write precise playbooks (for example, before you |
42 |
> used a specific "testing" package and now you want a newer "testing" |
43 |
> one) where you delete the previous package.accept_keywords line and |
44 |
> insert the new one. Or by having a small number of servers it's often |
45 |
> faster by clusterssh. |
46 |
|
47 |
|
48 |
That's almost exactly the same setup I have in mind. |
49 |
|
50 |
How complex do the playbooks get in real-life? |
51 |
|
52 |
|
53 |
-- |
54 |
Alan McKinnon |
55 |
alan.mckinnon@×××××.com |