Practical Tinkerbell

If you want to try out Tinkerbell, you can access the developers' Vagrant containers. The objective of this exercise is not to install an operating system on a server. Instead, the Vagrant environment is intended to show the basic workings of Tinkerbell and the opportunities it offers.

The Vagrant files and detailed instructions [4] supplied build a Tinkerbell environment in a very short time without disabling any features. The essence of the process is not complicated. First, you roll out the Provisioner with Vagrant that contains all the services described above: Tink, Boots, and Hegel, including their sub-services and everything else an admin needs.

From Vagrant, Tinkerbell then runs in Ubuntu containers, which you roll out with a Docker Compose file. Therefore, you also have the Tink CLI. You also need an image to get things started: In this example, I used the hello-world image provided by the Docker developers themselves. Tinkerbell runs a local container registry. You first need to run the pull command to retrieve the image from Docker Hub and then push it into the local registry with a push command.

Next, you inject the physical server configuration into Tinkerbell with the help of a file in JSON format (Figure 2) that gives the machine an ID, a few configuration details, and – very importantly – its network settings. This is where you specify which IP address the system will get from Boots later on and whether it uses UEFI or a conventional BIOS.

Figure 2: Defining hardware in Tinkerbell with a JSON file; the service doesn't need to know that much about the particular bare metal.

Server Template

The Tinkerbell services are running and the server configuration is where it belongs. However, Tinkerbell would not yet know what to do with the server when it phones home. It would start OSIE on the machine, but it would not install an operating system for a lack of instructions. Therefore, the template in Listing 1 is used in the next step.

cat > hello-world.yml <<EOF
version: "0.1"
name: hello_world_workflow
global_timeout: 600
tasks:
  - name: "hello world"
    worker: "{{.device_1}}"
    actions:
      - name: "hello_world"
        image: hello-world
        timeout: 60
EOF

In Tinkerbell, a template associates a particular machine with a set of instructions (Figure 3), which is strongly reminiscent of Kubernetes pod descriptions in style and form, even though it does not ultimately implement the Kubernetes standard. The most important thing in the template is the tasks section, which ensures that Tinkerbell executes the named image on the system after the OSIE startup.

Figure 3: Bootstrapping in Tinkerbell relies on templates and Docker containers. In this example, Tinkerbell writes an Ubuntu image to disk.

In the next step, if you start a Tinkerbell Worker and give it the ID of the template and the MAC address of the target machine, the process starts up. As soon as the corresponding server boots into a PXE environment, Tink kits it out with the OSIE image and then calls the container in the image, which outputs Hello World .

The individual steps of the process can be displayed directly in Tinkerbell by the workflow engine (Figure 4). To help with debugging, you can also see which parts of the workflow were executed and whether the execution worked.

Figure 4: The individual work steps within a template can be traced from the outside.

A Practical Example

In the daily grind, the rudimentary Vagrant example is admittedly unlikely to make an administrator happy. However, it shows basically what is possible. Tinkerbell's documentation also comes with concrete examples of templates that ultimately install Ubuntu or RHEL from official container images.

If you're now thinking, "Wait a minute, they don't have kernels and they don't install GRUB out of the box, either," you're absolutely right: You have to specify these steps individually in the respective templates – and in the way you want them to be executed. As with other solutions, the greater flexibility in Tinkerbell comes at a price of additional overhead in terms of needing to specify what you want to accomplish.