While still in its infancy, CoreOS is getting a lot of attention lately as a fast and lightweight Linux distribution geared towards large-scale server deployments. It’s bundled with software like Docker, Fleet, and etcd to allow for quick cluster deployments and manageable app containers.
One particular point that helps ease its adoption is that it supports iPXE booting with a cloud-config parameter. For providers that support iPXE booting (like Vultr.com), launching CoreOS instances doesn’t get much easier. A simple script.txt file placed in a publicly accessible location (we use Amazon S3 with the resource set as public) will give you a CoreOS instance on Vultr.com in about 60 seconds.
Upon logging in, you’ll have a fresh CoreOS running in RAM. While this may be ideal in many setups that have RAM to spare, memory constrained systems such as Vultr’s smallest 768MB instance can be relieved by installing CoreOS to disk using the install script provided by CoreOS. This works well and gives you an extra 50 – 100MB after rebooting, but we wanted our deployments to be automatic and not require any manual intervention.
We’re going to create three files:
- iPXE boot script – this is used to give the iPXE boot process commands to automatically execute and provide CoreOS with a shell script to execute after booting completes.
- cloud-config-bootstrap.sh – provided to the iPXE boot process in the boot script, this script downloads our actual cloud-config.yaml file, installs CoreOS to disk, and reboots the system.
- cloud-config.yaml – provided to the coreos-install program in the bootstrap script, this file contains options that start services like etcd and fleet, configure reboot settings, setup our public SSH key, and so on.
Because CoreOS supports a cloud-config-url parameter in the iPXE boot process, we can provide a URL (it can’t be HTTPS) to either a valid cloud-config.yaml file or a shell script. Unfortunately, CoreOS doesn’t yet support all of the cloud-config options such as runcmd and bootcmd, so we’ll need to resort to a shell script. But first, let’s add a cloud-config-url to our iPXE boot script:
#!ipxe set base-url http://stable.release.core-os.net/amd64-usr/current kernel ${base-url}/coreos_production_pxe.vmlinuz cloud-config-url=http://s3.amazonaws.com/[YOUR S3 BUCKET]/coreos/cloud-config-bootstrap.sh initrd ${base-url}/coreos_production_pxe_image.cpio.gz boot
Do note, you won’t be able to SSH into the instance if anything goes wrong because we removed the sshkey parameter. You can add this back into the script if you’d like.
Now, let’s create the file cloud-config-bootstrap.sh. Open up your favorite editor and create the following file:
#!/bin/bash curl -O http://s3.amazonaws.com/[YOUR S3 BUCKET]/coreos/cloud-config.yaml sudo coreos-install -d /dev/vda -c cloud-config.yaml sudo reboot
(Replace /dev/vda with the disk you want CoreOS installed on. *** The install script will delete everything on that device ***)
Put this file in a publicly accessible location (it can go right next to your iPXE boot script).
Here we download our actual cloud-config file that we’ll want to use when our installed version of CoreOS boots up. By downloading the file we can supply it to the coreos-install program that will bootstrap it during installation. A final reboot will free up the extra RAM that was being used by CoreOS and boot from disk instead.
Once that file is created, we can make our cloud-config.yaml file that each instance will receive upon booting:
#cloud-config coreos: update: reboot-strategy: best-effort units: - name: etcd.service command: start - name: fleet.service command: start ssh_authorized_keys: - ssh-rsa [PUBLIC KEY]
This file should be tweaked to your needs (including the reboot-strategy) and include your SSH public key so you’ll be able to SSH into the instance. Remote Fleet management also requires this, so don’t forget to include it. You can see all of the cloud-config options supported by CoreOS here.
Sign up for Turret.IO – the only email marketing platform specifically for developers
Cotton Tenney
This seems to work, except for the fact that it sends my Vultr instance into an endless reboot. Any ideas on this problem? I’ve tried removing the iPXE boot script after the initial install, before the VM reboots but no dice…
tim
Are you sure it’s stuck in a reboot cycle? This can take a bit of time to boot depending on the current load on Vultr. I’ve seen instances come up and be ready in a minute, while others take 4 minutes.
Try watching the console output as soon as the “Manage” button is ready for any clues. You can also add your public SSH key after the cloud-config-url in the iPXE script with the parameter `sshkey=”ssh-rsa …..”` to login to the instance as soon as the iPXE boot completes, but it will disconnect you when it reboots to finish the install-to-disk part.
Hope this helps!
-Tim
Cotton Tenney
I’m pretty sure it was a malformed cloud-config yaml, it’s working now! Nice tutorial, thanks.
tim
Awesome!
James Dunmore
Thanks for this, it set me on the right track for what I was after (being able to update the ec2 user metadata from external to AWS and/or running when the box is up (and have some sort of versioning))
I can use
sudo coreos-cloudinit –from-url http://s3 bucket etc