Chef is great for bigger architectures, but if your goal is to provision a limited set of servers and document it's configuration in a readable format, Ansible is truly fantastic.
check it out: http://www.nico.schottelius.org/software/cdist/
disclaimer: I work with the author, but not actually on the cdist codebase (not enough to brag about, anyway)
That might sound like a boring detail but it opens up many possibilities by doing things like asking all machines for their system time and then doing something with it.
Note that you might need to create the auth subfolder using `mkdir ~/.ssh/auth`, otherwise it might throw an error on connection: `muxserver_listen bind(): No such file or directory`
* More commits in github.
* More pull requests in github.
* Main website is ranked higher by alexa.
However, after using salt for a short while, I ran into a couple of problems (no mercurial state, no ability to specify versions when using a pip state), which ansible seemed to be able to handle.
So, I don't know... salt seems to be more popular. A bit. That's all I can tell.
It's also pretty easy to extend and the team who maintain Salt are really friendly and accepting of patches/pull requests.
We do strongly encourage squash commits so I wouldn't go by counts alone, but pick what tool you like to use most and that best fits your needs, and your style, and what you want to do with it.
I'd really appreciate a deeper comparison, though - especially if you feel that there are certain areas/circumstances where ansible may shine over salt.
Main thing on Ansible is the focus on multi-tier and process orchestration, without having to rely on coding up event paths between nodes -- admittedly it's a niche problem, but to me, deployment is as important as config management, and often harder. That being said you can write deployment in anything if you try hard enough, but I built what fit my brain and the particular needs of a few past companies deploying multi-tier web apps. While it is easy to have ad-hoc in the product (Puppet also does this with mCollective), it's a bit harder to be able to both model deployment and declarative state, and then make that into content you can hand over to a security auditor who doesn't know the language and he can say, yep, that's exactly what we want.
And 2.4+ nodes can be managed.
Once Python 3 is the thing everywhere I'm sure we'll have compliance. Ditto with, say, OpenStack which is also holding off. You kind of treat them as two different languages to a degree, if you still want to support things like RHEL 5 (2.4), you have to.
Specifically, they appear to be doing AES-CBC with HMAC-SHA256. There's nothing obviously wrong with it (randomized IVs from os.urandom, both authentication and encryption and with distinct keys...) but I would hope the standard for cryptography is higher than "nothing obviously wrong with it". Specifically, I would hope that the standard for cryptography is somewhere along the lines of using a peer-reviewed cryptosystem that has stood the test of time such as TLS, OpenPGP or even NaCl (given the name, particularly the latter would be pretty good). I'm not saying TLS doesn't have flaws; I'm saying appropriately configured TLS is better than rolling your own crypto.
I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.
Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic.
(Also, msgpack seems completely orthogonal to this issue.)
Yup, ZeroMQ doesn't support TLS.
Since it is, it really should have TLS support.
Can you please show me where that was the design decision that selected AES? Or are you just making an assumption that the code was not written by professional cryptographers and extensively peer reviewed?
AES-CBC is still a perfectly valid safe choice for implementations today. The most successful attacks against it, are ironically, due to OpenSSL's poor implementation. (http://eprint.iacr.org/2010/594)
This is a real community project. If you can see a way to improve something, just open a pull request on github.
Although it can do many of the same things as both of them, there are a few important differences. 1) By default, it encourages the use of YAML definitions which makes the codebase more readable/manageable over time. 2) It incorporates a first-class remote execution environment that replaces the need for parallel ssh or ssh almost entirely. 3) It leverages zmq as a data bus, and can easily transfer files or live data over the bus in multiple different topologies. 4) It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code.
Ansible shares a lot of similar characteristics, and it's great seeing both projects taking off. Definitely room for more than one system in this area, and everyone benefits from the healthy competition. It's not terribly complicated to have different systems manage different parts of your stack anyhow. You can easily use chef/salt/ansible all at once and use each project to manage different layers of your stack.
Just don't use capistrano... :-)
I disagree. If anything, Ruby is closer to Bash (in a good way, mind you) whereas Python's various syntax choices (white-space sensitivity, parens for function calls, some things only available as imported modules, etc.) makes it more different.
if [ `which foo` == "/usr/bin/foo" ]; then
if `which foo`.strip == "/usr/bin/foo"
if os.popen("which foo").read().strip() == "/usr/bin/foo":
I have only anecdotal evidence myself; I personally used to be a Python guy but now prefer Ruby; and some time ago my company hired a sysadmin/devops guy who came from Python, but grew to prefer Ruby once he started to learn it while working for us.
Considering that both Puppet and Chef are written in (almost entirely) Ruby, I would say that the sysadmin/devops field is currently leaning more strongly toward Ruby than Python. Although I'm sure bash dominates both.
Don't get me wrong, in terms of productivity and so forth, Python and Ruby are entirely on an equal footing.
from commands import getoutput
if getoutput('which bash') == '/bin/bash':
if [ -e '/bin/bash' ];
* Ruby has bashisms like `foo`; Python requires a function call.
* Ruby has a nesting syntax similar to bash with if/end; Python is whitespace-sensitive.
* Ruby has method calls without parentheses, similar to bash commands, whereas Python requires them.
> Although if your goal is to determine if e.g. bash is located in /bin,
Actually, that was not the goal at all. The goal (which, again, is irrelevant to my point) was to determine if the PATH-resolved executable binary "foo" was in a specific location. Rest assured that I would not use "which" in a real-life app. :-)
(Thanks for commands.getoutput(), my Python is rusty.)
> Just don't use capistrano... :-)
At one of my previous start-ups, we used to call it, "crapistrano". That is all!
Why are they doing this? Good question!
Their abstract mentions little about the algorithms they're actually using. For example, they mention "RSA authentication" but not what authenticated encryption mode they're using (looking at the code, it's encrypt-then-HMAC. At least their MAC comparison function looks constant time-ish)
I don't think the people who created this have any business designing an encrypted transport protocol.
As far as Func->Ansible goes, Seth Vidal (another one of the original authors) also does a lot of commits and wrote our yum module -- and is now using it for Fedora Infrastructure.
I wouldn't really recommend anyone look at Func anymore -- it's fading just a little bit (taken over by Steve Salesvan, also ex Red Hat), but it's still in use at places like Tumblr, which is a pretty large setup. Still, it was fun to do. We sort of did multiprocessing before multiprocessing.py :)
Adoption is going pretty well at the moment and it has been fun to watch. Several setups in the couple thousand of node ranges, lots around Big Data applications.
But I believe it's still in it's early stages and need to go way much much more. My colleague decided upon using salt instead of chef or puppet. I'm ok with this decision but had too made some tweaks and send bug fixes or features upstream while testing environment.
I believe there may be many more to come.
Still, it's easy to use, configure and also it's still really nice on the eyes with being python. It's trivial to make fixes to the code base.
It largely seems to be that a lot of these systems take their directives as nestable key-value pairs, so I think YAML is a good fit.
Amusingly, the first link someone posted on my blog post was to Salt. I didn't dig too deep at the time as it appeared to be more at the REF end of the spectrum to me.
This seems to be more in line with chef/puppet, with a dedicated daemon on the client.
I'm not saying that's a bad thing, but I see a distilled Puppet syntax there, where Ansible (http://ansible.cc) is more about modeling both resource states and ordered processes across machines.
Ansible actually uses SSH by default but there's a 0mq accelerator if you want to use it. We don't just execute individual SSH commands, modules are remote resources that model idempotent state -- but don't stay resident. The 0mq accelerator came later. There's also a pull mode, and a local mode in Ansible. Using SSH is nice because you don't have the additional PKI, and all that comes with having to maintain that. (No needs of accurate NTP and DNS either, and working with Kerberized SSH and using your OS credentials is possible). Need to do non-root things? You can do things (if you have permissions) entirely as non-root.
Furthermore, Ansible does not have a dedicated daemon on the client. It's daemonless, and consumes no resources when not running. When running with 0mq, the daemon is ephemeral, stopping after a set period of time, to not consume resources.
It also requires no bootstrapping, so if you have blank cloud images with nothing on them, or brownfield systems in the field, you can just start managing them immediately. cloud-init and so on are great for this, all cloud tools can inject keys. For this reason (no agents), it's starting to look very appealing on embedded devices and network hardware as well.
While implemented in Python you can write modules in any language. Finally, Ansible's core focus is around making multi-tier orchestration easy (somewhat of a niche case), so that leads it to look a lot different at the language/resource level. But if you have just one tier, you can use it too.
It's frequently used to deal with rolling updates involving N-tier applications with monitoring servers and load balancers all in play, though you can definitely use Ansible just for classical config management.
I think part of the reason Salt may look similar to Ansible is Salt is clearly inspired by Func, especially the minion/overlord terminology, globbing, minion-to-minion, etc, and I was one of the original authors of Func at Red Hat. We were toying around with a message bus Func at the time and decided not to do it.
So, yeah, lots of tools in this space.
In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!
The Rexify (or more precisely Rex) that I'm aware of is written in Perl - http://rexify.org/ | https://github.com/krimdomu/Rex