Hacker News Reader

Comment by rurounijones | Hacker News Reader

> Doing this with Chef would probably mean chasing down a knife plugin for adding Linode support, and would simply require a full Chef stack (say hello to RabbitMQ, Solr, CouchDB and a gazillion smaller dependencies)

It is throwaway lines line that where you really need to be careful since, no, you don't need to RabbitMQ, solr, couchdb etc. You can just use chef-solo which can also be installed with a one liner (albeit running a remote bash script)

When comparing two products (especially in an obviously biased manner) you need to make sure you are 100% correct. Otherwise you weaken your case and comments like this one turn up.

View on HN

The thing with one liners is that it is cool when they work, hell when they don't. I'm looking at replacing Puppet (because it's orders of magnitude too slow). Chef was a viable candidate, up until I tried installing it on two pristine installs (Scientific Linux 6 and, when it failed, Ubuntu Server). The instructions seem simple enough:

http://docs.opscode.com/install_server.html

but when you run:

  sudo chef-server-ctl reconfigure

Chef goes into a frenzy of bootstrapping itself , installing a huge stack of dependencies, takes ages, only to fail with an obscure message in the end about one of its dependencies failing to start (RabbitMQ, if I recall correctly).

Can I work around the failure? Sure! But what does it tell you about a piece of software that its installer fails on two pristine different and common linux distributions? To me, it tells me that it is over-complex and poorly engineered. So, from a different perspective, I really identify with the "gazillion smaller dependencies" comment.

I helps me little that chef-solo is simple. I don't want chef-solo. I want a full config management distributed solution that is dependable (which probably requires lean).

My next candidate is Salt, and so far it looks good.

I'm curious - for what do you use SL? I had tried it at v4 and it did not seem superior to a 'standard' Fedora install at that time, even for scientific analyses (ROOT and GEANT were no different to install IIRC and there wasn't the same healthy package system that comes with Fedora). Has it improved in some way since then?

It's an historic left-over. My company uses CentOS, and back in the days of the transition to v6, CentOS was delayed. SL6 came out at the right time and we switched.

SL is basically the same as CentOS: a community version of RHEL.

That's exactly why I'm on SL6. The delay, and better maintenance prospects with SL than CentOS as Fermilab is committed to the project.

(I don't think we work at the same place, there aren't any likely Sergio's in the corporate directory)

Does Salt offer all the benefits of Chef server? To my knowledge, the former has no search engine nor any way to return feedback from the managed hosts. Shared storage is absolutely essential for building things like ssh_known_hosts files and Nagios configurations.

Ansible can trade data between machines using 'hostvars' as a variable, so you don't even need the analog of Puppet storeconfigs to assemble facts. (Sorry, don't now the Chef term).

Stop by the list if you'd like more info, but it's easy to generate nagios configs from templates this way.

Who stores hostvars? Does Ansible provide a way to extract a subset of them based on other hostvars? (e.g. "give me all the ssh host keys of my hosts in the intersection of datacenter X and hostgroup Y")

Ansible doesn't store them, but exchanges them in memory. (The assumption is you'd want them to be current anyway). We are going to add some optional caching (likely just requiring sqlite as it's all we need) in a future release.

But yes, it's easy to do that. Assuming you meant a template, you could do:

{% for host in groups["datacenterX"] %} {% if host in groups["Y"] %} {{ ssh_host_key_rsa_public }} {% end if %} {% endif %}

Ansible is also good at carving up groups based on these things, like if you just wanted to talk to those hosts:

hosts: datacenterX:&Y

note that Hacker News ate my newlines.

etc

note that Hacker News ate my newlines.

If you want to edit the post to include them, indent by at least four spaces the text for which newlines are important. Maybe like this:

    {% for host in groups["datacenterX"] %}
        {% if host in groups["Y"] %}
            {{ ssh_host_key_rsa_public }}
        {% end if %}
    {% endif %} [sic]

> Ansible doesn't store them, but exchanges them in memory (The assumption is you'd want them to be current anyway).

What happens if the server crashes? Can a subsequent run before all the data is repopulated cause the derived files to have invalid or missing data?

It's saving them in memory now so there are no files to corrupt.

When you run again it gathers all the facts from the hosts.

I'm in no way proficient in Salt. It does have shared storage and the ability to go through other nodes config data, though.

This video is a nice introduction: http://m.youtube.com/watch?v=jJJ8cfDjcTc

You can do that with Salt via the Salt Mine: http://docs.saltstack.com/topics/mine/index.html

I haven't used it myself, but I've been reading up on Salt quite a bit in hopes that I can replace Chef with it soon.

I haven't had trouble with installing Chef 11 server on Ubuntu.

As for installing a huge stack of dependencies: if we're talking about Chef 11, there's nothing to install. All of it is embedded into the omnibus package. It is configuring them.

It's too bad about the RabbitMQ. Have you submitted a ticket?

Be aware that Salt, for reasons passing understanding, implemented their own encrypted channel (instead of TLS) as an alternative to using SSH, and suffered a grievous vulnerability as a result. I'm not saying don't use Salt (I don't know much about it), but I would recommend using SSH with it, and not its custom transport.

TLS is not possible over zeromq by design. There is work to build encryption directly into zeromq, but it isn't there

(Disclaimer: I used to contribute a lot of code to salt and still do when I have the time)

Why wouldn't it be possible to run zeromq over a TLS-encrypted TCP stream? It looks like people have already built that.

I had a look at how Ansible does 0mq encryption the other day, they do key exchange over SSH and then use keyczar to encrypt data over the socket, so that doesn't look too bad. I didn't look at the key exchange or review things in depth, but, assuming keyczar.Encrypt() does the right thing, it shouldn't be too bad.

From the docs:

chef-solo is a limited-functionality version of Chef and does not support the following:

* Node data storage

* Search indexes

* Centralized distribution of cookbooks

* Environments, including policy settings and cookbook versions

* A centralized API that interacts with and integrates infrastructure components

* Authentication or authorization

* Persistent attributes

There is a project called "littlechef" which allow you to use part of the chef-server's features without chef-server.

https://github.com/tobami/littlechef

It doesn't seem to include node storage, so for example you'll need to include a mysql password because if it generates a random one, you won't be able to retrieve it.

(This may have changed since last time I tried it.)

I should point out that Ansible can store passwords on the filesystem here, using the 'password' lookup plugin. So while there is no database you can still easily access things exactly like this.

I love how the first result when you google "chef-solo" is a list of all the things that it won't do for you, all of which are stated in jargon that a beginner cannot understand.

It might be more direct to replace that page with a single sentence: "chef-solo: We're Not Interested And You Shouldn't Be Either."

Or, might we consider compiling a friendly list of the great things chef-solo could do for you? I was going to work on that, but now I'm tinkering with Ansible instead.

I don't know what's the opinion of other people, but for me chef-solo is not even a product on its own. If you use chef, but need to either bootstrap the server or prepare some system image - then going the way of stripped down / hacked chef is what you're looking for. And that's what chef-solo does.

But maybe it's more of a standalone tool for others?

I use chef-solo with Vagrant, I rarely use chef-server/client with Vagrant. My dev box rarely needs to separate out environments, for example.

You do not need to bootstrap Chef 11. You download a single omnibus package and run a single line to install it. All dependencies are already embedded into the package. Under the covers, it bootstraps itself, but from the end user's perspective, It Just Works.

Came here to say exactly this. chef-solo _is_ good, particularly combined with things like Vagrant and Berkshelf

To be fair, I don't think Ansible has any of those, either.

for that list of features, you either don't need it because of how Ansible works, or there's an inventory plugin for it.

We're also adding some neat things around authentication and access control in a forthcoming product release, if you do decide you want those kind of "serverey" things. See here: http://www.ansibleworks.com/ansibleworks-awx/

But yes, you don't need these, Ansible can exchange variables between hosts in memory without needing a database, etc.

Ansible is licensed as GPLv3. But it sounds like AnsibleWorks-awx is a commercial-only product? Are future 'pro' features going to only be released and maintained in commercial variants of AnsibleWorks or separate related projects? Would love more transparency about the relationship between open and closed-source products at AnsibleWorks.

I made a similar clarifying request on the Ansible user group forum a few weeks ago but my message was not approved. I believe that these are fair requests and deserve clarification.

How is that a fair request? Ansible is a GPL3 Python codebase. If the community doesn't like where AnsibleWorks takes it, they'll fork it.

We've posted quite a lot about this to the list in the past, I'm not sure what happened to your post.

Ansible is GPL, and we're totally going to keep it just the way it is, and continuing to make it more awesome. (The application is just invoking ansible-playbook).

Why is it commercial? A lot of the stuff we are building is mainly interesting to enterprises -- RBAC, reporting, things like that.

The core things everybody needs to use Ansible today, all the modules, are free software and we will continue to add loads more there. Ansible received over 50 new modules in the last 2 releases.

K cool. Thanks for clarifying. Keep up the good work. :-)

Can I ask why you chose GPL for Ansible? This makes it more challenging to integrate or embed Ansible in many types of commercial or non-GPL projects.

Chef [1] and Puppet [2] both chose the Apache license. Salt did as well.

If you were worried about competitors offering hosted versions of Ansible, I could understand going AGPL, but not GPL3.

Thanks!

[1]: http://www.opscode.com/blog/2009/08/11/why-we-chose-the-apac... [2]: https://puppetlabs.com/apache/

I come from Red Hat and I like the GPL, because it ensures the software remains free. I view GPLv3 as largely a language improvement on GPLv2, which makes it easier to understand and define how it applies.

Ansible being GPLv3 doesn't affect folks much. Your library modules can be licensed in any way you like, and it's fine to shell out and call ansible-playbook. AWX also exists as a nice API layer if you need a web services interface that abstracts you from the license question, so folks looking to do commercial integrations can tap into the REST layer.

AGPL is more restrictive than GPL, in some ways, as you can't use things in a hosted service. We didn't want to be that restrictive.

While AGPL certainly is more restrictive (that is the whole point of the AGPL after all) -- it does of course not prevent the use in a hosted service, it just has a requirement that the end user still has access to the source code (while with GPL you could change large parts of the Free code, and never contribute that back to the users, if you so chose).

As long as there is a REST bridge/layer, any service shouldn't be considered a derived work -- only changes to "core" Ansible would be "covered" by the AGPL.

I'm sure you know this, but it is an important point (just like the GPL never dictates that you have to contribute changes upstream, just to "your" users (which of course might include upstream, and most people feel it is more constructive to give back in the more general sense...)).

I've seen some strange (imnho incorrect) interpretations of the AGPL, hence this comment.

Right! It would prevent people from being able to use it in hosted services that didn't share the source, and we wanted to make sure people could easily use it in those things without any problems.

That's mostly just sales talk. The reality is that chef-solo works just fine for a lot of use cases, and that set of use cases has significant overlap with the use cases for ansible.

If a tree falls in the forest, but that tree is not mentioned in the documentation – indeed, if the documentation says something like "there's this forest, we used to live there, it's dirty and primitive and stuff, now all the cool kids live in Manhattan"...

The point is, the beginners never find the tree. They get lost, kind of like I've gotten lost in this metaphor, and they go try something else.

I would agree (if I understand the metaphor within a metaphor, that is) that documentation and best practices are probably the biggest weakness in the Chef community. Once you add in tools like berkshelf or librarian-chef where the tool creators recommend totally different workflows from those recommended by Opscode, not to mention the wide variety of testing stories... it's a mess. I've heard from someone at Opscode that fixing that mess is one of their priorities, but until then, it's definitely a problem.

Where we really need to be is a place where configuration management is just another part of application repositories (there's a parallel here to db migrations), so that web applications are completely self-contained. That includes versioning, unit testing, etc. I haven't yet seen any of the configuration management tools come forward with a solid unified best practice solution for treating applications this way, but there are a lot of people working in that direction, which makes me very hopeful for the near future.

FWIW, environments should be in the next release.

http://tickets.opscode.com/browse/CHEF-3356

Chef 11 doesn't use Couchdb, though it uses those other dependencies. However, you do not go and install those dependencies. You install a single package that includes all of that.

Chef client does not require RabbitMQ, Solr, or CouchDB. It too has an omnibus package that embeds all the dependencies and isolates it from the system.

Both server and client are now one-line installs as well.

True, though chef-solo is a local-only solution. Ansible manages to manage remote machines without that kind of setup, and can start managing the remotes without installing anything on them.

Install chef-solo on server.

scp locally dev'd (with vagrant ideally) cookbook to server

Run cookbook

3 steps that can easily be wrapped in a little script (which I know a large company does because I saw their presentation about it on confreaks. Sorry I cannot remember the name of the company or presentation but it was a chef related one).

Still not exactly killing it in terms of complexity. I would avoid comparing ansible to chef-solo in that respect and focus on bits where ansible has a clear (IMHO) win.

Having said that I should say that I have not used ansible and am basing this on what I have read about it.

You don't even need to do that. You can type `knife solo prepare root@my-server` and it will install chef-solo on that machine. Then type `knife solo cook root@my-server` and you're good to go.

Well damn, I have been doing it wrong. That is awesome to know though.

I wonder if anyone has done a http://todomvc.com/ equivalent for cfengine, puppet, chef, salt, ansible etc.

Something like a simple webserver running Apache with mod_xsendfile, Passenger, Ruby 2.0.0, postgreSQL and a few firewall tweaks (why yes, I AM mainly a ruby developer, why do you ask?)

https://github.com/devstructure/blueprint [generates] configuration sets for "Puppet or Chef or CFEngine 3."

https://en.wikipedia.org/wiki/Comparison_of_open-source_conf...

https://ops-school.readthedocs.org/en/latest/config_manageme...

Is there a way to have multiple "roles" while using those commands?

I mean all my servers are 70% identical and have the same base, and the DB have a few different packages than the app-servers for an example.

I would hate to have two different chef-solo installations that basically does the same 70% of the time.

I think -r allows you to select roles IIRC. Not sure if it allows for multiple roles, but you can include roles within roles so you can make a role called 'web' that includes 'db','webserver' etc

`knife solo bootstrap root@my-server` will run both prepare and cook commands.

Awesome! Thanks for that

(Replying to this comment as I can't to the other for some reason) It is indeed! That'd be a brilliant idea actually. Sadly I only have a very minor amount of experience using chef.

If you're interested though, I recently released our stack as a chef solo project at: https://github.com/FineIO/fine-io-chef

I think you're thinking of Ben Rockwood from Joyent: http://www.confreaks.com/videos/1684-chefconf2012-chef-behin...

If I recall, he made a comment to the effect of "Chef solo is great for really small deployments and really big deployments."

chef-solo does require ruby > 1.8.7, rubygems and many gems though. Their argument for ansible is that it only needs basic python which is installed by default on most systems.

Python and Ruby are located at basically the exact same point in programming language space, so to me they're pretty interchangeable. Since these are Ops tools, the argument that anything is 'installed by default' scares me. Nothing should be installed by default; choosing what is installed and how it gets installed is one of the major responsibilities of the Ops team.

This is more of a function of so many utilities written by Red Hat and Canonical folks use (and require) Python. And that's part of the reason Python is so popular among systems applications. One of the earlier starts to this was the system-config-* toolchain, and of course Anaconda (which isn't so much installed, but a great example).

Reply on news.ycombinator.com