[mmerickel]

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 can avoid being a second-class citizen to the persistent, non-standard zeromq sockets.

That being said, ansible configuration files are fairly hacky and conceptually just don't quite fit. Some modules support a full yaml-dict whereas others need the string with key=value parts. Sometimes you need to wrap your jinja2 syntax in a yaml string to avoid it being parsed as a yaml dict. There's just some things that don't quite add up so there's definitely room for improvement.

I think I'll live with it until I gain confidence with nix though!

[harshreality]

Salt devs don't have any reason to make salt-ssh a second-class citizen, because they're working on a third transport. Everything's going to be (mostly, already is) abstracted from the transport so that salt-ssh, zeromq, and raet (the new transport, a kind of hierarchical distribution of messages to deal with massive deployments where the zeromq one-master-to-all-minions setup has scaling problems) are interchangeable. Also, raet uses CurveCP rather than rolling their own crypto, minimizing area where they can screw up enc/auth.

[existencebox]

This is good in theory, but in practice, there are known bugs against salt-ssh for which certain operations and states don't seem to work properly. (At least one of which I believe I pushed.) In hindsight (The problems I ran into with it were rather early into my multi year salt experience) it's highly possible in my naivety I was trying to do something that's simply not supported like tying some ext pillar in or something, but I have strong memories of bigger problems... (Wish I had a better recollection, but it's been a while)

The long and the short that this rambling was meant to convey: Salt is still very much in development. There are multiple open bugs on multiple core features (win repo comes to mind) which simply do not work as documented, period. That being said, when I made the same decision process for the company I was sysadminning for at the time as the author is considering, I went with salt, (with much the same background knowledge), and even knowing what I do post factum, I don't think I would change that decision. (I can give more justification as someone who had to live with their choice if anyone is curious, but I feel like I'm already rambling a bit.)

[ryan_lane]

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.

[mpdehaan2]

ansible-pull is available for those that need to invert the architecture, though we're finding most users in companies who need autoscaling can afford Tower. Price points are definitely important in that regard, but ansible-pull does exist for those that would rather go the pure OSS route.

Tower is also free for up to 10 nodes. See my comments above about why we went that route - being able to build products versus having to become a consultancy or support outfit makes it easy to keep ansible to be easy to understand and rock solid, and most people are quite happy with that split.

[ryan_lane]

Open core also has its set of issues. For most open core products I've used over time the community starts creating alternatives to the proprietary products and the upstream slows its acceptance of open code. The upstream will also tend to spend most of its time working on proprietary features.

Whether or not tower costs money, it's still a worry of being a single point of failure for autoscaling, which is part of why we avoided masters.

[mpdehaan2]

We've never held back anything from Ansible, really. Rather, Tower is more of a product on top that provides some extra enterprise features that most of our user bases don't need (but they should try it, because they might!).

I think if you see things like Windows being part of Ansible proper, it's clear we're not holding that back. But there are also tools the OSS community can't build easily, things that involve coordination around database schemas and (ick!) status meetings and UX mockups.

Yes, communities can build them, but occasionally, just occasionally, companies can build them better. And this is one of those cases. Our business model basically funds Ansible and also makes Tower significantly more capable that way, and it only becomes something you need when you can afford it. And it's not so much because we're a company, because I've got tons of awesome folks working in 100% full time, and that's a lot of power to build good stuff. Most likely your company employs a few folks as well :)

So on the "open core" comment, Ansible won't, for instance, ever have proprietary modules. That's something we said we don't do. Ever.

As for Tower, the small guy isn't going to need it yet. He's probably ok with pure Jenkins fronting the show. The big guy probably needs it and a super-well-tested environment and a guy to call when it has issues.

I don't know anything about other communities you've been a part of, but I think our track record shows what goes where and people are comfortable with it. Ansible isn't open core. It's the real deal. We take that seriously.

Yet, I think the general assumption that all software has to be purely 100% open is flawed, but that in general, open source communities can build some things in GREAT fantastic ways, and certain layers do benefit from being free software. But companies need to exist. Including yours! (Though I do love me some Uber).

Anyway, ansible-pull is indeed an option if you wanted to go that wrote, or even doing image builds with Packer. Both popular options for immutable systems and/or autoscaling, sans commercial bits.

But is commercial software dirty? Heck no. Ask any SaaS company :)

[icebraining]

But is commercial software dirty? Heck no. Ask any SaaS company :)

The pedantic in me feels compelled to point out that commercial SaaS doesn't have to mean closed; the company I work for is a good example, where our products and service are based on an third-party AGPL licensed software called Odoo[1] (and are therefore AGPL licensed themselves).

In any case, we do use Ansible here, and are happy with it :)

[1] https://www.odoo.com/

[malraux]

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.

[markhellewell]

Not the person you asked the question of, but we’re building AMIs (and VMware images) using packer.io (via the masterless puppet provisioner). It works nicely and with a minimum of fuss.

[Rapzid]

You might want to look at the new life cycle states: http://aws.amazon.com/blogs/aws/auto-scaling-update-lifecycl... . That should make it possible to bootstrap via SSH now. as to whether or not you'd want to.. That's another matter :)

[mpdehaan2]

Actually all modules take the key: value form if you want to use that :) ... though if you need to pass structured data, you can't use the shorthand.