Tinkerbell life-cycle management

Magical Management

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.

Listing 1

Tinkerbell Template

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

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Life cycle management with Foreman and Puppet
    Virtual machines seem to be ideal for spare capacity. They are easy to create and remove – if only all those time-consuming administrative tasks like assigning IP addresses, setting up backups, and monitoring were more manageable. Having the right tools can help.
  • Bare metal deployment with OpenStack
    Automating processes in the age of the cloud is not just a preference, but a necessity, especially as it applies to the installation and initial setup of compute nodes. OpenStack helps with built-in resources.
  • Server virtualization with Citrix XenServer
    Version 5.6 of Citrix XenServer is a feature-stripped version of the virtualization product and is available free, in addition to the commercial Advanced, Enterprise, and Platinum editions.
  • Open source cloud technologies at a glance
    With the promotion of CloudStack to an Apache top-level project in March, four open source solutions are now in the race to conquer the cloud, the other contenders being OpenNebula, Eucalyptus, and OpenStack. The projects have a number of similarities.
  • Build operating system images on demand
    If you are looking for a way to build images quickly and easily, FAI.me is the place to go.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=