3 ms·
I still use shell scripts because I don't have the time or energy to invest becoming a domain expert in installing packages. When my shell scripts become unten
by agentultra 13y ago
I still use shell scripts because I don't have the time or energy to invest becoming a domain expert in installing packages.
When my shell scripts become untenable I happily hire someone who is an expert at installing packages on a cluster of machines.
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.
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. :)
update: 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.
- giulianob 13y agoI was on the same boat until Ansible. It's so simple to use. If you have a couple of days to spare, you will pretty much know almost everything you need to. It also doesn't require setting up any infrastructure so you don't have to worry about spinning up some master server.
- mpdehaan2 13y agodisclaimer: author of project here. Achieving a middle ground was one of the points of creating the project -- making configuration tools more accessible to everybody, that you can forget and come back to in six months and still know how to work with. I definitely would be interested in your feedback after your trying things, but I think that's exactly the point Matt was trying to make in the article.
- agentultra 13y agoWell the proof of the pudding is in the tasting... I will have to give it a whirl I suppose. Chef/puppet/etc seem easy on the surface when you're getting your feet wet. I find that the complexity monster rears its head when you have to start supporting multiple OSs and combinations of configuration options. Shell scripts fail in this area too but it's generally much easier to find the problem than a morass of metadata files, recipes, and specifications. I would be more than happy to provide feedback (being the curmudgeon that I tend to be). I appreciate attempts at reducing complexity. I've been meaning to look into Marelle a bit (http://larsyencken.github.io/marelle/ http://larsyencken.github.io/marelle/) as I find logic programming and CBS to be where CMs should be heading. Is Ansible somewhere along that spectrum?
- mpdehaan2 13y agoAnsible doesn't seek to be programming, so my guess is no. I generally am not a fan of that syntax and would disagree that that is the way most administrators and developers brains work -- but I guess I can see it for some who do think that way. Multiple OSes are pretty straightforward though. Look at the 'group_by' module for dynamically carving up machines based on operating system, and things like the 'when' statement for introducing conditional behavior. Variables can also be overriden based on groups, so you can define defaults in one group and then have different settings in other groups.
- mattjaynes 13y agoI totally understand where you're coming from. That's actually why I wrote this. Many of the existing tools just don't have the ROI for smaller systems. The exciting thing is that there are new tools to choose from that have dramatically lower barrier to entry. I'd encourage you to check them out when you have a chance. Also, would love to hear if you ultimately use one, please feel free to email me.