Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Puppet: SaltStack or Ansible?

ryandlane.com

Post reply on HN
Print view View original

81–90 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#81

Post by sandGorgon »

I wish that Ansible would work with orchestrating Docker containers.

Here's my thought - Docker is replacing the use case for using Ansible/Chef/Puppet for a lot of people. It is far too easy to build portable docker machines and deploy them on bare metal. For me, the use case of provisioning a softlayer server and then setting it up using Ansible/Chef is no longer present.

However, the problem of orchestrating a bunch of Docker machines is still unsolved. I was hoping that Fig would solve it, but by their own admission [1], Fig is going to be closely tied to Orchardup and not intended for general use.

So, if I want to launch a hadoop cluster over 20 Docker VMs, physically hosted in 5 different servers... I really have no way today. Notice, that the complexity includes setting up bind-volume mapping, logging, passing of variables from one Docker VM to another, etc.

I'm not sure if Chef is more suited to this, given that Octohost moved from Ansible to chef for a Docker PAAS [2], but I would definitely love for Ansible to do this part really well !

[1] https://news.ycombinator.com/item?id=8075705

[2] https://news.ycombinator.com/item?id=8086092

Re: Moving away from Puppet: SaltStack or Ansible?

#83

Post by stonith »

sandGorgon wrote: post #81

I wish that Ansible would work with orchestrating Docker containers. Here's my thought - Docker is replacing the use case for using Ansible/Chef/Puppet for a lot of people. It is far too easy to build portable docker machines and deploy them on bare metal. For me, the use case of provisioning a softlayer server and then setting it up using Ansible/Chef is no longer present. However, the problem of orchestrating a bun…

You might be interested in the Openstack deployment tooling called 'tripleo'[1] which has similar questions and has avoided all the current config management tools. The general gist is that what you're describing can be done using tools like Cloudformation/Heat or the newly minted Terraform, since they can both orchestrate the hardware/cloud resources and pass data in/out of the guests.

[1] https://wiki.openstack.org/wiki/TripleO

Re: Moving away from Puppet: SaltStack or Ansible?

#84

Post by dkarapetyan »

mrmondo wrote: post #82

IMO, Chef > Puppet > Ansible I wouldn't go near salt

Salt is also ok I think. I don't quite understand custom DSLs though for configuration management. Giving users a library of idempotent code components like chef does I think is way better than a custom language that is almost but not quite or maybe turing complete. At some point you are going to want to iterate and loop over stuff and if there is anything that ant has taught us is that imperative things are better handled with imperative language constructs. Trying to shoehorn everything into a declarative format is the wrong approach.

Re: Moving away from Puppet: SaltStack or Ansible?

#85

Post by wernerb »

> No masters. For Ansible this meant using ansible-playbook locally, and for Salt this meant using salt-call locally. Using a master for configuration management adds an unnecessary point of failure and sacrifices performance.

There are two models for delivering state to your infrastructure nodes. Pulling and Pushing configuration. Ansible Pushes code from the controller to your nodes, while salt, puppet and chef all pull state from a master somewhere.

Like twic says, Ansible does not have a master. The original author says no masters means faster performance. What he means is that pulling configuration from a remote checkout equals faster performance, which is true because it can be loadbalanced etc.

A chef/puppet master can have features such as search and service discovery that should be a large red flag for SPOF problems.

Re: Moving away from Puppet: SaltStack or Ansible?

#86

Post by dkarapetyan »

Kiro wrote: post #80

May I ask why people think Puppet sucks?

It layers a custom DSL on top of a perfectly adequate language, uses standard terms like classes in non-standard ways, takes away the linear top/down flow that most programmers are used to, forces sequencing through notification chains, steamrolls over error messages willy-nilly, etc. Although I'm a bit biased so a few more data points would be helpful.

Re: Moving away from Puppet: SaltStack or Ansible?

#87

Post by wernerb »

sandGorgon wrote: post #81

I wish that Ansible would work with orchestrating Docker containers. Here's my thought - Docker is replacing the use case for using Ansible/Chef/Puppet for a lot of people. It is far too easy to build portable docker machines and deploy them on bare metal. For me, the use case of provisioning a softlayer server and then setting it up using Ansible/Chef is no longer present. However, the problem of orchestrating a bun…

Fleet part of CoreOS does orchestration by leveraging systemd. I am actually working on stateless deployment of interdependent docker containers by pushing docker state to VMs much like Ansible.

Re: Moving away from Puppet: SaltStack or Ansible?

#89

Post by twic »

wernerb wrote: post #85

> No masters. For Ansible this meant using ansible-playbook locally, and for Salt this meant using salt-call locally. Using a master for configuration management adds an unnecessary point of failure and sacrifices performance. There are two models for delivering state to your infrastructure nodes. Pulling and Pushing configuration. Ansible Pushes code from the controller to your nodes, while salt, puppet and chef all…

But Ansible doesn't have masters! It has a machine where you run Ansible. But that can be any machine, as long as it has Ansible installed, the Ansible code checked out, and an authorised SSH key. If your usual machine goes down, just check out the code and run from a different machine. The idea that you need to use local playbooks to use Ansible masterlessly just seems mistaken to me.

Moreover, any scheme which involves running local configuration (whether in Ansible, Chef, or Puppet) involves either pushing configuration updates to machines, or having the machines poll for configuration updates, in which case it's no different to running remote configuration or having a master, respectively.

I don't get the point about open ports. Are you running machines without SSH? If you are, well done. But if, like most people, you're not, then you already have all the port you need open.

Post reply on HN