In this blog post I will walk you through the steps needed to PXE boot a bare metal machine into a live CoreOS image, using Digital Rebar Provision (DRP), which is an Open Source project developed by RackN. The goal of this post is to demonstrate how the immutable infrastructure pattern can be implemented by using some of pre-built tasks available from the DRP community catalog.
The method outlined in this blog post can be used in a home lab context, but should work equally well in an edge computing environment. All you need to get started is a target node with intel x86-64 architecture support (physical or VM) and which is able to PXE or iPXE boot. Additionally, you will need a place to install DRP, for the purpose of this tutorial we will be targeting docker.
Install Digital Rebar Provision
The one-liner below will install DRP running in a single Docker container (named drp) with a single volume (named drp-data) for storing its state. DRP has a built in DHCP server which it uses send PXE boot instructions, because of this the docker container will need to connect to the host network, which should be the same network as that of the target node.
curl -kfsSL https://get.rebar.digital/stable | bash -s -- --container installInstall the drpcli
The drpcli can be downloaded from the built in file server which is hosted on port 8091. Assuming the commands below are being executed on the Docker host, we should be able to reach DRP through localhost.
curl -s -o /usr/local/bin/drpcli \ http://localhost:8091/files/drpcli.amd64.linux
chmod +x /usr/local/bin/drpcli
Install content packs and iso’s
All configuration in DRP can be done through the UI via the RackN Portal, but also through the CLI. Configuration can also be distributed in yaml format in the form of Content Packs. There are a bunch of handy pre build tasks and workflow available in the Digital Rebar Community Catalog. Let’s use the CLI to install the coreos content pack and its dependencies (like iso’s).
drpcli catalog item install task-library
drpcli catalog item install drp-community-content
drpcli catalog item install coreos
drpcli bootenvs uploadiso discovery
drpcli bootenvs list \
| jq -r '.[].Name' \
| grep -e 'coreos-.*-live' \
| xargs -L1 drpcli bootenvs uploadiso
Configure a subnet
To be able to discover new machines on your network, DRP needs to know on which subnet to listen for DHCP requests. Since you probably already have a DHCP server responsible in your network for handing out IPs, we will configure DRP in proxy mode. This means it will only be taking responsibility sending PXE boot related information, and nothing related to configuring the network.
DRP should already have discovered the subnet on interface eth0 via DHCP, so let’s use that information to create a subnet with proxy mode enabled. If you want DRP to also be in charge of handing out ip-addresses please refer to the documentation.
drpcli interfaces show eth0 \
| jq '.ActiveAddress | {
Name: "eth0",
Proxy: true,
Strategy: "MAC",
Enabled: true,
subnet: .}' \
| drpcli subnets create -
Discover a Machine
Before we can provision a machine it first needs to be known to DRP. This can be achieved by configuring unknown machines to boot into the sledgehammer image and perform a discover workflow. The main purpose of this workflow is running gohai (a tool for collecting system information) and updating the machine params with the results. This information can later be used to for example search for a machine with a certain type of storage (NVMe vs SSD vs HDD).
drpcli prefs set defaultBootEnv sledgehammer
drpcli prefs set defaultWorkflow discover-base
drpcli prefs set unknownBootEnv discovery
With the above preferences set, go ahead and PXE boot your machine. This can usually be configured in your BIOS. Alternatively this repo contains some helper scripts to create PXE booting virtual machines using VirtualBox. It should show up within 1 minute (could be slower depending on your network and disk performance).
Provision a Machine
Machines can have properties set on an individual level, like was done for storing the gohai results, you can however also set properties on a group of machines through the use of a profile. All machines will inherent the properties set on the global profile. We will use this profile to set a default public ssh key.
jq --arg user $(whoami) \
--arg key "$(curl -s https://github.com/$(whoami).keys)" \
-n '{"access-keys": {"\($user)": $key}}' \
| drpcli profiles params global -Now we are all set, let’s create a workflow in which the machine goes directly into the coreos-live stage. This stage boots the machine using a CoreOS live image (loaded into memory). It will also install the drpcli and run it in agent mode (waiting for further life cycle events) additionally it will install the public ssh key. Once the machine is ready you can ssh into it using the core user.
jq -n '{Name: "coreos-live", Stages: ["coreos-live"]}' \
| drpcli workflows create -
drpcli machines list \
| jq -r '.[].Uuid' \
| xargs -L1 -I{} drpcli machines workflow {} coreos-liveWhats next
Having just a plain CoreOS machine is not as useful in itself, however CoreOS can be used as a building block for building clusters. DRP exposes some powerful primitives for orchestrating common cluster patterns, through the use of shared profiles which are updated by the machines themselves. This simple primitive can be used to implement master election, rolling updates, and distribution of bootstrap token.
To further explore the power of Digital Rebar Provision take a look at one of the following projects, both of which use the common cluster-add stage to elect a master node and setup among other things Etcd.
Spread the word
