6 ms·

Puppet 4 is now production-ready

47 points by crypt1d 11y ago

smegel 11y 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 11y 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 11y 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 11y ago
  Same, except with Salt. Puppet is a large, unwieldy beast by comparison. Salt is like puppet, except not horribly frustrating to use.
- WestCoastJustin 11y 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 11y 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 11y 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 11y 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 11y ago
  Same here, Puppet was awful, Ansible was a real breath of fresh air, I could actually get stuff done finally.
- 23david 11y 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 11y 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 11y 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.
hanlec 11y ago
I've kept an eye on this space---automation is not my day job--and I have to say that I still cannot put my finger on Puppet or Chef or Salt or Ansible.
- duggan 11y ago
  Automation is my day job and I'm still not convinced any of them is a significant improvement over a well maintained set of shell scripts and Makefiles.
  - berkes 11y ago
    Automation is not my day job, and I am very happy that there are frameworks (I work with Chef) with communities that offer standards, guidelines and libraries for a well maintained set of shell scripts and Makefiles. Instead of having to build and maintain them all myself.
    - otterley 11y ago
      I've sadly learned that given enough time, you'll likely end up mostly using your own set of private cookbooks, even for configuring things community cookbooks already exist for. The quality of the community cookbooks varies wildly from "pretty good" to "toxic waste," and the likelihood of getting fixes upstream fast enough to reflect back into one's own environment is generally low, even for good maintainers. And Chef's strict adherence to X.Y.Z semver for cookbooks (even though cookbooks don't fit semver well) and inability to declare "my cookbook foo_prime can be used whenever cookbook foo is called" makes it near impossible to maintain your own branch while you wait for your fixes to make it upstream. This makes it difficult to try to get things done when you encounter a cookbook that just doesn't work quite right. The cookbook ecosystem is not yet mature enough at this point in time to rely on.
    - duggan 11y ago
      I agree that having standards and best practices is a boon, especially if they can be packaged up in an easy to use way. Like anything, Chef brings its own set of idiosyncrasies to the table. However, I don't like how it brings all of Ruby's idiosyncrasies along for the ride too. If you're not immediately comfortable and familiar with both ruby and the quirks of its ecosystem, you end up investing a lot of time into getting a development environment up and running (and having it reproducible by other members of your team). Most infrastructure tools, if they're any use, are rapidly evolving. Conway's law applies here, and the maintainability of Chef mirrors that of its ruby ecosystem roots - people tend to freeze dependencies rather than upgrade. That's an antipattern we don't need in infrastructure. Honestly I just think we can do better. For me, I'm not sure (read: I really don't know, I'm not being facetious) the costs outweigh the benefits, but for someone totally new, perhaps it helps them get stuff done faster.
girvo 11y ago
Is it weird that I've basically replaced Puppet/Chef/Ansible with Dockerfiles and Docker Compose?
- Nux 11y ago
  Not necessarily weird, but docker will not give you the same coverage and capabilities, we could invoke the "apples and oranges" comparison here.
  - Gigablah 11y ago
    I'm wondering about a possible execution mode for Ansible where instead of connecting via SSH and uploading/running each task, you dump each task in a shared volume and run them in a container with docker exec. Then you can commit the final result to an image.
    - Terretta 11y ago
      Like Packer? https://www.packer.io/intro/getting-started/provision.html https://www.packer.io/intro/getting-started/provision.html
      - Gigablah 11y ago
        I was under the impression that Packer was used to create machine images for EC2 and DigitalOcean, but apparently it supports building Docker images now. That's perfect! I'll have to make some changes to my pipeline :)
- sbt 11y ago
  I have too. After I moved to containers, the hosts themselves are so simple now. In fact, I just have a VM image I use for hosts, and then the devs make the container images running on them.
- hackerboos 11y ago
  Still need to provision your host.
gog 11y ago
I moved most of my projects to Ansible, but I have a project that is still on Puppet and I really would like to move on. The reason is that I need a centrally managed server where clients pull for changes because the clients are not online all of the time. Does anybody have experience with Ansibles pull model explained here http://jpmens.net/2012/07/14/ansible-pull-instead-of-push/ http://jpmens.net/2012/07/14/ansible-pull-instead-of-push/ ?

47 points by crypt1d 11y 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 11y 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 11y 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 11y ago
Same, except with Salt. Puppet is a large, unwieldy beast by comparison. Salt is like puppet, except not horribly frustrating to use.
WestCoastJustin 11y 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 11y 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 11y 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 11y 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 11y ago
Same here, Puppet was awful, Ansible was a real breath of fresh air, I could actually get stuff done finally.
23david 11y 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 11y 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 11y 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.

hanlec 11y ago

I've kept an eye on this space---automation is not my day job--and I have to say that I still cannot put my finger on Puppet or Chef or Salt or Ansible.

duggan 11y ago
Automation is my day job and I'm still not convinced any of them is a significant improvement over a well maintained set of shell scripts and Makefiles.
- berkes 11y ago
  Automation is not my day job, and I am very happy that there are frameworks (I work with Chef) with communities that offer standards, guidelines and libraries for a well maintained set of shell scripts and Makefiles. Instead of having to build and maintain them all myself.
  - otterley 11y ago
    I've sadly learned that given enough time, you'll likely end up mostly using your own set of private cookbooks, even for configuring things community cookbooks already exist for. The quality of the community cookbooks varies wildly from "pretty good" to "toxic waste," and the likelihood of getting fixes upstream fast enough to reflect back into one's own environment is generally low, even for good maintainers. And Chef's strict adherence to X.Y.Z semver for cookbooks (even though cookbooks don't fit semver well) and inability to declare "my cookbook foo_prime can be used whenever cookbook foo is called" makes it near impossible to maintain your own branch while you wait for your fixes to make it upstream. This makes it difficult to try to get things done when you encounter a cookbook that just doesn't work quite right. The cookbook ecosystem is not yet mature enough at this point in time to rely on.
  - duggan 11y ago
    I agree that having standards and best practices is a boon, especially if they can be packaged up in an easy to use way. Like anything, Chef brings its own set of idiosyncrasies to the table. However, I don't like how it brings all of Ruby's idiosyncrasies along for the ride too. If you're not immediately comfortable and familiar with both ruby and the quirks of its ecosystem, you end up investing a lot of time into getting a development environment up and running (and having it reproducible by other members of your team). Most infrastructure tools, if they're any use, are rapidly evolving. Conway's law applies here, and the maintainability of Chef mirrors that of its ruby ecosystem roots - people tend to freeze dependencies rather than upgrade. That's an antipattern we don't need in infrastructure. Honestly I just think we can do better. For me, I'm not sure (read: I really don't know, I'm not being facetious) the costs outweigh the benefits, but for someone totally new, perhaps it helps them get stuff done faster.

girvo 11y ago

Is it weird that I've basically replaced Puppet/Chef/Ansible with Dockerfiles and Docker Compose?

Nux 11y ago
Not necessarily weird, but docker will not give you the same coverage and capabilities, we could invoke the "apples and oranges" comparison here.
- Gigablah 11y ago
  I'm wondering about a possible execution mode for Ansible where instead of connecting via SSH and uploading/running each task, you dump each task in a shared volume and run them in a container with docker exec. Then you can commit the final result to an image.
  - Terretta 11y ago
    Like Packer? https://www.packer.io/intro/getting-started/provision.html https://www.packer.io/intro/getting-started/provision.html
    - Gigablah 11y ago
      I was under the impression that Packer was used to create machine images for EC2 and DigitalOcean, but apparently it supports building Docker images now. That's perfect! I'll have to make some changes to my pipeline :)
sbt 11y ago
I have too. After I moved to containers, the hosts themselves are so simple now. In fact, I just have a VM image I use for hosts, and then the devs make the container images running on them.
hackerboos 11y ago
Still need to provision your host.

gog 11y ago

I moved most of my projects to Ansible, but I have a project that is still on Puppet and I really would like to move on. The reason is that I need a centrally managed server where clients pull for changes because the clients are not online all of the time. Does anybody have experience with Ansibles pull model explained here http://jpmens.net/2012/07/14/ansible-pull-instead-of-push/ http://jpmens.net/2012/07/14/ansible-pull-instead-of-push/ ?