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

121–130 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#121

Post by shiven »

mpdehaan2 wrote: post #114
zwischenzug wrote: post #109

Earlier quoted context omitted.

"Everything I try to do in Ansible seems to turn into a shell script" This was my disappointment with Ansible (and other CM tools) - so why not treat the shell as the basic unit of action? See my post elsewhere on this page for more: https://news.ycombinator.com/item?id=8135823

This doesn't have to be the case. All resources in Ansible are declarative models of state, that get informed, and have idempotent properties. So it's just like any CMS. However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :) Also, when you want to just push and run a script versus using one of the 234 other modules, it's there - http://docs.ansible.com/scr…

However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :)

A thousand times this! I, personally, find YAML easier to grok than whatever Puppet was using (see, post-puppet PTSD selective amnesia). And, anything that doesn't work, on a deadline, can be shell scripted now and modularized later.

Re: Moving away from Puppet: SaltStack or Ansible?

#122

Post by mpdehaan2 »

staz wrote: post #117
cheald wrote: post #13

Earlier quoted context omitted.

"Pull request welcome" usually means "This is a legitimate bug, but I don't care enough to fix this for you." Some people believe that maintainers should fix all bugs that are reported to them. Other people believe that the open-source nature of the software should cause people to fix their own bugs and contribute the fixes back to the project, and both camps often believe that demands on their own time and effort ar…

This is not a problem of entitlement where people expect that you fix their bug for them. This is an anti pattern because many people consider this type of answer rude and it doesn't create a welcoming community. Saying "This is a legitimate bug, but I don't care enough to fix this for you." is already an order of magnitude more polite than "Pull request welcome" or the older "Patch welcome" , explaining in details w…

Yeah, but it's not the same thing.

This is a legit bug results in the bug staying open.

Pull requests welcome is "I feel this is a feature, but we'd be open to you working on it".

I think one of the great tragedies of the internet is people assuming people say things they don't mean.

And yes, building a great community is a lot of work, and it's something we spend a TON of time on. And it's why we have one of the most contributed to projects on Github.

Getting to 810 contributors is really hard, and you don't do it easily :)

Re: Moving away from Puppet: SaltStack or Ansible?

#123

Post by mpdehaan2 »

volume wrote: post #59
mpdehaan2 wrote: post #30

Earlier quoted context omitted.

Here's a blog about Ansible windows support for those interested: http://www.ansible.com/blog/windows-is-coming 1.7 comes out this week, and we're going to continue to improve it in 1.8.

I'm eagerly awaiting when the SSL cert setup is more streamlined and maybe encapsulated if possible? I could hack away at the powershell that MS makes available but if you guys are going to put work into it, I will wait even more eagerly for it.

We recently updated the docs to point to a new setup script you might not have seen yet - https://github.com/ansible/ansible/blob/devel/examples/scrip...

But yeah, stop by the -project or -devel list if you have questions or ideas for it, that would be great!

Re: Moving away from Puppet: SaltStack or Ansible?

#124

Post by mdasen »

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 want to look into Apache Mesos. I don't know it it works with Docker specifically, but it does manage Linux containers (which Docker is based upon).

Re: Moving away from Puppet: SaltStack or Ansible?

#125

Post by duebbert »

Interesting to see that Salt seems to have a slightly higher following here compared to Ansible.

I'm managing around 10-15 servers only but after having it all set up with Salt for the last year, I am now migrating it to Ansible despite it being a big hassle. I find it much more straight forward and am happy with the documentation so far.

Salt has bitten me twice in that after (non-master) server updates commands would fail with non-descriptive error message. I reported it as bugs but got too frustrated in the end and decided that with a new server I will start a migration to Ansible.

Very happy so far even though I do see the problems of speed (haven't investigated tuning it) and that it seems to require too many shell work arounds. But conceptually it seems much cleaner to me.

Re: Moving away from Puppet: SaltStack or Ansible?

#126

Post by crucialfelix »

mpdehaan2 wrote: post #114
zwischenzug wrote: post #109

Earlier quoted context omitted.

"Everything I try to do in Ansible seems to turn into a shell script" This was my disappointment with Ansible (and other CM tools) - so why not treat the shell as the basic unit of action? See my post elsewhere on this page for more: https://news.ycombinator.com/item?id=8135823

This doesn't have to be the case. All resources in Ansible are declarative models of state, that get informed, and have idempotent properties. So it's just like any CMS. However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :) Also, when you want to just push and run a script versus using one of the 234 other modules, it's there - http://docs.ansible.com/scr…

is CMS supposed to mean Configuration Management System ?

If so, that's a really awful re-use of a TLA (three letter acronym)

Many people still refer to any website that is editable as a CMS - Content Management Systems.

so please don't call it that, it will only sow confusion

Re: Moving away from Puppet: SaltStack or Ansible?

#127

Post by mpdehaan2 »

duebbert wrote: post #125

Interesting to see that Salt seems to have a slightly higher following here compared to Ansible. I'm managing around 10-15 servers only but after having it all set up with Salt for the last year, I am now migrating it to Ansible despite it being a big hassle. I find it much more straight forward and am happy with the documentation so far. Salt has bitten me twice in that after (non-master) server updates commands wou…

Not sure on trends, it's hard to say.

I think this is probably accurate-ish:

http://www.ryan-williams.net/hacker-news-hiring-trends/2014/...

Definitely investigate the tuning options. ControlPersist + pipelining does awesome wonders. We have pipelining off by default for max compatibility just so nobody gets stuck on an initial install, but feel free to stop by the list if you have questions.

Using "with_items" on yum/apt transactions also saves giant loads of time keeping things in single transactions.

http://www.ansible.com/blog/ansible-performance-tuning

Re: Moving away from Puppet: SaltStack or Ansible?

#128

Post by zwischenzug »

mpdehaan2 wrote: post #114
zwischenzug wrote: post #109

Earlier quoted context omitted.

"Everything I try to do in Ansible seems to turn into a shell script" This was my disappointment with Ansible (and other CM tools) - so why not treat the shell as the basic unit of action? See my post elsewhere on this page for more: https://news.ycombinator.com/item?id=8135823

This doesn't have to be the case. All resources in Ansible are declarative models of state, that get informed, and have idempotent properties. So it's just like any CMS. However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :) Also, when you want to just push and run a script versus using one of the 234 other modules, it's there - http://docs.ansible.com/scr…

I don't see the point of managing state at all. If it's stateful you're doing it wrong, and likely deploying it wrong too.

And if that's the case I don't see the point of a level of indirection outside the shell script. But that might be just me :)

I talk a bit more about this here:

https://www.youtube.com/watch?v=zVUPmmUU3yY

but it's quite heavily edited and a little out of date.

Re: Moving away from Puppet: SaltStack or Ansible?

#129

Post by mpdehaan2 »

darklajid wrote: post #76

I haven't looked at Salt, but I had a love/hate relationship with Ansible so far. To be clear: Starting with Ansible was amazing, the first couple steps were easy and enlightening. Maybe I'm expecting too much now and act entitled or something? That said, it broke down rather quickly. - My first issue was documentation. This article is correct about the current state of the documentation, but the site was in a really…

The docs reorg you mentioned happened Christmas of last year and most people are really really really happy with it now. We haven't done a major reorg sense or needed to, but the company was only a year old at that time, and it got to the point it needed to be done. Definitely took a while to appreciate all the different learning styles of people using the docs to find something that works for everyone and took some wrangling with Sphinx too!

I don't think it's fair to say we declined community help because one of the most amazing things we have in docs - the module docs generator that builds half the website, is a community addition. There were also various attempts to build Angular JS versions that looked crazy awesome, but the search engine problem wasn't solved at the time, so we were unable to use them.

I'm not sure why people don't like the template, but it's a common feature in Bugzilla - frankly, we spent so much % of our time asking what Ansible version was, this allowed us to service everyone's GitHub a LOT faster, and gives us the ability to work through everything so much faster and ensure better quality.

The bug template is important. As for lag in GitHub response, there's a priority system for tagging tickets, where we hit P2 items first, and then some others. Ultimately, we're devoted to stability and hitting the biggest things first, and have to avoid "hey look, a squirrel" syndrome. Part of the cost of having one of the most contributed to projects in GitHub in terms of users is does take a while to review everything and we spend a lot of time on triage.

Re: Moving away from Puppet: SaltStack or Ansible?

#130

Post by malraux »

ryan_lane wrote: post #37
mmerickel wrote: post #8

It's unfortunate that this article focuses on running the playbooks/salt states locally. The use of ssh by ansible was the killer feature for me. Configuring a remote cluster without requiring a persistent master. There are valid arguments for maintaining a persistent master, but it's just not in the cards sometimes. I know salt-ssh exists but it's still alpha, I look forward to seeing how it pans out and whether it…

I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master. We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.

How are you building your AMIs?

We're using Ansible and building the AMIs on a dedicated ec2 instance (started for a build and shut down afterwards). The AMIs are fully baked and environment information is configured via user_data in the launch configuration.

We use SSH to communicate with the build instance as a result, but I'd rather spend time during the build than during start-up of a new instance.

Post reply on HN