mirror of
https://github.com/outbackdingo/matchbox.git
synced 2026-01-27 10:19:35 +00:00
scripts: Improve scripts for use in releases
* Minor documentation tweaks
This commit is contained in:
Dalton Hubble
@@ -19,7 +19,7 @@ Build and install [bootkube](https://github.com/coreos/bootkube).
|
||||
|
||||
## Examples
|
||||
|
||||
The [examples](../examples) statically assign IP addresses to libvirt client VMs created by `scripts/libvirt`. You can use the same examples for real hardware, but you'll need to update the MAC/IP addresses.
|
||||
The [examples](../examples) statically assign IP addresses to libvirt client VMs created by `scripts/libvirt`. You can use the same examples for physical machines, but you'll need to update the MAC/IP addresses. See [network setup](network-setup.md) and [deployment](deployment.md).
|
||||
|
||||
* [bootkube](../examples/groups/bootkube) - iPXE boot a bootkube-ready cluster (use rkt)
|
||||
* [bootkube-install](../examples/groups/bootkube-install) - Install a bootkube-ready cluster (use rkt)
|
||||
@@ -28,7 +28,7 @@ The [examples](../examples) statically assign IP addresses to libvirt client VMs
|
||||
|
||||
Download the CoreOS image assets referenced in the target [profile](../examples/profiles).
|
||||
|
||||
./scripts/get-coreos alpha 1053.2.0
|
||||
./scripts/get-coreos alpha 1053.2.0 ./examples/assets
|
||||
|
||||
Use the `bootkube` tool to render Kubernetes manifests and credentials into an `--asset-dir`. Later, `bootkube` will schedule these manifests during bootstrapping and the credentials will be used to access your cluster.
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ Configuration arguments can be provided as flags or as environment variables.
|
||||
## Version
|
||||
|
||||
./bin/bootcfg -version
|
||||
sudo rkt --insecure-options=image run quay.io/coreos/bootcfg:latest -- -version
|
||||
sudo rkt run quay.io/coreos/bootcfg:latest -- -version
|
||||
sudo docker run quay.io/coreos/bootcfg:latest -version
|
||||
|
||||
## Minimal
|
||||
@@ -68,6 +68,14 @@ Run the Docker image. Mounts are used to add the provided examples.
|
||||
|
||||
The gRPC API can be enabled with the `-rpc-address` flag and by providing a TLS server certificate and key with `-cert-file` and `-key-file` and a CA certificate for authenticating clients with `-ca-file`. gRPC clients (such as `bootcmd`) must verify the server's certificate with a CA bundle passed via `-ca-file` and present a client certificate and key via `-cert-file` and `-key-file`.
|
||||
|
||||
Run the binary with TLS credentials from `examples/etc/bootcfg`.
|
||||
|
||||
./bin/bootcfg -address=0.0.0.0:8080 -rpc-address=0.0.0.0:8081 -log-level=debug -data-path=examples -assets-path=examples/assets -cert-file examples/etc/bootcfg/server.crt -key-file examples/etc/bootcfg/server.key -ca-file examples/etc/bootcfg/ca.crt
|
||||
|
||||
A `bootcmd` client can call the gRPC API.
|
||||
|
||||
./bin/bootcmd profile list --endpoints 127.0.0.1:8081 --ca-file examples/etc/bootcfg/ca.crt --cert-file examples/etc/bootcfg/client.crt --key-file examples/etc/bootcfg/client.key
|
||||
|
||||
Run the ACI with rkt and TLS credentials from `examples/etc/bootcfg`.
|
||||
|
||||
sudo rkt run --net=metal0:IP=172.15.0.2 --mount volume=data,target=/var/lib/bootcfg --volume data,kind=host,source=$PWD/examples,readOnly=true --mount volume=config,target=/etc/bootcfg --volume config,kind=host,source=$PWD/examples/etc/bootcfg --mount volume=groups,target=/var/lib/bootcfg/groups --volume groups,kind=host,source=$PWD/examples/groups/etcd quay.io/coreos/bootcfg:latest -- -address=0.0.0.0:8080 -rpc-address=0.0.0.0:8081 -log-level=debug
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
In this tutorial, we'll run `bootcfg` on your Linux machine with Docker to network boot and provision a cluster of CoreOS machines locally. You'll be able to create Kubernetes clustes, etcd clusters, and test network setups.
|
||||
|
||||
If you're ready to try [rkt](https://coreos.com/rkt/docs/latest/), see [Getting Started with rkt](getting-started-rkt.md).
|
||||
*Note*: To provision physical machines, see [network setup](network-setup.md) and [deployment](deployment.md).
|
||||
|
||||
## Requirements
|
||||
|
||||
@@ -24,8 +24,7 @@ Clone the [coreos-baremetal](https://github.com/coreos/coreos-baremetal) source
|
||||
|
||||
Download CoreOS image assets referenced by the `etcd-docker` [example](../examples) to `examples/assets`.
|
||||
|
||||
./scripts/get-coreos
|
||||
./scripts/get-coreos channel version # examples pin a required version
|
||||
./scripts/get-coreos alpha 1053.2.0 ./examples/assets
|
||||
|
||||
## Containers
|
||||
|
||||
|
||||
@@ -3,6 +3,8 @@
|
||||
|
||||
In this tutorial, we'll run `bootcfg` on your Linux machine with `rkt` and `CNI` to network boot and provision a cluster of CoreOS machines locally. You'll be able to create Kubernetes clustes, etcd clusters, and test network setups.
|
||||
|
||||
*Note*: To provision physical machines, see [network setup](network-setup.md) and [deployment](deployment.md).
|
||||
|
||||
## Requirements
|
||||
|
||||
Install [rkt](https://github.com/coreos/rkt/releases) and [acbuild](https://github.com/appc/acbuild/releases) from the latest releases ([example script](https://github.com/dghubble/phoenix/blob/master/scripts/fedora/sources.sh)). Optionally setup rkt [privilege separation](https://coreos.com/rkt/docs/latest/trying-out-rkt.html).
|
||||
@@ -24,8 +26,7 @@ Clone the [coreos-baremetal](https://github.com/coreos/coreos-baremetal) source
|
||||
|
||||
Download CoreOS image assets referenced by the `etcd` [example](../examples) to `examples/assets`.
|
||||
|
||||
./scripts/get-coreos
|
||||
./scripts/get-coreos channel version
|
||||
./scripts/get-coreos alpha 1053.2.0 ./examples/assets
|
||||
|
||||
Define the `metal0` virtual bridge with [CNI](https://github.com/appc/cni).
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Ensure that you've gone through the [bootcfg with rkt](getting-started-rkt.md) g
|
||||
|
||||
## Examples
|
||||
|
||||
The [examples](../examples) statically assign IP addresses to libvirt client VMs created by `scripts/libvirt`. VMs are setup on the `metal0` CNI bridge for rkt or the `docker0` bridge for Docker. You can use the same examples for real hardware, but you'll need to update the MAC/IP addresses.
|
||||
The [examples](../examples) statically assign IP addresses to libvirt client VMs created by `scripts/libvirt`. VMs are setup on the `metal0` CNI bridge for rkt or the `docker0` bridge for Docker. You can use the same examples for physical machines, but you'll need to update the MAC/IP addresses. See [network setup](network-setup.md) and [deployment](deployment.md).
|
||||
|
||||
* [k8s](../examples/groups/k8s) - iPXE boot a Kubernetes cluster (use rkt)
|
||||
* [k8s-docker](../examples/groups/k8s-docker) - iPXE boot a Kubernetes cluster on `docker0` (use docker)
|
||||
@@ -23,7 +23,7 @@ The [examples](../examples) statically assign IP addresses to libvirt client VMs
|
||||
|
||||
Download the CoreOS image assets referenced in the target [profile](../examples/profiles).
|
||||
|
||||
./scripts/get-coreos alpha 1053.2.0
|
||||
./scripts/get-coreos alpha 1053.2.0 ./examples/assets
|
||||
|
||||
Generate a root CA and Kubernetes TLS assets for components (`admin`, `apiserver`, `worker`).
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ The [examples](..examples) statically assign IP addresses (172.15.0.21, 172.15.0
|
||||
|
||||
Download the CoreOS image assets referenced in the target [profile](../examples/profiles).
|
||||
|
||||
./scripts/get-coreos alpha 1053.2.0
|
||||
./scripts/get-coreos alpha 1053.2.0 ./examples/assets
|
||||
|
||||
## Containers
|
||||
|
||||
|
||||
@@ -15,13 +15,14 @@ CoreOS on Baremetal provides guides and a service for network booting and provis
|
||||
|
||||
`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)
|
||||
* [bootcfg Service](Documentation/bootcfg.md)
|
||||
* [Groups](Documentation/bootcfg.md#groups-and-metadata)
|
||||
* [Profiles](Documentation/bootcfg.md#profiles)
|
||||
* [Ignition](Documentation/ignition.md)
|
||||
* [Cloud-Config](Documentation/cloud-config.md)
|
||||
* Tutorials (libvirt)
|
||||
* [bootcfg with rkt](Documentation/getting-started-rkt.md)
|
||||
* [bootcfg with Docker](Documentation/getting-started-docker.md)
|
||||
* [Flags](Documentation/config.md)
|
||||
* [HTTP API](Documentation/api.md)
|
||||
* [gRPC API](https://godoc.org/github.com/coreos/coreos-baremetal/bootcfg/client)
|
||||
|
||||
@@ -6,7 +6,7 @@ Documentation=https://github.com/coreos/coreos-baremetal
|
||||
Type=simple
|
||||
User=bootcfg
|
||||
Group=bootcfg
|
||||
ExecStart=/usr/local/bin/bootcfg -address=0.0.0.0:8080 -log-level=debug
|
||||
ExecStart=/usr/local/bin/bootcfg -address=0.0.0.0:8080 -rpc-address=0.0.0.0:8081 -log-level=debug
|
||||
|
||||
# systemd.exec
|
||||
ProtectHome=yes
|
||||
|
||||
@@ -9,6 +9,14 @@ Navigate to the example directory which will be mounted as `/etc/bootcfg` in exa
|
||||
|
||||
cd coreos-baremetal/examples/etc/bootcfg
|
||||
|
||||
Set certificate subject alt names which should be used by exporting `SAN`. Use the DNS name or IP at which `bootcfg` is hosted.
|
||||
|
||||
# for examples on metal0 or docker0 bridges
|
||||
export SAN=IP.1:127.0.0.1,IP.2:172.15.0.2
|
||||
|
||||
# production example
|
||||
export SAN=DNS.1:bootcfg.example.com
|
||||
|
||||
Create a fake `ca.crt`, `server.crt`, `server.key`, `client.crt`, and `client.key`. Type 'Y' when prompted.
|
||||
|
||||
$ ./cert-gen
|
||||
|
||||
@@ -22,8 +22,6 @@ openssl req -config openssl.conf -new -x509 -days 3650 -sha256 -key ca.key -exte
|
||||
openssl genrsa -out server.key 2048
|
||||
# Server certificate signing request (CSR)
|
||||
openssl req -config openssl.conf -new -sha256 -key server.key -out server.csr -subj "/CN=fake-server"
|
||||
# Suitable SANs for bootcfg on 172.15.0.2(rkt example) and 127.0.0.1(docker example)
|
||||
export SAN=IP.1:127.0.0.1,IP.2:172.15.0.2
|
||||
# Certificate Authority signs CSR to grant a certificate
|
||||
openssl ca -config openssl.conf -extensions server_cert -days 365 -notext -md sha256 -in server.csr -out server.crt -cert ca.crt -keyfile ca.key
|
||||
|
||||
|
||||
@@ -1,21 +1,22 @@
|
||||
#!/bin/bash -e
|
||||
# USAGE: ./scripts/get-coreos
|
||||
# USAGE: ./scripts/get-coreos channel version
|
||||
# USAGE: ./scripts/get-coreos channel version dest
|
||||
|
||||
CHANNEL=${1:-"alpha"}
|
||||
VERSION=${2:-"1053.2.0"}
|
||||
DEST=${PWD}/examples/assets/coreos/$VERSION
|
||||
DEST_DIR=${3:-"$PWD/examples/assets"}
|
||||
DEST=$DEST_DIR/coreos/$VERSION
|
||||
BASE_URL=https://$CHANNEL.release.core-os.net/amd64-usr/$VERSION
|
||||
|
||||
# check channel/version exist based on the header response
|
||||
curl -s -I $BASE_URL/coreos_production_pxe.vmlinuz | awk '/200/ {found++} /301/ {found++} END { if (found<1) { print "Channel or Version not found"; exit 1 }}'
|
||||
curl -s -I $BASE_URL/coreos_production_pxe.vmlinuz | awk '/1.1 200/ {found++} /1.1 301/ {found++} END { if (found<1) { print "Channel or Version not found"; exit 1 }}'
|
||||
|
||||
if [ ! -d "$DEST" ]; then
|
||||
echo "Creating directory $DEST"
|
||||
mkdir -p $DEST
|
||||
fi
|
||||
|
||||
echo "Downloading CoreOS $CHANNEL $VERSION images and signatures"
|
||||
echo "Downloading CoreOS $CHANNEL $VERSION images and sigs to $DEST"
|
||||
|
||||
# PXE kernel and sig
|
||||
echo "coreos_production_pxe.vmlinuz..."
|
||||
|
||||
Reference in New Issue
Block a user