Re: [gentoo-user] Ansible, puppet and chef

[Alan McKinnon <alan.mckinnon@gmail.com>]

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


That's almost exactly the same setup I have in mind.

How complex do the playbooks get in real-life?


-- 
Alan McKinnon
alan.mckinnon@gmail.com