Currently I am involved in a project which uses Puppetlabs Razor to deploy ESXi servers. I’ll write about this in more detail later but let’s start off with a short introduction of Puppetlabs Razor.
Initially razor was written by Nick Weaver from EMC and released on may 21 2012. The anouncement was in this blog article: http://nickapedia.com/2012/05/21/lex-parsimoniae-cloud-provisioning-with-a-razor/. Later on, Razor was handed over to puppetlabs and Nick is apparently no longer involved in the development. When Razor was handed over to puppetlabs they started out by re-writing Razor. It is now entirely written in Ruby, uses sinatra and runs in torquebox. The current release is version 0.10. It’s not quite where the old razor was but work is progressing steadily. The development version at Github already has some features which are not available in the 0.10 release.
But what does Razor do exactly?
Quote from the razor website: Razor is an advanced provisioning application which can deploy both bare-metal and virtual systems. It’s aimed at solving the problem of how to bring new metal into a state where your existing DevOps/configuration management workflows can take it over.
So Razor deploys operating systems and hands it over to a tool which configures the OS. The deployment process start with the target server booting from PXE. If the server is not in the Razor database yet it will boot a microkernel. This is a Fedora 19 based linux image which connects to the network, collects hardware information using Facter and sends this to the Razor server.
Once the information of the target server is in the database Razor will start looking for a matching policy. Policies are attached to tags which contain matching rules. You can match on anything that is reported by Facter. For example: It is possible to apply a policy to all HP DL380G8 server containing 2 CPU Sockets, 16GM RAM and 2 Harddrives. Or you could just match on serial number so you have complete control over which server get assigned to a policy.
The policy itself contains certain settings for the deployment. The most important one being the installer to use and the repository to install from. An installer is a script which tells the target server how it should be installed. The repository is usually an imported ISO file of the OS that needs to be installed. Other settings in the policy are the root password and the hostname pattern.
Once a policy is matched the target machine will reboot and carry out the installation configured in the policy. The installer defines what needs to happen in different stages of the installation. Once it’s finished it will tell the server to boot from local disk. The last step in every OS installation is running the broker script. This script hands over the machine to another tool. Puppet comes with a broker for puppet. This broker installs the puppet agent on the target machine which, from then on, is under control of puppet. There is no broker for vCenter but I managed to create an AMQP broker which makes it very easy to integrate with vCenter orchestrator. I’ll write about this in a separate blog post.
Want to get started right away?