1. Overview

Node Types

A minimum of 3 machines are required to run Tectonic.

Provisioner Node

A provisioner node runs the bootcfg network boot and provisioning service, along with PXE services if you don't already run them elsewhere. You may use CoreOS or any Linux distribution for this node. It provisions nodes, but does not join Tectonic clusters.

A Tectonic cluster consists of two types of nodes:

Controller Nodes

Controller nodes run etcd and the control plane of the cluster.

Worker Nodes

Worker nodes run your applications. New worker nodes will join the cluster by talking to controller nodes for admission.

Networking Requirements

This guide requires familiarity with PXE booting, the ability to configure network services, and to add DNS names. These are discussed in detail below.

2. Provisioning Infrastructure

bootcfg

bootcfg is a service for network booting and provisioning bare-metal nodes into CoreOS clusters. bootcfg should be installed on a provisioner node to serve configs during boot.

The commands to set up bootcfg should be performed on the provisioner node.

Create systemd Service

Customization

Customize bootcfg by editing the systemd unit or adding a systemd dropin. Find the complete set of bootcfg flags and environment variables at config.

sudo systemctl edit bootcfg

By default, the read-only HTTP machine endpoint will be exposed on port 8080. Enable the gRPC API to allow clients with a TLS client certificate to change machine configs. The Tectonic Installer uses this API.

Generate TLS Credentials

The bootcfg API allows client apps such as the Tectonic Installer to manage how machines are provisioned. TLS credentials are needed for client authentication and to establish a secure communication channel.

If your organization manages public key infrastructure and a certificate authority, create a server certificate and key for the bootcfg service and a client certificate and key.

Otherwise, generate a self-signed ca.crt, a server certificate (server.crt, server.key), and client credentials (client.crt, client.key) with the scripts/tls/cert-gen script. Export the DNS name or IP (discouraged) of the provisioner node.

CoreOS provides a dnsmasq container, if you wish to use rkt or Docker.

DNS

The Tectonic Installer will prompt for "Controller" and "Tectonic" DNS names. For the controller DNS name, add a record which resolves to the node you plan to use as a controller.

By default, Tectonic Ingress runs as a Kubernetes Daemon Set across workers. For the Tectonic DNS name, add a record which resolves to any node(s) you plan to use as workers.

For example,

bootcfg.example.com resolves to your bootcfg deployment

controllers.example.com resolves to any controller node

tectonic.example.com resolves to any worker nodes

4. Tectonic Installer

The Tectonic Installer is a graphical application run on your laptop to create Tectonic clusters. It authenticates to bootcfg via its API.

Requirements

Your laptop running the Tectonic installer app must be able to access your bootcfg instance. You will need the client.crt and client.key credentials created when setting up bootcfg to complete the flow, as well as the ca.crt.

The commands to run the Tectonic Installer should be performed on your laptop.

A tab should open in your browser. Follow the instructions to enter information needed for provisioning. You will need to enter machine MAC addresses, domain names, and your SSH public key.

Then, you'll be prompted to power on your machines via IPMI or by pressing the power button and guided through the rest of the bring-up. If needed, you can use the generated assets bundle kubeconfig to troubleshoot.

5. Tectonic Console

After the installer is complete, you'll have a Tectonic cluster and be able to access the Tectonic console. You are ready to deploy your first application on to the cluster!

Viewing a node in the Tectonic Console

Full Uninstall

You can remove all Tectonic components if you'd like to perform a fresh installation to the same cluster.