By Dalton Hubble, January 22, 2016
Originally published on the CoreOS blog (archived copy) . Re-published with the authors' permission.
We’re developing coreos-baremetal, a configuration distribution service and a set of guides for network-booting and configuring CoreOS Linux clusters on bare metal hardware. The project is at an early proof-of-concept stage, but the ultimate goal is to automate the creation of secure CoreOS Linux clusters in your data center.
Whether you are managing a small, experimental cluster or a large number of machines in a data center, coreos-baremetal aims to help you network-boot your infrastructure, configure early machine bootstrapping, and leverage the capabilities of CoreOS and Tectonic for cluster provisioning. We’ve used the project to boot a pile of bare metal machines into etcd clusters or TLS-authenticated Kubernetes clusters in about three minutes.
We’ve been developing a new bare metal config service (v0.1.0) that supports PXE, iPXE, and Pixiecore network boot environments and serves CoreOS Ignition configs and Cloud-Configs to machines. One or more machines are matched to specifications based on their hardware attributes, or by free-form tags. Boot images, kernel arguments, Ignition configs, or cloud configs can be defined for different machines. This lets you control machine bootup with signed configs and provision the machine during both kernel bootstrap and userspace startup.
The coreos-baremetal guides walk through network booting and configuring CoreOS clusters on virtual and bare metal hardware. We’ve included a few fixed examples that network-boot a set of libvirt VMs on your laptop with multi-node etcd and Kubernetes clusters.
As part of CoreOS’s mission to improve the security of the world’s infrastructure, we’ll be adding features to support Tectonic Distributed Trusting Computing (DTC), binding configuration in the chain of trust established at the hardware level by DTC’s innovative use of server TPM facilities.
Read on to dive in deeper, and be sure to join us at our San Francisco Meetup on January 27 at 6 p.m. PT to see a live talk about this CoreOS Bare Metal Configuration Service for CoreOS Linux.
With coreos-baremetal, the network environment points network-boot client machines to an instance of the config service, on the network, which manages the rest of the boot, install, and configuration process to prepare a functioning CoreOS cluster.
Network environments can be configured to point network boot client machines to a boot configuration endpoint, while chainloading clients with older firmware. The guides discuss how to configure a DHCP service or a standalone proxy DHCP service for this purpose.
The Config service maintains specifications that are groupings of the boot images, kernel arguments, Ignition configs, and cloud configs. This lets you configure the boot, kernel startup, and user space startup of machines. Machines are matched to specifications based on hardware attributes or by free-form tags.
For example, a machine with a specific UUID or MAC address might be associated with a kubernetes-master specification or a group of machines might match to an etcd-worker specification. Free-form tag matchers allow you to perform advanced multi-stage configuration if desired, such as configuring a machine for a specific role after CoreOS installs to disk.
Here is a sample associating machine tags to specifications:
---
api_version: v1alpha1
groups:
- name: Kubernetes Master Node
spec: master
require:
uuid: 16e7d8a7-bfa9-428b-9117-363341bb330b
- name: Generic Worker Nodes
spec: worker
require:
region: us-central1-a
role: worker
- name: All Other Machines
spec: default
Currently, the config service is backed by a filesystem so the declarative set of tag matchers, specifications, Ignition configs, and cloud configs for your infrastructure can be kept under version control.
The coreos-baremetal guides:
Then you’re ready to use the config service to boot machines into clusters!
If you’d like to get started quickly on a Linux laptop, you can run the config service on a virtual network with libvirt VMs and try the examples. They include a single-node etcd cluster, multi-node etcd cluster, and multi-node Kubernetes cluster on CoreOS.
We love running Kubernetes on CoreOS so we’ve included a set of examples for booting a multi-node Kubernetes cluster. Run the config service with the Kubernetes example on a virtual network or adjust the subnet, IP addresses, and machine attributes for a physical network of machines.
Start network booting CoreOS clusters with etcd or Kubernetes under libvirt, right from your Linux machine. Get started using either rkt or docker.
Next, try deploying clusters on your own network and hardware with the bare metal guide or learn more about the config service.
Stay tuned for future developments and improvements. Support for OpenPGP signed configs, the GNU GRUB bootloader, and metadata services are planned. We’ll have more to say about distributed trusted computing, secure booting, and secret distribution in the future.
Please contribute and file any issues that you find. We welcome your feedback. And, feel free to stop by our SF meetup to learn more. Let us know what you’d like to see next!