The devops "installer"
puppet and similar things are very nice tools for managing your systems. Rather than doing the same thing 100 times, it's much more interesting to spend some time describing how to do something, and then have it done hundreds of times automatically.
However, I'm starting to see a distressing trend lately. I'd like to say that puppet is not an installer, nor is it a replacement for one. Here's why:
- By giving me a script that calls puppet to install your software from the interwebz, you're making it very hard for me to install your software in case I'm running behind a paranoid firewall that I don't have access to.
- By giving me a script that calls puppet to install your software, and sets up things so it will try to run puppet agent against your server (presumably to keep my installation up-to-date), you're making it much more difficult for me to manage that system as part of my larger network, which is already being managed with puppet.
Please, pretty please, with sugar on top: just provide packages. If that can't be done, just provide clear installation instructions and/or a puppet module that I can include or something. Don't assume I'm a system administrator not worth his paycheck.
Thanks.
note: the gitorious example above is just that, an example. I've seen more cases of people doing similar things, not just gitorious. Surprisingly, it's mostly from people who're on the ruby kool-aid. I hope that's not related...
Update: (2013-04-18) despite my usage of buzzwords in the title of this post, I did not mean to imply that any of the above has anything to do with devops. Instead, what the post is supposed to say is that you should not fall into the trap of believing that devops methods, which may work wonderfully internal to your organization, will therefore also work wonderfully for processes outside your organization.
Some of us use other tools to manage our systems (either chef/cfengine/bcfg2/dyi or good old-fashioned manual labor).
Things like these kept me away from the Ruby ecosystem, TBH: a lot of people seem to assume you have the whole developer stack.
I liked the idea of “devops” when it came out. Seriously.
But nowadays it’s a buzzword which means half-baked solutions in puppet and ruby made by people who aren’t full developers and usually don’t have good admin experience either.
And, yes, it goes together with ruby.
I keep using working solutions that do not involve either; shell is so much nicer for automation, and everything else can just go into packages, metapackages and config packages.
When it comes to "configuration management" (by lack of a better expression), I don't believe in prebaked scripts. Those will never match the specs of your environment.
Prebaked scripts can be nice as a start to integrate in your environment, as a better instruction than some howto document, but in most cases you'll want to write your own.
I've been involved in ansible.cc lately, and I'm curious how their newest "roles" feature (now in 1.2-devel) will evolve, but I don't expect they will be that parameterizable to just be copy-pasted locally.
Puppet is indeed not an installer, also I can understand why some people do it disclaimer: all text below don't reflect MY opinion, it is just an explanation IMHO of why some people can use puppet as an installer.
Packaging skills are quite hard to acquire and you end up most of the time doing puppet or packaging. Mixing the two is not that common. E.g. a full installation can be done with preseeding + a small package that depends on everything you.
Packaging skills are specific to a distro. You package for Debian or Fedora. Doing both is not very common. Puppet provides you a way to do "something close to packaging" in a portable way (directory creation, ownership setting, user creation...)
Distro are generally not web-app friendly. Creating a DB is not straight (I know that there is dbconfig-common) and distro don't handle multiple instances of the web-app (e.g. setting up 2 blogs using dotclear) or installing the same set of files in 2 different directories, etc.
Setting up a signed repository for your distributing your own packages is not very common (although this is a weak point, because I think it is not that complex).
Getting any packages into a stable distro (be it Debian, Fedora or whatever) is a long process. So you probably don't want the latest version of ruby, but you want this fancy web-app that is just out since 3 months... What to do next (backporting ?).
-- stop of the disclaimer. back to MY opinion.
All these reasons are probably pushing some people to provide way to not package and just install from the interwebz the latest, not even yet backed, version.
BTW, you should also be concern by another trend, that I find even more concerning: not even releasing version! So when some upstream asked me to just take a random snapshot of their github repository, I am even more concerned.
It's from the set of people who've never really understood what the point of a distribution is.
And so they're patching together the concepts as they come across them with a glorified set of scripts.
It hasn't fallen apart yet because it hasn't got widespread big, complex & interdependent enough to do so.
(I expected this short-sightedness from the sort of people who were espousing autopackage back in the day and eventually resigned to the fact that they were making their own beds, but these people are supposed to be running servers for god's sake, with other people's data...)
Oh, I agree; I've written all my puppet recipes and modules myself, never used anything from puppetforge or the likes. Not that it isn't useful, I just never saw the need.
The point was this: I discourage the practice; but if you absolutely have to use puppet as an "installer", then please at the very least make it something I can easily integrate into my existing installer...
First of all I fully agree on providing packages as opposed to half baked crappy scripts that try to automate stuff for you they shouldn't.
Specifically the curl http://somehost.io/install.sh | sh stuff freaks me out ...
Secondly there's the topic of naming things .. imvho the stuff you described has nothing to do with #devops or the fact that they use Puppet It's just people being stupid ... (Frankly I've seen more of the exec install.sh type of approaches wich Chef people ... so .. no .. no comment on the Ruby involvement
And last but not least .... I provide a lot of puppet modules on github, for people to re (ab)use in any way they like .. the thing is for me this is documentation .. how did I install such and such application, and reusability Some of the vagrant boxen can actually be used to deploy some app in minutes .. but that's not the goal .. I want people to learn from them and give them a faster start a head to get going ... Which is exactly what most of the installlers should do ... help you get going ... not take you by the hand blindly as if they know the way around your house better .
To be clear, I did not mean to suggest that any of the "use puppet as an installer" or "here's a script, and no, we won't tell you what it does" boatload has anything to do with devops, at all, though I agree that my post is fairly ambiguous about that.
What I meant to say is that devops methods and tools (in casu, puppet) should be used internally to organizations; while they makes it easier for you to install and maintain your systems, you should not fall into the trap that therefore it is easier for people external to your organization to use your product.
I should probably clarify that.