4 ms·

I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet... Can anyone who's worked with Puppet/Chef and Ansible offer some i

by taude 13y ago

I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet... Can anyone who's worked with Puppet/Chef and Ansible offer some insights?

donjigweed 13y ago
Same basic concept as the others. Ansible has Playbooks to Chef's Recipes. Ansible has Vars to Chef's data bags, and template files just like Chef or Puppet. For some reason, Ansible just ends up being much simpler to get going with. Probably because you write playbooks in a very straightforward yaml syntax, and the topology is not client-server - you just run Ansible right from your local terminal, like running knife I guess, with chef-solo. Just look at the documentation on their site, there's basically 3 or 4 pages you need to read before you're writing playbooks. I've worked with all three, Ansible is far and away the only sane one if you ask me.
andyl 13y ago
I started with Chef, then switched to Puppet, then to Ansible. They all do similar things, but for me, Ansible was simplest and most productive. Things I like best: Ansible relies on SSH and not a custom messaging system. Ansible requires no software to install/monitor on the remote systems. Ansible configs generally smaller and simpler, based on YAML and not a custom config file format. Also I found it to be simple to extend Ansible with custom modules written in Ruby and Bash.
tszming 13y ago
I have been using chef (solo/server) for 2 yrs and started playing with ansible two weeks ago, so far, my comments: Pros: - ansible's creator is very active and helpful in github/mailing list in answering issues/questions; for chef, reproducible bugs can't even get an acknowledgement from opscode [1], free users are not their priority IMO - simple in design, able to deploy multiple targets without a centralized monster like chef-server, you just need SSH - batteries included, e.g. aws, linode, mysql, postgresql tasks Cons: - ansible is more buggy and still under heavy development - documentation is confusing, e.g. current ansible latest is 1.2.2 but documentation showing features only appear in 1.3 - no playbook dependency handling - build in modules are helpful but not really extensible [2] - the creator is helpful but sometimes opinionated [3] [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204 [2] https://github.com/ansible/ansible/issues/3776#issuecomment-22264220 https://github.com/ansible/ansible/issues/3776#issuecomment-... [3] https://groups.google.com/forum/#!searchin/ansible-project/group_vars$20default/ansible-project/Gd_7P3Ei_Vs/5DsDiCS-w8AJ https://groups.google.com/forum/#!searchin/ansible-project/g...
- iffycan 13y ago
  aye... opinionated he is :)
- mpdehaan2 13y ago
  So, to address some questions. (A) Definitely file tickets on bugs. If there are things we don't know about we can't fix them :) (B) Role dependencies I think are what you may mean. They are on deck for inclusion in 1.3 which is out this month. (C) I would agree that core modules aren't subclassable by design though this is largely an artifact of how we are engineered to not have any dependencies for getting things going on remote nodes (zero bootstrapping). For the most part it works well and I'm fine with moving get_url into module common. (D) Yay variable scope thread! No doubt, I do have opinions and we want to fight to keep things minimal. There was a recent proposal to inject role variables into the local namespace that fixes most of this, this is also something we are going to do in 1.3. I think that will eliminate most of the "prefix" ideas when you have variables defined in multiple places. I still think group_vars/ is a great place for defaults :)
  - tszming 13y ago
    Hi Michael, congratulation first and thanks for your prompt reply. It is amazing how you can be so attentive to the community. For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line! For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.

by taude 13y ago

I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet... Can anyone who's worked with Puppet/Chef and Ansible offer some insights?

donjigweed 13y ago

Same basic concept as the others. Ansible has Playbooks to Chef's Recipes. Ansible has Vars to Chef's data bags, and template files just like Chef or Puppet. For some reason, Ansible just ends up being much simpler to get going with. Probably because you write playbooks in a very straightforward yaml syntax, and the topology is not client-server - you just run Ansible right from your local terminal, like running knife I guess, with chef-solo. Just look at the documentation on their site, there's basically 3 or 4 pages you need to read before you're writing playbooks. I've worked with all three, Ansible is far and away the only sane one if you ask me.

andyl 13y ago

I started with Chef, then switched to Puppet, then to Ansible. They all do similar things, but for me, Ansible was simplest and most productive. Things I like best: Ansible relies on SSH and not a custom messaging system. Ansible requires no software to install/monitor on the remote systems. Ansible configs generally smaller and simpler, based on YAML and not a custom config file format. Also I found it to be simple to extend Ansible with custom modules written in Ruby and Bash.

tszming 13y ago

I have been using chef (solo/server) for 2 yrs and started playing with ansible two weeks ago, so far, my comments: Pros: - ansible's creator is very active and helpful in github/mailing list in answering issues/questions; for chef, reproducible bugs can't even get an acknowledgement from opscode [1], free users are not their priority IMO - simple in design, able to deploy multiple targets without a centralized monster like chef-server, you just need SSH - batteries included, e.g. aws, linode, mysql, postgresql tasks Cons: - ansible is more buggy and still under heavy development - documentation is confusing, e.g. current ansible latest is 1.2.2 but documentation showing features only appear in 1.3 - no playbook dependency handling - build in modules are helpful but not really extensible [2] - the creator is helpful but sometimes opinionated [3] [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204 [2] https://github.com/ansible/ansible/issues/3776#issuecomment-22264220 https://github.com/ansible/ansible/issues/3776#issuecomment-... [3] https://groups.google.com/forum/#!searchin/ansible-project/group_vars$20default/ansible-project/Gd_7P3Ei_Vs/5DsDiCS-w8AJ https://groups.google.com/forum/#!searchin/ansible-project/g...

iffycan 13y ago
aye... opinionated he is :)
mpdehaan2 13y ago
So, to address some questions. (A) Definitely file tickets on bugs. If there are things we don't know about we can't fix them :) (B) Role dependencies I think are what you may mean. They are on deck for inclusion in 1.3 which is out this month. (C) I would agree that core modules aren't subclassable by design though this is largely an artifact of how we are engineered to not have any dependencies for getting things going on remote nodes (zero bootstrapping). For the most part it works well and I'm fine with moving get_url into module common. (D) Yay variable scope thread! No doubt, I do have opinions and we want to fight to keep things minimal. There was a recent proposal to inject role variables into the local namespace that fixes most of this, this is also something we are going to do in 1.3. I think that will eliminate most of the "prefix" ideas when you have variables defined in multiple places. I still think group_vars/ is a great place for defaults :)
- tszming 13y ago
  Hi Michael, congratulation first and thanks for your prompt reply. It is amazing how you can be so attentive to the community. For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line! For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.