Right now, OVHcloud is involved in both Cloud (OpenStack-based), and BareMetal. This is why we try to have the same approach when it comes to deploying OSes. In this article, we’ll explain how we do this using the example of a newly available distribution: RedHat© Entreprise Linux.
What is a cloud-ready image?
For those who don’t know, cloud-ready images are a pre-installed distribution that come in the format of a single file (RAW, QCOW2, OVF,…), and can be booted by a hypervisor to have a system ready in seconds, without having to endure all the installation process.
As you can have a lot of different VMs based on these images, it’s kind of a One-Size-Fits-All situation – making them pretty interesting to work with.
You may ask ‘How can I set things like hostname, network, ssh key, on this server prior to booting?’ This is where cloud-init and instance metadata come in.
What are cloud-init and instance metadata?
Cloud-init is a solution developed by Canonical to be the ‘industry standard multi-distribution method for cross-platform cloud instance initialization’, and as far as we’ve used it, it works pretty well.
Cloud-init is a service that runs at first boot to resize your partitions, configure hostname, network, to pass and execute scripts, to tell other services that it’s alive, and other possibilities.
All of this information is held on instance metadata which can come in many forms. Mostly, perhaps, as a cloud-provided metadata, in the form of a collection of JSON files. Below is an example of a meta_data.json file.
{
"keys": [
{
"data": "ssh-rsa AAAAB3NzaC1yc2AACABQCnZ0Ma2nE99GXH== jcollin@ovhcloud.com",
"type": "ssh",
"name": "key1"
}
],
"public_keys": {
"key1": "ssh-rsa AAAAB3NzaC1yc2AACABQCnZ0Ma2nE99GXH== jcollin@ovhcloud.com"
},
"uuid": "12345678-1234-1234-1234-abcdefghijkl",
"availability_zone": "nova",
"hostname": "myhostname",
"devices": [],
"launch_index": 0,
"project_id": "abcdefgh-4321-4321-1234-lkjihgfedcba",
"name": "myhostname"
}
How does that work on BareMetal?
It’s almost the same as the cloud way, except it requires some extra work. As we work with OpenStack, we want to apply the cloud process to baremetal servers. It’s heavily inspired from Ironic, the OpenStack Baremetal module.
The image
For this example we will use the case of the newly available RedHat© Entreprise Linux, and as we can provide two ways of having it on your server, the process is roughly the same.
We use the official cloud-ready RHEL image provided by RedHat©, use it on our own template factory, made with Packer and OVHcloud Public Cloud, to download and pre-install packages that will be used later in the installation process, such as mdadm, lvm2, and others.
The image is then pushed on our mirror infrastructure that will distribute this image to the service that will perform installation.
The process
To install such an image on your bare-metal server, we boot it on a rescue-image and perform a lot of operations on it, such as:
- wiping the disks
- setting up the partitions, and RAID (if any)
- creating the config-drive partition (we’ll talk about it later)
- mounting all setup partitions in a temporary folder
- rsyncing the image in the temporary folder
- making it bootable (later on that part)
- if the distribution needs to have a license, one additional step is required, like:
- registering against the RedHat© Subscription Manager’
- rebooting
- waiting for phoneHome
config-drive
This, is the source of our instance metadata on bare metal servers. It contains all the necessary files for cloud_init to set and configure the system at first boot.
It’s a little (1MB) partition with ISO-9660 file system (yes, that means read-only), that will be detected by cloud-init-service instead of the standard meta_data.
Making the image bootable
Behind this barbaric name there is a well polished process that involves a lot of tweaking. Luckily for you (and us), all of this is automated, even if the tweaking is done manually at first.
- creation of
/etc/fstab - configuration of grub with some specific presets
- installation of tools like lvm2, mdadm
- creation of
/boot/initramfswith additional drivers - grub installation
- syncing of
/boot/efipartition
All of this will ensure that your server will be able to boot gracefully.
phone-home
Phone-home is a cloud-init feature we have outsourced to be sure it will work, even if you decide to have a first boot script that will delete all traces of cloud-init.
It’s a simple script that will execute a HTTP POST to a home-made service. This lets us know that the server is finally booted, and that just after the first steps of cloud-init, the original one will wait the end of the process, and make the call only when you can log into your server.
What makes all this tricky?
Well, that is a good question! We try for this process to be as simple as possible, and that’s a hard task, because every distribution is different, even the same distribution on a different version can be different.
For example, we provide 4 kind of RedHat© Entreprise Linux
| Version | Licensing |
|---|---|
| RHEL 7 | w/ license |
| RHEL 8 | w/ license |
| RHEL 7 | BYOL |
| RHEL 8 | BYOL |
Tweaking for RHEL 7 is a little different than for RHEL 8, but you have the same scripts to apply (or not apply), when it comes to the licensing. Since we have no way of licensing for RHEL, the standard method for purchasing a license from OVH is the ‘BYOL’ way which stands for: Bring Your Own License.
Is RedHat© this complicated?
Really, no. But RedHat© has standards, and we have to respect them, so there are challenges.
Before being able to sell RedHat© Entreprise Linux on Baremetal, we had to certify each of our flavor with hardware tests, such as network, computational, disks access, memory, virtualization capabilities, and more. The process is long, but you ought to know what you are doing even better, because even if each distribution is different, each server is too.
So, yeah, we are proud to say we achieved this feat like other major manufacturers.
The future
As I told you before, this process is quite close to OpenStack Ironic, and if it might even be the future in terms of providing Baremetal as a Service – a little work on your cloud-ready image may still be necessary.
And if you’re up to the challenge, maybe make your own image to install it on your fresh servers with the soon-to-come Bring Your Own Image feature that is in development right now!
OVH BareMetal System Engineering
Writing black magic in shell, perl, and python.
I love good coffee, craft beer, and old Islay whisky.