4 ms·

Sorry, switched to Ansible last month and haven't looked back. Edit: Actually I have looked back, in horror and disbelief that I put up with Puppet for so long

by smegel 12y ago

Sorry, switched to Ansible last month and haven't looked back. Edit: Actually I have looked back, in horror and disbelief that I put up with Puppet for so long.

stunthamsterio 12y ago
Same here. I've used Puppet for years and I've even written a book on it. I dropped it completely within days of using Ansible, to me it betters Puppet in just about every way I can think of.
quicksilver03 12y ago
I'm contemplating switching to Ansible as well after 3 years of using Puppet for my personal and company infrastructure, I feel that Puppet has become too complex and that I use no more than 10% of its features.
cheald 12y ago
Same, except with Salt. Puppet is a large, unwieldy beast by comparison. Salt is like puppet, except not horribly frustrating to use.
WestCoastJustin 12y ago
For anyone wondering what Ansible is, or what is allows you to do, here's a basic overview screencast I put together [1]. Cannot recommend it enough, as the barrier to entry is simply so small, that you can get up and running in no time. The 250+ built in modules are also a killer feature, no hunting around for added logic to make things "just work" off the starting line. I kind of think Ansible hit a sweet spot, coming to market after Puppet/Chef, in that they learned from the ecosystem, and adapted their tool for the pain points. There is also no reason you could not use Puppet with Ansible (rolling upgrades, quick patches, etc). Happy to answer any questions too. PS. Bit of a disclaimer: The screencast is a four part series, the first episode is free, and the remain three parts require a subscription. Did not want to bait and switch you. The first episode will give you enough to know what Ansible is all about though. [1] https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...
- smegel 12y ago
  If you are an Ansible dev, I actually do have a question. I am a bit stumped as to how to "call" a role from other roles with different variables, so as to deploy the same template with different parameters. Currently I am putting the template in a separate role (with a task to deploy it), and then including it several times from other roles, e.g. # role X - include: ../../common/tasks/foo.yml # deploys ../../common/templates/my.conf.j2 - vars: x=33 # role Y - include: ../../common/tasks/foo.yml # deploys ../../common/templates/my.conf.j2 - vars: x=42 Is there a better way to do this? It would be nice to be able to "call" a role/task with parameters, to be able to reuse common elements like templates and task logic.
  - BadassFractal 12y ago
    You can pass parameters to roles: http://docs.ansible.com/playbooks_roles.html#role-dependencies http://docs.ansible.com/playbooks_roles.html#role-dependenci...
    - smegel 12y ago
      I was somewhat aware of dependencies, but they don't really do what I want. I want to be able to execute a role (or task within a role), much like calling a function, that will be executed at the point it is called (dependencies are all executed before the role executes. I may also want to call the "function" multiple times within a role, with different parameters, to, for example, deploy a template several times to different named files. And yes, dependencies can execute roles multiple times, but this is business logic that belongs in the main role file, not in a meta file. And from what I can see, dependencies can only call a role as a whole, not a part (or task) therein. Basically what I have with "include" does exactly what I want, but it would be nice if it was a bit more explicit that I was calling a role component, something like: # Role X - name: deploy conf files callrole: common::deployconf args: name={{ item.name }} val={{ item.val }} with_items: - { name: 'conf1', val: 33 } - { name: 'conf2', val: 42 } Where callrole::conf corresponds to roles/common/tasks/deployconf.yml. This might allow for more powerful constructs than is available by simply using include.
BadassFractal 12y ago
Same here, Puppet was awful, Ansible was a real breath of fresh air, I could actually get stuff done finally.
23david 12y ago
Is there a reason why Ansible fans feel it's important to hijack unrelated DevOps tooling articles on HN and chime in about how awesome they think Ansible is? It just seems rude, and reinforces the image that the Ansible community is elitist and intolerant.
- skywhopper 12y ago
  I'm guessing there's a glut of such comments because most people comment with their first gut instinct to a topic, and a lot of Ansible users' first gut instinct when they hear "Puppet" is "Ooof, glad I switched to Ansible." This particular link is sort of hard to comment on, because it doesn't really say anything about what's different in Puppet 4.0. So there's not really a way to comment on the substance.
skywhopper 12y ago
Yep, in my experience, Ansible is less fragile, more flexible, easier to get started with, easier to scale, and easier to learn. It has its frustrations, but they feel minor compared to what Puppet and Chef put us through.

by smegel 12y ago

Sorry, switched to Ansible last month and haven't looked back. Edit: Actually I have looked back, in horror and disbelief that I put up with Puppet for so long.

stunthamsterio 12y ago

Same here. I've used Puppet for years and I've even written a book on it. I dropped it completely within days of using Ansible, to me it betters Puppet in just about every way I can think of.

quicksilver03 12y ago

I'm contemplating switching to Ansible as well after 3 years of using Puppet for my personal and company infrastructure, I feel that Puppet has become too complex and that I use no more than 10% of its features.

cheald 12y ago

Same, except with Salt. Puppet is a large, unwieldy beast by comparison. Salt is like puppet, except not horribly frustrating to use.

WestCoastJustin 12y ago

For anyone wondering what Ansible is, or what is allows you to do, here's a basic overview screencast I put together [1]. Cannot recommend it enough, as the barrier to entry is simply so small, that you can get up and running in no time. The 250+ built in modules are also a killer feature, no hunting around for added logic to make things "just work" off the starting line. I kind of think Ansible hit a sweet spot, coming to market after Puppet/Chef, in that they learned from the ecosystem, and adapted their tool for the pain points. There is also no reason you could not use Puppet with Ansible (rolling upgrades, quick patches, etc). Happy to answer any questions too. PS. Bit of a disclaimer: The screencast is a four part series, the first episode is free, and the remain three parts require a subscription. Did not want to bait and switch you. The first episode will give you enough to know what Ansible is all about though. [1] https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...

smegel 12y ago
If you are an Ansible dev, I actually do have a question. I am a bit stumped as to how to "call" a role from other roles with different variables, so as to deploy the same template with different parameters. Currently I am putting the template in a separate role (with a task to deploy it), and then including it several times from other roles, e.g. # role X - include: ../../common/tasks/foo.yml # deploys ../../common/templates/my.conf.j2 - vars: x=33 # role Y - include: ../../common/tasks/foo.yml # deploys ../../common/templates/my.conf.j2 - vars: x=42 Is there a better way to do this? It would be nice to be able to "call" a role/task with parameters, to be able to reuse common elements like templates and task logic.
- BadassFractal 12y ago
  You can pass parameters to roles: http://docs.ansible.com/playbooks_roles.html#role-dependencies http://docs.ansible.com/playbooks_roles.html#role-dependenci...
  - smegel 12y ago
    I was somewhat aware of dependencies, but they don't really do what I want. I want to be able to execute a role (or task within a role), much like calling a function, that will be executed at the point it is called (dependencies are all executed before the role executes. I may also want to call the "function" multiple times within a role, with different parameters, to, for example, deploy a template several times to different named files. And yes, dependencies can execute roles multiple times, but this is business logic that belongs in the main role file, not in a meta file. And from what I can see, dependencies can only call a role as a whole, not a part (or task) therein. Basically what I have with "include" does exactly what I want, but it would be nice if it was a bit more explicit that I was calling a role component, something like: # Role X - name: deploy conf files callrole: common::deployconf args: name={{ item.name }} val={{ item.val }} with_items: - { name: 'conf1', val: 33 } - { name: 'conf2', val: 42 } Where callrole::conf corresponds to roles/common/tasks/deployconf.yml. This might allow for more powerful constructs than is available by simply using include.

BadassFractal 12y ago

Same here, Puppet was awful, Ansible was a real breath of fresh air, I could actually get stuff done finally.

23david 12y ago

Is there a reason why Ansible fans feel it's important to hijack unrelated DevOps tooling articles on HN and chime in about how awesome they think Ansible is? It just seems rude, and reinforces the image that the Ansible community is elitist and intolerant.

skywhopper 12y ago
I'm guessing there's a glut of such comments because most people comment with their first gut instinct to a topic, and a lot of Ansible users' first gut instinct when they hear "Puppet" is "Ooof, glad I switched to Ansible." This particular link is sort of hard to comment on, because it doesn't really say anything about what's different in Puppet 4.0. So there's not really a way to comment on the substance.

skywhopper 12y ago

Yep, in my experience, Ansible is less fragile, more flexible, easier to get started with, easier to scale, and easier to learn. It has its frustrations, but they feel minor compared to what Puppet and Chef put us through.