Metal as a Service

Metal as a Service

Canonical’s “Metal as a Service” is a front-end to a number of standard system services used to provision bare-metal equipment in a rack. This is a short, high-level description of how it works.

I’ve been working with Canonica’s MAAS recently. MAAS is a front-end and management daemon for bare-metal servers accessible over the network. Unlike Fedora/RedHat’s Cockpit, which (primarily) provides a web-UI for post-provision management (disk management, logging, containers, etc) - MAAS is for getting Linux on disk and getting the server to a usable state.

There’s a lot of different ways to manage the power of a server remotely. Different power-bars offer different interfaces. Different NICs offer different protocols and interfaces to manage a server in the power-off state. My experience is with Sun OpenBOOT and Dell’s implementation of IPMI. OpenBOOT is perhaps gone, I haven’t seen modern Oracle servers. The basic usage of IPMI in our case is to set the boot device to PXE, and power-cycle the server. MAAS comes with support for IPMI, which it uses to monitor the power state of the server, and reboot it when required.

If you’ve provisioned hardware over PXE before, you’ll know the steps pretty well. When the server boots, the PXE function in the NIC firmware(?) attempts to negotiate DHCP, and then attempts to pull a small boot payload from a (typically) tftp server specified by the DHCP server. That payload is usually, in our case, PXELINUX. Once the payload is pulled, it executes, providing a menu (if desired) that can be used to load operating systems over the wire.

So we have two services needed on the local network to get to that point. In my experience, they’re usually tftpd and dhcpd. I expect you could do it with dnsmasq and any old tftp server. While tftp works, you’ll usually find that Linux distributions (and their documentation) prefer to fetch their files over HTTP or HTTPS. For this, I usually use the Python (2) SimpleHttpServer, as it happily serves the current working directory on a non-privileged port. That working directory being the installation ISO on a mount:

mount -tiso9660 -oloop /centos.img /mnt/centos

Historically, unattended installations (for CentOS) were done by knocking up a kickstart file, generating an ISO for your specific server, and installing from that. That process has largely been replaced with cloud-init. I won’t get into cloud-init and cloud-config files here, but you can consider them a file that defines what an installed system should look like, that is processed either on installation or on boot to configure a system. MAAS uses cloud-init files.

Bringing this all together, MAAS provides a very automated way to take IPMI, take DHCP, take TFTP, take HTTP, take image management, take cloud-init and wraps them up in a very slick UI.