• Post Reply Bookmark Topic Watch Topic
  • New Topic

Need advice on configuration management software  RSS feed

 
Daniel Levine
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm looking for open-source configuration management software that
- Supports both Linux and Solaris
- Makes it easy to automate the installation of software from source
- Will not be too painful to migrate to; hopefully as a gradual process, with new managed VMs slowly replacing the old ad-hoc ones

So far I've looked at Ansible (somehow having trouble figuring it out...) and bcfg2 (seems very inflexible re the second requirement, and documentation is a bit iffy). I also know a bit of Puppet already, though I'm not by any means well versed with it. I've taken a look at Chef, but just could not wrap my head around it for some reason.

I wish I could keep working with plain SSH and shell scripts, but I think my coworkers and I are already at the point where we're hitting a scalability ceiling. Basically
- We don't have a concept of state, so every application of a set of scripts is a big time-wasting deal
- We don't have a way of rolling back changes
- A lot of failure conditions are not detectable without actually running the scripts, and when they fail we have to start over again
- Maintaining idempotence is difficult
- The whole thing is just incredibly fragile, and subject to obscure silent failures when people mess up
- People are unwilling to run scripts over SSH if they can get away with doing stuff manually, due to the time it consumes and the tendency to break stuff
- Even assuming we could fix all this, we'd have to reinvent several wheels in the process

So yeah, I think we have some issues. But it is going to be hard to sell anything new to The Management, especially if it's something that everyone has trouble figuring out vs. the seductive ease of shell scripting.

Any thoughts? I'm thinking I should just go with what I sorta kinda know (i.e. Puppet) but Puppet apparently has a reputation for creating a demand for specialists, so that might be even harder to convince The Management about...
 
Tim Cooke
Marshal
Posts: 4044
239
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I went to a local DevOps event a couple of weeks ago and they did a good little talk on using Puppet and Vagrant to 'codify' your build and deploy instructions. Puppet was used for the deploy instructions and Vagrant for bringing up and tearing down virtual machines.

It really didn't look that tricky so I wouldn't imagine you'd need any "specialists" to come in and sort it out for you. Integrating it into a Continuous Deployment setup will let you know pretty quickly if you've broken your deploy.
 
Daniel Levine
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I finally got around to looking at some Chef recipes... They made my eyes bleed! 130 files, 80 of them recipe files, just to configure Apache. I can't imagine managing anything like this without an IDE designed for the purpose. Argh.

Ansible playbooks were similar. Lots and lots of files in a deeply nested directory structure. I have no idea how people keep track of this stuff. The cognitive overhead must be absolutely gonzo.

It seems to me there has got to be a better way. Scripting language maybe? Python? Something a bit closer to the shell, but with try/except functionality?
 
Tim Holloway
Saloon Keeper
Posts: 18795
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chef is a programmatic provisioning system and while it's certainly popular, I prefer a declarative solution for things like this. The weakness of programmatic systems is their strength. Meaning that you can code whatever you want, but at the price of coding bugs. And bugs in provisioning can do horrible things to large numbers of servers in a very short interval.

Declarative systems have a fixed syntax and rule relationships, so it's easy to scan them beforehand and catch many common mistakes. Also, you don't have to be an ace programmer to code rules. Usually.

So I'm a puppet fan myself. Although the puppet docs aren't always as obvious as they ought to be, and configuring Apache is a prime example of where they assume you know what needs to be done at the higher levels so they only explain the lower-level stuff.

Ansible's speciality is that is is an agent-less "push" system. Puppet and Chef rely on having a client agent installed that "pulls" the maintenance into the client and applies it. It's not actually all that bad as far as specifying stuff goes if you're OK with YAML, but again, I prefer Puppet, which I think is tidier. However, Ansible is definitely useful for doing the initial push of the Puppet agent out to a new client!

I don't install software from source, myself. I build RPMS, debs, or Solaris packages as part of the prep work for production (Jenkins can help, but I used to do fine with just Ant). Even my JEE modules are RPM-packaged, since that allows me to do whatever setup needs to be done external to the server, such as building work resource directories. There is/was a tool that could generate Solaris, RPM and deb from a common spec file, although it had its limitations. I'm not sure of its current state, since I no longer deal with Solaris in production.

There are also, of course, systems that work on the idea that your applications and servers should be built as prototypes and replicated as needed. Stuff like Docker, pre-packaged VMs (Vagrant), and full cloud solutions. My project this week, in fact, is to work with the Apache stratos Paas (Platform as a service) system, which is geared towards scalable management of server systems known as "cartridges". It's huge, it's complex, it's not very tidy and I spent 2 days just trying to get Maven to build it. But it's popular in some circles, so I'm slogging my way through it. It used Puppet as its deployment tool, incidentally.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!