I’ve recently decided to take the time and look into the various open-source systems for server deployment and life cycle management. As the amount of servers in the data-center grows, as well the the demands for quicker response to rapidly changing IT needs in the organization, performing manual server installation, or even using a manually configured Kickstart server simply doesn’t cut it.
The following is a list of server deployment and life cycle management systems I could find on the Internet, and what I could learn from reading the documentation available on their websites.
Cobbler
Cobbler aims to bring the all various tasks that has to do with server provisioning under a single roof:
- Managing and configuring DHCP, DNS and TFPT servers
- Managing the PXE kernel and installer system images served over TFTP
- Managing and configuring Kickstart and Preseed files
- Mirroring package repositories
- Configuring server network connectivity during installation, including advanced setting such as interface bonding and bridges (Unfortunately this feature is typically omitted from provisioning systems, and you end up having to physically access the server to configure networking after the OS is installed)
Cobbler includes a command-line interface as well as a web-based GUI.
It seems that cobbler is somewhat semi-automatic, it configure that various DNS, DHCP, etc. servers by generating configuration files on demand (Whlie issuing the “cobbler sync” command) rather then using dynamic update tools such as nsupdate. This limits cobblers utility to only configure such services if they are installed on the same server running cobbler and are not managed by any other system.
The network configuration done by cobbler seems to depend on knowing the MAC addresses of all the NICs on the server and where they are connected to, prior to installing the OS on the server. This would require the system administrator to access the server using some sort of a “rescue” OS before cobbler could be used, this pretty much beats the purpose of using an automatic provisioning system.
Cobbler seems to be focused around installation, as such, it provides limited utility for managing the server once it is installed. Cobbler does provide integration to configuration management systems such as Puppet as well as it’s own built-in simple CMS, but it doesn’t provide any means to manage and collect information about the server software after the installation is complete.
Spacewalk
Spacewalk is the open-source project behind RedHat Satellite, as such it supports not only RedHat systems but also Debian and SUSE and CentOS-based systems.
Spacewalk builds on top of Cobbler and extends it by including server package management and monitoring as well as somewhat better-looking web-based GUI.
One important Foreman feature that is unfortunately not supported by Spacewalk is the integration with 3rd-party configuration management systems.
Foreman
Foreman aims to be a complete server life cycle management solution, it does that by performing server deployment (Via the usual route of automating the PXE boot/Kickstart configuration) and then providing very strong integration with Puppet.
Foreman integration with Puppet is indeed very strong, not only can it act as as external node configuration source (Similar to cobbler) but it can also read and provide a GUI for all information available to and generated by Puppet including server facts (Collected with Facter) and Puppet execution results.
When it comes to managing DNS and DHCP servers to perform deployment, Foreman offers an interesting solution, it provides a “smart proxy” component that is meant to be installed on the relevant servers to allow it to configure them. The smart proxy supports configuring both Linux and Windows-based DNS and DHCP servers.
Since it is primarily built around Puppet, Foreman is somewhat weak when it comes to managing things that are not managed by Puppet, therefore it doesn’t provide any means of managing software repositories nor does it include features for managing or collecting information about software packages not directly installed by Puppet (Which typically include most critical core OS packages such as the kernel, glibc and the coreutils)
The Foreman documentation is unclear about how does it handle bare-metal servers it never saw before, it seems it can assign tasks to them based on their IP address, but can it configure the DHCP server to assign a particular address based on a MAC address for a previously unseen host? Also, does Foreman assume MAC addresses never change? What happens when NICs need to be replaced?
Foreman doesn’t seem to support performing any complex server networking configuration out of the box, you seem to be stuck with what Anaconda/Kickstart can do on its own and manually looking up the server MAC addresses.
Puppet Razor
Razor is joint EMC/Puppetlabs project.
Razor is somewhat different then other provisioning solutions in that it doesn’t boot new servers into the installer system provided by the OS provider (E.g. Kickstart) but into its own microkernel that proceeds to collect information about the server (using Facter) and install the OS based on that information.
This feature of including such a microkernel, may indeed allow for true “hands-off” installations, since for once, there is a central location you can query what the server MAC addresses are.
Being a Puppetlabs product, Razor includes Puppet integration, but it can also integrate with other configuration management systems.
Razor does not currently include a GUI.
Razor seems to have the assumption that you can decide which OS to install based solely on hardware information embedded in its workflow (As opposed to deciding what to install based on where the server is located for example). That might cause problems for sites which may install different OSes on similar servers. One workaround may be to use the MAC address as basis for selecting the OS to install, buy it really seems that Razor is aimed at creating a workflow where you don’t care what is installed on which box as long as it fits the bill, this workflow may not fit all organizations well.
Ubuntu MAAS
Ubuntu MAAS (Metal as a Service) is designed to bring the Juju service orchestration framework to bare-metal servers. As such it provides a somewhat radical approach to server installation. Like Puppet Razor, Ubuntu MAAS boots its own system rather then the OS installer, and that system goes on to collect information about the machine its running on. At this point MAAS preforms its radical departure from other systems, it does not go on to install an OS, instead, the server is shut down, and is brought back up and provisioned only when Juju deems such a machine is needed to provide a certain service.
Being very tightly integrated into Ubuntu and Juju, MAAS as it is may be unsuitable for organization looking to use other OSes and orchestration systems.
Katello
Katello (more information here) is the open-source project behind the next generation of RedHat Satellite (E.g. replacing Spacewalk?), to bring it up to speed with modern approaches to server management such as workflow-based configuration management.
Katello is built on top of Puppet and Foreman, and supplements them with Pulp for package and repository management and Candlepin to manage RedHat channel entitlement.
While it had already released versions 1.0 and even 1.2, it seems to be still early days for Katello, also, it seems to only support RedHat systems for now.
The Katello documentation seems to indicate the Katello server requires 2.5GB of RAM as a bare minimum, this requirement might make it unfit for smaller sites that are used to having the installation server be a tiny VM running TFTP.
Ifblog (ponderings 2.0) 
Very nice (and helpful) list!
Any chance you could have a look at OpenQRM (http://www.openqrm-enterprise.com) and share your thoughts how it fits in?
Thanks!
I had a (very) quick look (mostly looked at the screenshots…)
OpenQRM does seem to have some interesting features, like the ability to setup servers that boot from NAS. Over all it seems very strong in the deployment department, but I wonder about the strength of the post-deployemnt life-cycle management features. The site claims OpenQRM has Puppet integration, but I couldn’t see any screens for class-assignment and fact browsing, I also couldn’t find any screenshots or descriptions for features of package repository management or update management.
Another interesting feature is the “Cloud request form”, it might be very useful for sites looking to facilitate end-user self-service, but I wonder how customizable is it, because every organization will have its own ideas about what options should be available here.
I wonder about the integration with Nagius, I’m not sure that deployment management and monitoring are really related tightly enough to justify unification under a single tool. If so, integration with performance monitoring tool such as Ganglia might be missing.
Some important features such as network bonding support and external DNS/DHCP server configuration support seem to be available only in the enterprise version. In my view, this is is a shame, such features might be deal-breakers for some organizations, but being exactly the kind of feature that fail to work as advertised in many products, organizations would be very interested to make sure they work properly before having to pay for the full product.
Thanks for the link! I will probably give OpenQRM a deeper examination in the future, and write a more knowledgeable review. There is one caveat the I couldn’t ignore though – It is a PHP application… really? who writes PHP in this age of Rails? :)
Great post. Certainly helps me understand the available options. I am leaning towards Foreman for it’s ability to boot baremetal and cloud instances while also providing tight integration with a configuration management tool like puppet.
Foreman seems to be a logical choice as RedHat’s future tools are based in it. But I’m still in doubt about how efficiently it can handle bulk deployments of brand new bare-metal servers. I would take a serious look at openqrm, described in a comment above, as it also brings monitoring to the mix.
Hi,
Great post. Thank you. I’m investing some time on some of the infrastructure I manage, making things a little more automated and efficient. I had come across most of the software in the list above, but it was a little hard to get a good overview of what the concrete differences are. (Without digging in and just trying each of them …) Your take on them helped to put things in context. So I wanted to say thanks!, and also ask if you have had any good/bad/new experiences in the past year or so … ?
Hi, thanks for your kind comment.
For various reasons, I didn’t have the opportunity to implement the kind of improvements I was thinking about back when I was writing this post, therefore I am still using the same Puppet/Satellite mix I’ve been using for the last 3 years with some custom scripts to fill-in the gaps.
There are a few more things I would look into now days:
1. Firmware updates as part of the installation process – Dell’s Crowbar is one tool that seems to provide this kind of capability (On top of Chef), though you might be able to implement this with Razor and some creative use of Puppet manifests and plugins.
2. Windows Support – because it isn’t going away, and its nice to be able to use common tools for all platforms. You can accomplish quite interesting things when you have Puppet and MCollective running on both Windows and Linux servers (Take a look at the “Ultimate Deployment Appliance” for that).
3. OpenStack – Its bare-metal provisioning support is getting some attention lately and may get mature enough for production use in the next release. That will allow one to implement a Cloud-Like lifecycle management approach throughout the entire infrastructure. This is similar to what Ubuntu MAAS does though hopefully it won’t be limited to a single distro and would also bring Storage and Network provisioning to the mix.
One practical advice – if you are using Satellite/Spacewalk, try out the Spacecmd tool, it dramatically reduces the time it takes to implement various automation features on top of those tools. Another interesting tool I recently came across is FPM – it radically simplifies the process of creating RPM/DEB packages for 3rd-party (“Enterprise”…) software. I’ve been using it recently with great success.
Nice!! Thank you, those look good. It’s great to have more puzzle pieces.
I wonder why you didn’t had a lok at FAI (Fully Automatic Installation).
It’s like kickstart/cobbler, and can install different Linux distributions but is much more flexible in the configuration part.
You can use shell scripts or your own puppet, cfengine, chef,.. system for customisaztion.
It also supports bare metal deployment, installing virtual machines, creating live images (CD or USB stick) or chroot environments.
Have a look at its web page
http://fai-project.org