DHCP and iPXE with Boots

Tink is surrounded by various components that do the real work on the target systems. These include Boots, a DHCP server, and an iPXE server written especially for Tinkerbell. As a reminder, the PXE extension iPXE offers various additional features such as chain loading (i.e., the ability to execute several boot commands one after the other).

The only task Boots has is to field the incoming DHCP requests from starting servers and to match the queried MAC address with the hardware stored in Tink. When it identifies a machine, it assigns it an IP address and then sends the machine an iPXE image, ensuring that the server boots into the third Tinkerbell component, the operating system installation environment (OSIE). This mini-distribution is based on Arch Linux, which processes the various steps defined in the template for the respective server, one after the other. OSIE uses Docker for this purpose, which lets you use simple containers of your own that OSIE calls in the sequence your define. Alternatively, you can rely on standard containers from the major vendors.

OSIE is supported by a metadata service named Hegel, the fourth component, that stores the configuration parameters you specify in a template for the respective server so that they can be retrieved directly from OSIE. In principle, this process works like cloud-init in various cloud environments. The script talks to a defined API interface over HTTP at system startup; by doing so, it obtains all the parameters defined for the machine (e.g., a special script that calls the virtual instance or, in the Tinkerbell example, the physical server at system startup).

Hegel imposes virtually no limits on your imagination, although a reminder is in order: Especially in the context of virtual instances, many administrators get carried away with re-implementing half an Ansible setup in the boot script that the VM receives from its metadata. However, this is not exactly what the scripts are designed to do. In fact, they are only supposed to do the tasks that are immediately necessary. If any additional work is to be done later, you will want it done by components that are made precisely for those purposes.

Bare Metal Is Not the Focus

The fifth and most recent Tinkerbell component is the power and boot service, which can control the machine by out-of-band management. This function was not originally part of the Tinkerbell design; however, it quickly became clear that reinstalling a system on the fly is also part of life-cycle management and only works conveniently if the life-cycle manager controls the hardware. Otherwise, you would have to use IPMItool or the respective management tool for the out-of-band interface to change the boot order on the system to PXE first and then trigger a reboot locally.

However, you can only get this to work if the affected system still lets you log in over SSH. If this does not work, you have to use the BMC interface. Tinkerbell's power and boot service allows all of this to be done automatically and conveniently from the existing management interface.

The developers clearly focus on IPMI. All BMC vendor implementations offer IPMI support, even though you might have to enable it separately. In any case, the only alternative to IPMI would be to fall back on Dell's remote access admin tool, Racadm. Tinkerbell does not implement these protocols itself but relies on existing tools in the background, which undoubtedly saves a lot of work.

Communication by gRPC

By now, you know the components of the Tinkerbell stack. As befits a solution in the year 2021, the individual services do not communicate with each other in any way; rather, they use the gRPC protocol that was originally developed by Google. Therefore Tink, as the central component, ultimately controls the other services remotely in a certain way. gRPC is designed to be both robust and stable, so the developers' decision in favor of the protocol is understandable.