I still use shell scripts because I don't have the time or energy to invest becoming a domain expert in installing packages.<p>When my shell scripts become untenable I happily hire someone who is an expert at installing packages on a cluster of machines.<p>It's a complex problem and CMs so far are complex enough that I'm put off by how dense the CM language is. Every time I come across chef my ears start leaking precious brain fluid. Recipes, cookbooks, knives, bags, dependencies, acronyms I haven't bothered googling for... there's enough there that someone can dedicate their time to mastering it and be paid a decent salary.<p>No thanks, I'm already spending enough time as it is being an expert in something else. I'll just stick with shell scripts because at least I can understand those without much effort. If they become a problem I'll hire someone to fix it. :)<p><i>update</i>: That was a little rant-y... after reading this article I might try Ansible if I get the chance. The problem I have with CMs is that they tend to be very complex because they solve a complex problem. Shell scripts tend to be simple (but crude by virtue). I am curious whether there is a middle-ground.
This article will be preaching to the converted for many of you, but I still see so many folks still doing manual installs and shell scripts even for large companies that I felt I needed to try and convert a few more folks over to saner systems.<p>Fortunately Ansible has dramatically lowered the learning curve and now is a great time to make the switch. So, if you have friends that need an "intervention" from their manual installs, hopefully this will help you make your case to them :)<p>Of course there are many great config mgmt tools out there. I singled out Ansible because it's so simple to get started with and I've found that the learning curve is usually the biggest hurdle to adoption.
I've used a lot of various configuration management systems over the years - CFengine, BCFG2, Puppet and now Ansible.<p>Two notes-<p>1)
They all work well for the base cases, and make it much easier to handle hundreds of machines - Being able to say "Ensure libcurl is installed on appserver, and make sure that nagios has these plugins we wrote" is amazing.<p>But where every system starts to break down, is when we have setups that I have a good reason for, but don't fit into the preconceived notion of how to handle things.<p>For example, if I want to install a package from source, or if I want to manually wget a .deb from an internal server, then dpkg -i it.<p>What's nice is that most systems allow some flexibility - You can do 90% of things in the pre-written modules, and break out to do manual commands where necessary.<p>2)
One thing I'd really like to see, though, is a system which operated with even LESS intelligence.<p>Rather than using YAML files, or any sort of "user-friendly" config, let me define variables and use pure Python to iterate and execute using them.<p>I'd love to have people give me pre-written modules as classes I can call, but having that exposed in a way I can get at it with native loops, if/then, etc, would make things a lot more straight forward.<p><pre><code> for server in webservers:
server.ensure_perms('/var/lib/somefile',755)
if server.name in qa_servers:
server.ensure_line('/etc/profile','EXPORT RUBY_ENV=QA')
</code></pre>
I know I can write modules to do this, but it'd be awesome to do away with the concept of cookbooks, and let me just write everything in a more straightforward language.
As someone who has written utilities to check for configuration changes presented by packages systems when they update, glossing over this issue is a bad idea.<p>Having a unified configuration that you can track and push is good, but if you are installing from RPM or DEB, you want to know if the package is pushing a new config itself, or providing a new config for review.<p>The utility I wrote looked for .rpmnew and .rpmsave save files and checked with a central repo for whether they were whitelisted (by MD5) or not. Anything not whitelisted resulted in mail being sent alerting admins. Along with an fairly comprehensive per-host auto-update exclude list (which I got yum-autoupdate patched upstream to allow), this allowed us to be fairly confident in allowing our 100+ boxes to auto update every day.<p>Without paying close attention to packages release notes, interesting things can come down from the maintainers, usually from them back-porting a fix from a later version (or a feature, if it's a RHEL point release).<p>I think configuration management is a good thing, but I'm not sure it's the best thing to be taught <i>first</i>, unless there's mentors to work with. Some things you just won't think of until it's bit you in the ass, and have that bite be at small scale until you've figured it all out is probably a good thing.
A coworker and I needed to get an ElasticSearch server up using chef, and the whole time we were complaining that we wished we could just use shell scripts.<p>So, we spent a friday and came up with <a href="http://fuckingshellscripts.org" rel="nofollow">http://fuckingshellscripts.org</a>. At first it was just a parody, but then it started to get real after we found a lot of value in just using shell scripts for simple servers.<p>Granted, we now use ansible and it has been far easier to implement than chef!
I think your ansible example could be improved by removing all the names.<p><pre><code> - name: Ensure https support for apt is installed
apt: pkg=apt-transport-https state=present
</code></pre>
smells a little bit like:<p><pre><code> // add one to x
x += 1;
</code></pre>
Additionally, I would far rather see "apt: pkg=apt-transport-https state=present" in my logs than "Ensure https support for apt is installed"
This is a bit OT because the article is about configuring servers, but I wonder if anyone has found CM systems like this helpful for maintaining their desktop or laptop system configurations?<p>Every few upgrades of Ubuntu I seem to get into a situation that I want or have to do a clean install, then waste time getting the new system back into a workable state. It would have to be pretty lightweight and intuitive for my purposes.
> Which method supports easily templating your configuration files?<p>But you don't actually use templating. You just copy the file over.<p>What do you do when you have to edit the configuration file? When it needs to be different on every machine for whatever reason (IPs to listen on, hostnames)? What is the smart way to do that automatically?
In my opinion, ansible only beats puppet here in ease of initial setup. I even find the equivalent puppet script for this task to be a tad bit clearer. But we're talking just syntax now. I only see now just how similar puppet and ansible (and perhaps chef too) are. What with the ensure'ing and all.<p>Puppet is a bit difficult to setup (not too much, mind you, it does its own key generating and being a PKI on first setup just fine, and you can run it from its own internal webserver until you have to go all "webscale"), but after that it hums along nicely. Haven't had too much complaining to do.<p>Except that they changed the string escaping rules somewhere in the 2.7.x branch, which debian of course pushed because it's in the same point release. That was fun.
This article doesn't do a very good job of stating it's thesis: The ansible version is no fewer lines than the shell script version; but requires you to understand ansible and how it works.<p>It doesn't seem preferable to me, from this example.<p>Note, I don't need to be convinced of the benefits of configuration management in terms of reproducibility and reliability. I'm just saying the OP's examples don't really make the case it suggests they make, of showing how ansible is so much easier than shell scripts. It does not appear to be.
Does ansible have some sort of REPL so I can use it for both manual administration and automated? I use shellscripts for a lot of stuff because they're just bash one-offs with seniority.
The important concept here is Reentrancy [1] and versioned code.<p>If the configuration is small enough it's easier to write a script in bash that approximates the re-entrancy well enough instead of having to bootstrap the configuration manager, distribute the description files and execute it. In fact a bash library could go a long way covering the scope of these tools.<p>[1]: <a href="https://en.wikipedia.org/wiki/Reentrancy_%28computing%29" rel="nofollow">https://en.wikipedia.org/wiki/Reentrancy_%28computing%29</a>
Can anyone discuss their experience with Ansible versus Chef + knife-solo?<p>I found Chef clumsy and hard to set up on its own (its central server requirement seems like it was designed just to support a business model), but with knife-solo it's extremely usable.
What seems to be missing is _updating_ the nginx.conf with sed or something.<p>In the article, you're just copying a new magic configuration from somewhere vs. "proper" sed use (in reality, it can be a bit more than that) in the shell script.