[gentoo-user] Re: Ansible, puppet and chef
On Tue, 16 Sep 2014 22:43:18 +0200, Alan McKinnon wrote: 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'm using puppet for small installs ( 10 hosts) and am quite happy with it. It's wonderful to push some changes and have all these hosts configure themselves accordingly. Not to mention the joy of adding new hosts. The configuration can get large, but then again, these are all things that you are already managing on the host. Better to do it all in one place, rather than on each individual host with all its associated inconsistencies. Us being a ruby shop I never looked at ansible and I'm not even sure it existed when we choose puppet. One thing you can do to make the deployment easier for smaller scale setups would be to use a masterless puppet. One less component to worry about. Just distribute the puppet repository and run puppet apply. Hans
Re: [gentoo-user] Re: Ansible, puppet and chef
On 17/09/2014 07:46, Hans de Graaff wrote: On Tue, 16 Sep 2014 22:43:18 +0200, Alan McKinnon wrote: 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'm using puppet for small installs ( 10 hosts) and am quite happy with it. It's wonderful to push some changes and have all these hosts configure themselves accordingly. Not to mention the joy of adding new hosts. I want the benefits of puppet and the end result it brings about - that's already established. The configuration can get large, but then again, these are all things that you are already managing on the host. Better to do it all in one place, rather than on each individual host with all its associated inconsistencies. Us being a ruby shop I never looked at ansible and I'm not even sure it existed when we choose puppet. Ansible is somewhat new, and reading between the lines it might have been written in response to large complex puppet installs. One thing you can do to make the deployment easier for smaller scale setups would be to use a masterless puppet. One less component to worry about. Just distribute the puppet repository and run puppet apply. Well, I've already decided to not use puppet, I find it over-complex for my needs (not to mind that the language has some confusing parts to it ) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Ansible, puppet and chef
Alec Ten Harmsel alec at alectenharmsel.com writes: We use bcfg2, and all I can say is to stay away. XML abuse runs rampant in bcfg2. From what I've heard from other professional sysadmins, Puppet is the favorite, but that's mostly conjecture. Hi Alec! Anyone here used ansible What are your thoughts? I have no thoughts. I do see many, many new git repositories that contain mesos and ansible. [1] So ansible must be cool? Ansible is everywhere now. Already given up on the local cron_extended effort? What, no Chronos? Anyone care to share experiences? Hey, I was drunk OK? I thought this clustering for science was a good thing, like getting a puppy and a new girlfriend all in the same week. BOY was I tricked. Anyway, I know deep down inside you are wanting a cluster where you work(?). Alec has one, I'm building one, so come in, the water is, well, very wet and wild! [1] https://github.com/AnsibleShipyard/ansible-mesos https://github.com/mhamrah/ansible-mesos-playbook http://blog.michaelhamrah.com/2014/06/setting-up-a-multi-node-mesos-cluster-running-docker-haproxy-and-marathon-with-ansible/ http://ops-school.readthedocs.org/en/latest/config_management.html snip many more. James
