rPath X6 in the Lab

 

rPath X6 in the Lab

I installed rPath X6 on a six-core Advanced Micro Devices Opteron 4000-series server in our lab and performed basic configuration of the X6 instance through rPath's handy Web-based appliance administration console. I next configured CentOS 5.5 as a platform operating system and kicked off a process to sync packages from the nearby kernel.org CentOS mirror to my X6 instance.

I then configured a pair of targets for deploying my VMs (virtual machines) by providing the location of and credentials for our VMware vCenter server in the lab and for an Amazon EC2 account in the cloud. During my previous rPath review, configuring and using the VMware target took some trial and error, but this time around, the process was completely trouble-free. After setting up the VMware target, I could browse through the existing VMs associated with our test data center.

For my test appliance, I opted to re-create our WordPress-based blog server, and started by picking relevant CentOS packages to add to my appliance, such as Apache, PHP and MySQL. rPath X6 took care of the details of pulling in dependencies, including the Linux kernel and the constellation of other components that go into a typical server image. For the WordPress code itself, I created a package of my own by uploading the WordPress tarball into my X6 instance, providing basic metadata, such as name, version and a location to extract the archive.

I was able to carry out each of these platform, target and appliance operations through the product's Flash-based Web interface, which, as with the VMware target support, performed much more smoothly this time around than it had during my 2009 tests.

It was in the next step of my tests, running through the new appliance configuration options, that I hit my first real snags. In previous versions of the rPath product, the Web admin console I used to manage the X6 instance itself was also available for managing individual appliances, and this new version still sports a "manage" link that points at the port 8003 location where this console lives. However, the rPath admin console is only available for rPath Linux-based appliances, and rPath Linux is no longer listed as a platform option in X6.

What's more, the "configuration" tab for individual appliances reported that my appliance lacked any configurable elements. After scratching my head trying to figure out why the manage link wasn't working with my CentOS-based appliance-in-progress, I got on the right track and set about creating configuration packages to handle operations such as turning the Apache server on or off by default, and modifying the port number at which the Web server listened.

Creating these configurations involved breaking out a text editor to create XML config property and handler files capable of swapping values entered in the X6 interface into particular configuration files on my deployed VM. Also, the configuration packages had to include scripts for performing operations such as restarting or shutting down services. Once created, these configuration packages worked just as the WordPress package did-I compressed them into tarballs and uploaded them with a directive to extract them to the root of my deployed VM.

I used an example package from rPath for configuring Apache to start up by default to create a handful of other configurations-including those for changing Apache's document root and for starting up MySQL by default.

This built-in configuration system, called iconfig, is an open-source project licensed under the CPL, but I found scant information about it in rPath's documentation. The software would be much easier to use with a community around it and with more sample packages. According to rPath, more example content is on the way, and a user interface for creating configurations is planned for a future version. Sites already using Chef, Puppet or Cfengine for configuration management should be in better shape than I was, as these systems may be used with rPath X6 in lieu of iconfig.

Deploying my WordPress instance to Amazon EC2 was a straightforward affair: Using the X6 Web interface, I created an EC2 AMI for my appliance and launched it on Amazon's cloud just as I had with our vSphere installation. Managing and configuring EC2-deployed appliances, however, require additional setup, as an X6 server must be reachable by deployed appliances, either by hosting an X6 instance in a DMZ or by locating an instance at EC2.