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