github-personal/matchbox
1
0
Fork 0
mirror of https://github.com/outbackdingo/matchbox.git synced 2026-01-27 18:19:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #159 from coreos/network-docs-wip

Browse Source 
docs: Add network setup guide and flow diagram
This commit is contained in:
Dalton Hubble
2016-06-14 23:50:30 -07:00
committed by GitHub
parent d5fef3f9a7 4672903c2a
commit 4dc6bbe29c
8 changed files with 181 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/bootcfg.md
View File

@@ -5,6 +5,8 @@
Network boot endpoints provide PXE, iPXE, GRUB, and [Pixiecore](https://github.com/danderson/pixiecore/blob/master/README.api.md) support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with rkt, or as a Docker container.
<img src='img/overview.png' class="img-center" alt="Bootcfg Overview"/>
## Getting Started
Get started running `bootcfg` on your Linux machine, with rkt or Docker, to network boot virtual or physical machines into CoreOS clusters.
@@ -12,15 +14,14 @@ Get started running `bootcfg` on your Linux machine, with rkt or Docker, to netw
* [bootcfg with rkt](getting-started-rkt.md)
* [bootcfg with Docker](getting-started-docker.md)
<img src='img/overview.png' class="img-center" alt="Bootcfg Overview"/>
## Flags
See [flags and variables](config.md)
## API
See [API](api.md)
* [HTTP API](api.md)
* [gRPC API](https://godoc.org/github.com/coreos/coreos-baremetal/bootcfg/client)
## Data
@@ -44,11 +45,6 @@ Prepare `/var/lib/bootcfg` with `profile`, `groups`, `ignition`, and `cloud` sub
└── etcd.json
└── worker.json
Ignition templates can be JSON or YAML files (rendered as JSON). Cloud-Config templates can be a script or YAML file. Both may contain [Go template](https://golang.org/pkg/text/template/) elements which will be executed with machine Group [metadata](#groups-and-metadata). For details and examples:
* [Ignition Config](ignition.md)
* [Cloud-Config](cloud-config.md)
### Profiles
Profiles specify a Ignition config, Cloud-Config, and network boot config.
@@ -76,6 +72,13 @@ To use cloud-config, set the `cloud-config-url` kernel option to reference the `
To use Ignition, set the `coreos.config.url` kernel option to reference the `bootcfg` [Ignition endpoint](api.md#ignition-config), which will render the `ignition_id` file. Be sure to add the `coreos.first_boot` option as well.
### Configs
Ignition templates can be JSON or YAML files (rendered as JSON). Cloud-Config templates can be a script or YAML file. Both may contain [Go template](https://golang.org/pkg/text/template/) elements which will be executed with machine Group [metadata](#groups-and-metadata). For details and examples:
* [Ignition Config](ignition.md)
* [Cloud-Config](cloud-config.md)
## Groups and Metadata
Groups define selectors which match zero or more machines. Machine(s) matching a group will boot and provision according to the group's `Profile` and `metadata`.

3
Documentation/getting-started-docker.md
View File

@@ -85,6 +85,5 @@ Clean up the VM machines.
## Going Further
Explore the [examples](../examples). Try the [k8s-docker example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)).
Learn more about [bootcfg](bootcfg.md) or explore the other [example](../examples) clusters. Try the [k8s-docker example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)).
Learn more about [bootcfg](bootcfg.md) or adapt an example for your own [physical hardware](physical-hardware.md) and network.

3
Documentation/getting-started-rkt.md
View File

@@ -123,6 +123,5 @@ Press ^] three times to stop a rkt pod. Clean up the VM machines.
## Going Further
Explore the [examples](../examples). Try the [k8s example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)).
Learn more about [bootcfg](bootcfg.md) or explore the other [example](../examples) clusters. Try the [k8s example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)).
Learn more about [bootcfg](bootcfg.md) or adapt an example for your own [physical hardware](physical-hardware.md) and network.

BIN
Documentation/img/network-setup-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

20
Documentation/network-booting.md
View File

@@ -1,9 +1,7 @@
# Network Boot Environments
These guides walk through booting and configuring CoreOS on real or virtual hardware on your network. This introductory document reviews network booting protocols and the requirments of your network environment.
Once you've reviewed the protocols, you'll be ready to [get started](getting-started-rkt.md) serving configs to machines during boot with [bootcfg](bootcfg.md).
This guide reviews network boot protocols and the different ways client machines can be PXE booted.
## PXE
@@ -45,8 +43,6 @@ PXELINUX then downloads the specified kernel and init RAM filesystem images with
This approach has a number of drawbacks. TFTP can be slow, managing config files can be tedious, and using different ignition or cloud configs on different machines requires separate pxelinux configs. These limitations spurred the development of various enhancements to PXE, discussed next.
In these guides, PXE is used to load the iPXE boot file so iPXE can chainload config scripts and HTTP images over HTTP. Continue to the [baremetal guide](physical-hardware.md) to boot PXE clients by chainloading iPXE. Consult [CoreOS with PXE](https://coreos.com/os/docs/latest/booting-with-pxe.html) for details about CoreOS support for PXE.
#### iPXE
[iPXE](http://ipxe.org/) is an enhanced implementation of the PXE client firmware and a network boot program which uses iPXE scripts rather than config files and can download scripts and images with HTTP.
@@ -70,24 +66,14 @@ A TFTP server is used only to provide the `undionly.kpxe` boot program to older
CoreOS `bootcfg` can render signed iPXE scripts to machines based on their hardware attributes. Setup involves configuring your DHCP server to point iPXE clients to the `bootcfg` [iPXE endpoint](api.md#ipxe).
Continue to the [baremetal guide](physical-hardware.md) to use iPXE to boot PXE/iPXE client machines. Consult [CoreOS with iPXE](https://coreos.com/os/docs/latest/booting-with-ipxe.html) for details about CoreOS support for iPXE.
#### Pixiecore
[Pixiecore](https://github.com/danderson/pixiecore) is a newer service which implements a proxyDHCP server, TFTP server, and HTTP server all-in-one and calls through to an HTTP API. CoreOS `bootcfg` can serve Pixiecore JSON (optionally signed) based on the supplied MAC address, to implement the Pixiecore HTTP API.
## Network Environments
## DHCP
### DHCP
Many networks have DHCP services which are impractical to modify or disable. Corporate DHCP servers are governed by network admin policies and home/office networks often have routers running a DHCP service which cannot supply PXE options to PXE clients.
Many networks have DHCP services which are impractical to modify or disable. Company DHCP servers are governed by network admin policies and home/office networks often have routers running a DHCP service which cannot supply PXE options to PXE clients.
To address this, PXE client firmware listens for DHCPOFFERs from a non-PXE DHCP server *and* a PXE-enabled **proxyDHCP server** configured to respond with the next server and boot filename only. Client firmware combines the two responses as if they had come from a single PXE-enabled DHCP server.
<img src='img/proxydhcp.png' class="img-center" alt="DHCP and proxyDHCP responses are merged to get PXE Options"/>
The [baremetal guide](physical-hardware.md) shows how to check your network environment and run either a standalone PXE-enabled DHCP server, a proxyDHCP server to compliment your existing network DHCP service, or configure existing services.
## Configuration Service
Now that you understand network booting protocols [get started](getting-started-rkt.md) serving configs to machines during boot with [bootcfg](bootcfg.md).

160
Documentation/network-setup.md Normal file
View File

@@ -0,0 +1,160 @@
# Network Setup
This guide shows how to create a DHCP/TFTP/DNS network boot environment to work with `bootcfg` to boot and provision PXE, iPXE, or GRUB2 client machines.
`bootcfg` serves iPXE scripts or GRUB configs over HTTP to serve as the entrypoint for CoreOS cluster bring-up. It does not implement or exec a DHCP, TFTP, or DNS server. Instead, you can configure your own network services to point to `bootcfg` or use the convenient [coreos/dnsmasq](../contrib/dnsmasq) container image (used in libvirt demos).
*Note*: These are just suggestions. Your network administrator or system administrator should choose the right network setup for your company.
## Requirements
Client hardware must have a network interface which supports PXE or iPXE.
## Goals
* Add a DNS name which resolves to a `bootcfg` deploy.
* Chainload PXE firmware to iPXE or GRUB2
* Point iPXE clients to `http://bootcfg.foo:port/boot.ipxe`
* Point GRUB clients to `http://bootcfg.foo:port/grub`
## Setup
Many companies already have DHCP/TFTP configured to "PXE-boot" PXE/iPXE clients. In this case, machines (or a subset of machines) can be made to chainload from `chain http://bootcfg.foo:port/boot.ipxe`. Older PXE clients can be made to chainload into iPXE or GRUB to be able to fetch subsequent configs via HTTP.
On simpler networks, such as what a developer might have at home, a relatively inflexible DHCP server may be in place, with no TFTP server. In this case, a proxy DHCP server can be run alongside a non-PXE capable DHCP server.
This diagram can point you to the **right section(s)** of this document.
<img src='img/network-setup-flow.png' class="img-center" alt="Network Setup Flow"/>
The setup of DHCP, TFTP, and DNS services on a network varies greatly. If you wish to use rkt or Docker to quickly run DHCP, proxyDHCP TFTP, or DNS services, use [coreos/dnsmasq](#coreos/dnsmasq).
## DNS
Add a DNS entry (e.g. `bootcfg.foo`, `provisoner.mycompany-internal`) that resolves to a deployment of the CoreOS `bootcfg` service from machines you intend to boot and provision.
dig bootcfg.foo
If you deployed `bootcfg` to a known IP address (e.g. dedicated host, load balanced endpoint, Kubernetes NodePort) and use `dnsmasq`, a domain name to IPv4/IPv6 address mapping could be added to the `/etc/dnsmasq.conf`.
# dnsmasq.conf
address=/bootcfg.foo/172.15.0.2
## iPXE
Servers with DHCP/TFTP/ services which already network boot iPXE clients can use the `chain` command to make clients download and execute the iPXE boot script from `bootcfg`.
# /var/www/html/ipxe/default.ipxe
chain http://bootcfg.foo:8080/boot.ipxe
You can chainload from a menu entry or use other [iPXE commands](http://ipxe.org/cmd) if you have needs beyond just delegating to the iPXE script served by `bootcfg`.
## GRUB
Needs docs.
### Configuring DHCP
Configure your DHCP server to supply options to older PXE client firmware to specify the location of an iPXE or GRUB network boot program on your TFTP server. Send clients to the `bootcfg` iPXE script or GRUB config endpoints.
Here is an example `/etc/dnsmasq.conf`:
dhcp-range=192.168.1.1,192.168.1.254,30m
enable-tftp
tftp-root=/var/lib/tftpboot
# if request comes from older PXE ROM, chainload to iPXE (via TFTP)
dhcp-boot=tag:!ipxe,undionly.kpxe
# if request comes from iPXE user class, set tag "ipxe"
dhcp-userclass=set:ipxe,iPXE
# point ipxe tagged requests to the bootcfg iPXE boot script (via HTTP)
dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe
# verbose
log-queries
log-dhcp
# (optional) disable DNS
port=0
# (optional) static DNS assignements
# address=/bootcfg.foo/192.168.1.100
Add [unidonly.kpxe](http://boot.ipxe.org/undionly.kpxe) (and undionly.kpxe.0 if using dnsmasq) to your tftp-root (e.g. `/var/lib/tftpboot`).
sudo systemctl start dnsmasq
sudo firewall-cmd --add-service=dhcp --add-service=tftp [--add-service=dns]
sudo firewall-cmd --list-services
#### proxy DHCP
Alternately, a DHCP proxy server can be run alongside an existing non-PXE DHCP server. The proxy DHCP server provides only the next server and boot filename Options, leaving IP allocation to the DHCP server. Clients listen for both DHCP offers and merge the responses as though they had come from one PXE-enabled DHCP server.
Example `/etc/dnsmasq.conf`:
dhcp-range=192.168.1.1,proxy,255.255.255.0
enable-tftp
tftp-root=/var/lib/tftpboot
# if request comes from older PXE ROM, chainload to iPXE (via TFTP)
pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe
# if request comes from iPXE user class, set tag "ipxe"
dhcp-userclass=set:ipxe,iPXE
# point ipxe tagged requests to the bootcfg iPXE boot script (via HTTP)
pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe
# verbose
log-queries
log-dhcp
Add [unidonly.kpxe](http://boot.ipxe.org/undionly.kpxe) (and undionly.kpxe.0 if using dnsmasq) to your tftp-root (e.g. `/var/lib/tftpboot`).
sudo systemctl start dnsmasq
sudo firewall-cmd --add-service=dhcp --add-service=tftp [--add-service=dns]
sudo firewall-cmd --list-services
With rkt:
sudo rkt run coreos.com/dnsmasq:v0.3.0 --net=host -- -d -q --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe --log-queries --log-dhcp
With Docker:
sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe --log-queries --log-dhcp
### Configurable TFTP
If your DHCP server is configured to PXE boot clients, but you don't have control over this configuration, you can modify the pxelinux.cfg's served to PXE clients.
Example `/var/lib/tftpboot/pxelinux.cfg/default`:
timeout 10
default iPXE
LABEL iPXE
KERNEL ipxe.lkrn
APPEND dhcp && chain http://bootcfg.foo:8080/boot.ipxe
Add ipxe.lkrn to `/var/lib/tftpboot` (see [iPXE docs](http://ipxe.org/embed)).
## coreos/dnsmasq
On networks without network services, the `coreos.com/dnsmasq:v0.3.0` rkt ACI or `coreos/dnsmasq:latest` Docker image can setup an appropriate environment quickly. The images bundle `undionly.kpxe` and `grub.efi` for convenience. Here are some examples which run a DHCP/TFTP/DNS server on your host's network:
With rkt:
```
sudo rkt trust --prefix coreos.com/dnsmasq
# gpg key fingerprint is: 18AD 5014 C99E F7E3 BA5F 6CE9 50BD D3E0 FC8A 365E
```
```
sudo rkt run coreos.com/dnsmasq:v0.3.0 --net=host -- -d -q --dhcp-range=192.168.1.3,192.168.1.254 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe --address=/bootcfg.foo/192.168.1.2 --log-queries --log-dhcp
```
With Docker:
```
sudo docker run --rm --cap-add=NET_ADMIN --net=host quay.io/coreos/dnsmasq -d -q --dhcp-range=192.168.1.3,192.168.1.254 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe --address=/bootcfg.foo/192.168.1.2 --log-queries --log-dhcp
```
Ensure that `bootcfg.foo` resolves to a `bootcfg` deployment and that you've allowed the services to run in your firewall configuration.
sudo firewall-cmd --add-service=dhcp --add-service=tftp --add-service=dns
## Troubleshooting
See [troubleshooting](troubleshooting.md).

103
Documentation/physical-hardware.md
View File

@@ -1,103 +0,0 @@
# CoreOS on Baremetal/Physical Hardware
Physical or baremetal hardware can be booted and configured with CoreOS by PXE, iPXE, and Pixiecore network environments. This guide will show how to setup and test network boot environments with physical clients.
DHCP, TFTP, and HTTP services can run on separate network hosts or on the same host in PXE network environments. We'll focus on configuring a single *provisioner* Linux host to run these services as containers.
## Requirements
Client hardware boot firmware must support PXE or iPXE and the client must have at least one PXE-capable network interface. Most boot firmware and network cards support PXE so you're probably ok.
## Inspect
Identify whether the network runs a DHCP service which can be configured or whether you'll need to run a proxyDHCP service. Check a host's routing table to find the gateway where DHCP is likely to be running.
route -n # e.g. Gateway 192.168.1.1
## bootcfg
Set up `bootcfg` according to the [docs](bootcfg.md). Pull the `coreos/bootcfg` image, prepare a data volume with `Machine` definitions, `Spec` definitions and ignition/cloud configs. Optionally, include a volume of downloaded image assets.
Run the `bootcfg` container to serve configs for any of the network environments we'll discuss next.
docker run -p 8080:8080 --net=host --name=bootcfg --rm -v $PWD/examples:/data:Z -v $PWD/assets:/assets:Z coreos/bootcfg:latest -address=0.0.0.0:8080 -log-level=debug -config /data/etcd-docker.yaml
Note, the kernel options in the `Spec` [examples](../examples) reference 172.17.0.2 (the libvirt case). Your kernel cmdline options should reference the IP or DNS name where `bootcfg` runs.
## Network Setups
Your network may already have a configurable PXE or iPXE server, configurable DHCP, a DHCP server you cannot modify, or no DHCP server at all. We'll show how to setup each network environment to talk to `bootcfg`, depending on your circumstances.
Otherwise create a PXE, iPXE, or Pixiecore network boot environment using the CoreOS [dnsmasq](../contrib/dnsmasq) container image which can run DHCP, proxyDHCP, TFTP, and/or DNS with `dnsmasq`. Use `--net=host` to run the services on the host and use `--dhcp-boot` to point clients to `bootcfg`.
### Configurable iPXE
If your network environment already supports iPXE, edit your iPXE boot script to chainload from `bootcfg`
# boot.ipxe
chain http://192.168.1.100:8080/boot.ipxe
Substitute the name or IP and port where `bootcfg` runs.
### Configurable DHCP
If the DHCP server on your network is PXE-enabled and configurable, send the `bootcfg` iPXE endpoint as the boot filename option (e.g. `http://192.168.1.100:8080/boot.ipxe`). Substitute the name or IP and port where `bootcfg` runs.
Optionally, respond to older PXE client firmware with the location of the `undionly.kpxe` boot program on your TFTP server.
With `dnsmasq`, here is an example `dnsmasq.conf`
# dnsmasq.conf
dhcp-range=192.168.1.1,192.168.1.254,30m
enable-tftp
tftp-root=/var/lib/tftpboot
# set tag "ipxe" if request comes from iPXE ("iPXE" user class)
dhcp-userclass=set:ipxe,iPXE
# if PXE request came from regular firmware, serve iPXE firmware (via TFTP)
dhcp-boot=tag:!ipxe,undionly.kpxe
# if PXE request came from iPXE, serve an iPXE boot script (via HTTP)
dhcp-boot=tag:ipxe,http://192.168.1.100:8080/boot.ipxe
### proxyDHCP
If the network already runs a DHCP service, setup a PXE/iPXE network environment alongside it with proxyDHCP and TFTP.
Run DHCP in proxy mode to respond to DHCP requests on the subnet. Optionally, serve the `undionly.pxe` boot file to older, non-iPXE clients (the '#' means not). Detect iPXE clients by the user class sent in their DHCPDISCOVER (or by Option 175) and point them to the `bootcfg` iPXE boot script.
```
sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q -i enp0s25 --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://192.168.1.100:8080/boot.ipxe
```
Change the `dhcp-range`, `-i interface`, and boot.ipxe endpoint to match your environment.
In this example, an existing router at 192.168.1.1 runs DHCP to allocate IP addresses between 192.168.1.2 and 192.168.1.254. The proxyDHCP is configured to respond to disocver requests on the 192.168.1.0/24 subnet. `bootcfg` runs on host (192.168.1.100) to serve iPXE boot scripts.
### DHCP
If the network does not already run a DHCP service, you can run one yourself and provide PXE options to baremetal clients. This is the case if your baremetal machines are connected to an isolated switch.
Identify a host machine which should run the DHCP service. If this machine has two NICs, it can serve as a router, using one for the uplink connection and the other to connect to the subnet with baremetal clients.
Run DHCP to allocate IP address leases and TFTP to serve the `undionly.pxe` boot file to older, non-iPXE clients (the '#' means not). Point iPXE clients to the `bootcfg` iPXE boot script.
```
sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q -i enp0s20u1 --dhcp-range=192.168.1.101,192.168.1.150 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://192.168.1.100:8080/boot.ipxe
```
Change the `dhcp-range`, `-i interface`, and boot.ipxe endpoint to match your environment.
In this example, a DHCP server is configured to allocate IP addresses between 192.168.1.101 and 192.168.1.150. `bootcfg` runs on host (192.168.1.100) to serve iPXE boot scripts.
You may have to explicitly assign the interface (-i) a network address and mark the interface as up.
ip addr add 192.168.1.100/24 dev enp0s20u1
ip link set dev enp0s20u1 up
## Troubleshooting
See [troubleshooting](troubleshooting.md).
### Alternatives
If you prefer, [Debian](http://www.debian-administration.org/article/478/Setting_up_a_server_for_PXE_network_booting), [Fedora](https://docs.fedoraproject.org/en-US/Fedora/7/html/Installation_Guide/ap-pxe-server.html), and [Ubuntu](https://help.ubuntu.com/community/DisklessUbuntuHowto) provide guides on PXE server setups. CoreOS-baremetal also includes [Vagrantfiles](vagrant) to quickly setup example Fedora PXE, iPXE, and Pixiecore servers on libvirt.

8
README.md
View File

@@ -7,12 +7,13 @@ CoreOS on Baremetal provides guides and a service for network booting and provis
## Guides
* [Network Booting](Documentation/network-booting.md)
* [Network Setup](Documentation/network-setup.md)
* [Machine Lifecycle](Documentation/machine-lifecycle.md)
* [Background: PXE Booting](Documentation/network-booting.md)
## bootcfg
`bootcfg` is an HTTP and gRPC service that renders signed [Ignition configs](https://coreos.com/ignition/docs/latest/what-is-ignition.html), [cloud-configs](https://coreos.com/os/docs/latest/cloud-config.html), network boot configs, and metadata to machines to create CoreOS clusters. Groups match machines based on labels (e.g. UUID, MAC, stage, region) and use named Profiles for provisioning. Network boot endpoints provide PXE, iPXE, GRUB, and Pixiecore support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with [rkt](https://coreos.com/rkt/docs/latest/), or as a Docker container.
`bootcfg` is an HTTP and gRPC service that renders signed [Ignition configs](https://coreos.com/ignition/docs/latest/what-is-ignition.html), [cloud-configs](https://coreos.com/os/docs/latest/cloud-config.html), network boot configs, and metadata to machines to create CoreOS clusters. Groups match machines based on labels (e.g. MAC, UUID, stage, region) and use named Profiles for provisioning. Network boot endpoints provide PXE, iPXE, GRUB, and Pixiecore support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with [rkt](https://coreos.com/rkt/docs/latest/), or as a Docker container.
* [bootcfg with rkt](Documentation/getting-started-rkt.md)
* [bootcfg with Docker](Documentation/getting-started-docker.md)
@@ -22,7 +23,8 @@ CoreOS on Baremetal provides guides and a service for network booting and provis
* [Ignition](Documentation/ignition.md)
* [Cloud-Config](Documentation/cloud-config.md)
* [Flags](Documentation/config.md)
* [API](Documentation/api.md)
* [HTTP API](Documentation/api.md)
* [gRPC API](https://godoc.org/github.com/coreos/coreos-baremetal/bootcfg/client)
* Backends
* [FileStore](Documentation/bootcfg.md#data)
* Deployment via