This article is merely a cursory analysis of both systems as they are adept at managing the cloud, and not a comprehensive technical review, and focused on support for managing and provisioning cloud instances with a configuration management framework.Puppet and Chef are two configuration management systems that are gaining a lot of popularity and traction in the IT community for managing and automating one’s IT infrastructure, including servers, network devices, and applciations.
Background
A configuration management system helps you describe your IT infrastructure declaratively, and then ensures the desired configuration is enforced. Chef and Puppet are two newer configuration management systems that are gaining popularity due to their wide array of features.
In this article I have given a preview into both Puppet and Chef, two widely deployed configuration management systems, in the context of managing a cloud-based infrastructure. Both systems allow for managing cloud and traditional IT infrastructures, and both are robust systems which are excellent for managing complex IT infrastructures.
This article is not a comparison of Puppet versus Chef, which one is better for your environment, making a decision on a configuration management framework isn’t that easy, and differs for each organization. The goal; however, is to give some insight into what it’s like managing Cloud nodes with these various configuration management frameworks, and saving the reader a lot of time before they set out to do their own tests. If you are new to configuration management, and are interested in it’s benefits, I would recommend reading this email thread from the SAGE mailing lists for some background information.
In this review I am using CentOS version 5.5, which is basically the open source version of Red Hat Enterprise Linux. I chose to go with Rackspace’s CloudServers, because it was a more affordable option than Amazon EC2, and I find snapshotting my images to be a much easier process on Rackspace than on EC2, but both Cloud systems could be used interchangably in this test. Because these systems come with just enough operating system to run, there were a few dependencies which were not called out in the documentation which I have noted in each respective section for Puppet and Chef below.
The Test Case
My test case in both instances was to provision a new instance, and install an Apache Web server on that instance. There are many useful reviews out there on how to install and configure Puppet and Chef, so I am not going to go through that here. I have included links at the bottom of this article for your convenience if that is the information you are looking for. I used RPM packages to install both Puppet and Chef to get things up and running quickly for purposes of rapdily testing it’s ability to provision and manage Cloud instances, which was primary goal.
Puppet
Installation
For purposes of simplicity, I chose to install the enterprise version of Puppet, which allows you to install and manage two nodes without having to purchase any license keys. The enterprise installer prompts you for details about how the Puppet installation should look and then installs all of the dependencies and requirements for running a Puppet server and clients. The open source version of Puppet is also available for installation, although it requires more steps to get a working Puppet installation going.
The Puppet Enterprise installer is executed by downloading Puppet Enterprise and then executing the ./puppet-enterprise-installer command. On my system I ran into an error where /etc/mime.types was not present, so the installer failed. I insalled the mailcap package by executing yum install mailcap, and that resolved that issue and the installer was able to move forward without issue.
Configuration
Once Puppet was installed, we need to create a manifest file. I chose to edit the global defaults, which is most likely what you wouldend set up first to configure global settings to be enforced across all of your systems and applications. Manifests, classes and defined types can be applied in a multitude of ways at a very granular level, but are beyond the scope of this article.
To set up my site.pp Manifest, I added the following configurations to set my PATH, and to ensure that /etc/mime.types is present on all hosts. The manifest is written in a Ruby-based domain specific language.
#/etc/puppetlabs/puppet/manifests/site.pp
node default
{
Exec { path => “/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:” }
file { “/etc/mime.types”:
ensure => present,
mode => 644,
owner => root,
group => root
}
Once my site manifest was present, I ran the puppet agent command, which checks with the Puppet server to ensure all configurations are in sync, and applies any changes that may be out of sync:
# puppet agent
info: Retrieving plugin
info: Caching catalog for puppet2
info: Applying configuration version ’1299362162′
notice: /Stage[main]//Node[default]/File[/etc/mime.types]/ensure: created
notice: Finished catalog run in 0.10 seconds
Once this command was executed, I could see the file which was previously not present appeared on the filesystem. This is a very simple test, but the same test could also be configured for very complex use cases, such as verifying application configuration files, security rules, and auditing general system integrity.
Cloud
Once the Puppet configuration was in place, I looked for a way to provision and manage Rackspace nodes using Puppet. Unfortunately, there does not seems to be a plugin or feature that allows the user to administer Cloud nodes, although there is support for Amazon EC2. I did not have a chance to test the EC2 module, which might make this an unfair comparison considering I am looking at Cloud management with configuration management frameworks; however, Chef supports most major Cloud computing efforts, and according to Aviv Ben Yosef’s post, it has some various dependencies. An additional resource available for Puppet EC2 Integration came from Puppet Labs onBootstrapping EC2 with CloudFormation templates using Puppet.
Chef
Installation
Although Chef has many dependencies (CouchDB, RabbitMQ, Java, Solr), using one of the provided RPM or Debian packages actually makes it fairly easy to install. You can install Chef manually, but due to the large amount of dependencies, you probably don’t want to, unless you have a really good reason to do so. Before you set out to do so, I had to install some libraries whcih were not called out in the documentation, those were zlib-devel libxml2-devel, libxsl-devel, and make. The authors of the installation document may have assumed most people have gcc and make install, but I didn’t, so those starting with JeOS (just enough operating system) wont get stuck on that.
Configuration
Once Chef has been installed, I followed the docmeuntation on installing the various certificates and setting up the the Chef client’s and servers. TheOpsCode Quick Start documentation is the best source of information for this.
To configure a standard recipe, I followed the Cookbook Quick Start documentation off the OpsCode Web site. Rather than re-hash what was said in this article, I recommend you follow this document if you are interested in writing your first Recipe. Essentially the Recipe looks like the following:
Cloud
I began by simply listing the Cloud instances I had in the Rackspace account. This was as simple as installing some Ruby gems which includednet-ssh net-ssh-multi fog highline,and the pre-relase version of the chefgem.
Note: At the time of this writing the current stable gem of Chef is not compatible with the current stable version of the foggem.
After the necessary gems were installed, I added my API key for my cloud provider into my knife.rb configuration file. Once the API was present in knife.rb, I was able to list and create instances with ease using the knife rackspace command set (there is also a knife ec2, slicehost, and terremark subcommands). A lot of this heavy lifting is done by the fog libraries, but what is really a win is that knife has support for automatically bootsrapping a recently launched instance with the necessary Chef configuration files.
Conclusions
Although Puppet is a mature and robust system for configuration management, and a very good one at that, it doesn’t have the Cloud integration which Chef comes with out of the box. I hope to see this remedied soon, because I think Puppet is an excellent configuration management framework, although possibly currently better suited to organizations not managing many cloud instances or willing to put forward some extra resources to write an extension or utiility to integrate cloud management and provisioning with Puppet.
Chef’s knife tool makes provisioning and managing Cloud instances on almost any platform a breeze, without the need for additional tooling or configuration. Its almost all there already to manage cloud instances and deploy “recipes” (basically Chef’s term for what in Puppet is a Manifest) to Cloud instances.
Recommended Reading (Puppet)
Recommended Reading (Chef)
Automating the Cloud with Chef (Slides)
Installing & Configuring Chef (RHEL)
Launching Cloud Instances with Knife
DRBL 企鵝龍
|
關於DRBL企鵝龍
|
DRBL (Diskless Remote Boot in Linux)是一個自由軟體，由國家高速網路與計算中心所開發，主要功能是安裝了此軟體的Linux伺服器，就可以同時提供數十台電腦操作與使用。管理者所需要做得就是在伺服器上安裝好Linux之後，再裝好DRBL，用戶端電腦不需要有硬碟，不需安裝軟體，只要透過PXE網路開機，就可以直接使用了伺服器端提供的Linux了。DRBL的特色包含:
|
http://drbl.nchc.org.tw
2651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
