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 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 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 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.
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 (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 (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.
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.