On Tue, 20 Mar 2012, Miles Fidelman wrote: > Tom Perrine wrote: >> I've used both cfengine and Puppet over the years, and have met people >> who have been successful with Chef. What has worked for others in >> their specific environment may (or may not) work well for yours. > > What I keep coming back to is that they seem like overkill for what I'm > doing right now - and carry with them the need to: > - install a layer of infrastructure > - work in yet another language (bash and sed do pretty much all I need, > why have to wade through recipes written in Ruby or Python or whatever)? > - do I really need to deal with lots of recipes to ultimately execute a > few install and config. statements (who really needs the overhead to > execute "apt-get install" or "./configure; ./make; ./make test, ./make > install") - at least for the stuff I'm managing now, the details are in > site-specific configurations, and it seems like a lot of getting that > right with Chef (or whatever) involves wading into and understanding how > the individual recipes work (or writing them)
It's useful to look at the benefits of configuration management tools beyond automation. As a small example, you can run your provisioning shell/perl scripts from within a CM framework as shell commands. What would be the point? Once your hosts are in a CM system you can leverage the existing tools to get the additional features you want. 1. You get inventory tools such as facter and ohai to report on the systems configuration in a standardized manner. 2. Most CM tools can store your hosts configuration in a central database to provide ongoing system inventory information. 3. You get reporting on the state of your hosts (Example: http://puppetlabs.com/puppet/related-projects/dashboard/). As you add checks for each script, you will see whether or not your hosts are compliant, when the script was run, and how long the script took to run. This information is recorded in a database for historical purposes. 4. There are tools such as foreman (http://theforeman.org/) that integrate inventory management/provisioning with your CM system. Foreman can control DNS and DHCP for you when you add a new host to the system. Foreman doesn't require that you use a CM system, but when you do, there is a single place to record the state each host should be in. 5. Going forward you may want to take parts of your scripts and move them into discrete clauses in your CM configuration. That will start to give you the version control and idempotence benefits that others have mentioned. 6. You mentioned that you like the power of perl+CPAN for application installation. One of the big gains in modern CM systems is the availability of modules or recipes. They provide a bundled set of functionality that you can then use in your CM code similar to the way CPAN modules can be used by various perl applications. A side benefit is that they often provide good documentation on deploying various applications. Some of my examples are Puppet specific because that is what I'm familiar with. Any of the modern CM tools should be able to provide equivalent functionality. By using a common framework rather than only custom scripts you get the above functionality for much lower cost than developing it yourself. You also get to leverage the future work of other sysadmins/developers who are writing new features within the framework. Thanks, Doug _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
