----
A Bare Metal Configuration Service for CoreOS Linux
// CoreOS Blog
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.
Config service
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.
Guides
The coreos-baremetal guides:
- Walk through network booting and configuring CoreOS clusters on virtual and physical hardware.
- Review network booting principles.
- Discuss how to configure a network boot environment, taking into account existing PXE, iPXE, or DHCP services you may have running.
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.
Example for booting Kubernetes
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.
Getting started
Get started on your Linux machine with libvirt and virt-manager.
sudo dnf install virt-manager virt-install docker sudo systemctl start docker git clone https://github.com/coreos/coreos-baremetal.git cd coreos-baremetal This example uses Docker and its network to run services - stay tuned for a rkt guide in coreos-baremetal.
Create 5 VM nodes which have known "hardware" attributes that match the examples:
./scripts/libvirt create Pull the config service from Quay:
docker pull quay.io/coreos/bootcfg:latest Download the CoreOS network boot images to assets/coreos:
./scripts/get-coreos Now run the config service on the same virtual network as the libvirt VM nodes and mount the etcd-large example with image assets.
docker run -p 8080:8080 --name=bootcfg --rm -v $PWD/examples/etcd-large:/data:Z -v $PWD/assets:/assets:Z quay.io/coreos/bootcfg:latest -address=0.0.0.0:8080 -log-level=debug Since the virtual network has no network boot services, let's set up an example iPXE environment which runs DHCP and TFTP. You may need to update your firewall to allow DHCP and TFTP services.
docker run --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q --dhcp-range=172.17.0.43,172.17.0.99 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://172.17.0.2:8080/boot.ipxe This network environment and example are specific to the IP address and subnet assigned when trying this on your laptop. To run the config service in another environment, such as a physical network with physical machines, adapt the subnet and IP or DNS name.
At this point, if you reboot the VMs, you should get a CoreOS cluster in which nodes 1, 2, and 3 run etcd, while the remaining nodes proxy to them.
Learn more about the config service, explore the libvirt examples, and adapt them to start writing specifications for your own hardware.
Going further
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!
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment