Introduction

NOTE: The third post of this series is available here.

This blog post is the fourth in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The third post in the series covered further configuration of a cluster once it’s already up and running. At this point you should have a cluster up and running and configured with custom TLS certificates and user login’s outsourced to some other identity management service.

Introduction

NOTE: The second post of this series is available here.

This blog post is the third in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The second post in the series covered the automated deployment and teardown of a cluster using the digitalocean-okd-install script. At this point you should have a cluster up and running and ready to be further customized.

Set Up Custom TLS Certificates

In the first post in this series we mentioned that you may want to have valid certificates for your cluster. For this example we used certbot to talk with Let's Encrypt to get us some certificates for use with our cluster. Assuming the files are in the letsencrypt/ directory we can add the certificates to our cluster like so:

Introduction

NOTE: The first post of this series is available here.

This blog post is the second in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The first post in the series covered some background information and pre-requisites needed for deploying a cluster. At this point you should have chosen the domain for your cluster, set up your registrar to point to DigitalOcean nameservers, installed all necessary software (doctl, openshift-install, oc, aws cli, etc..), and configured appropriate credentials in your environment (DIGITALOCEAN_ACCESS_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).

Introduction

This blog post is the first in a series that will illustrate how to set up an OpenShift OKD cluster on DigitalOcean using the bare metal install documentation (user provisioned infrastructure). OKD has tight integrations with the Operating System and uses Fedora CoreOS as a platform for driving the underlying infrastructure, thus we’ll be deploying on top of Fedora CoreOS images inside of DigitalOcean.

The documentation for OKD is pretty comprehensive, but there is nothing like having a guide to help fill in some of the gaps and show an example of it working with real world values. This series aims to do just that.

If you’ve ever had a chance to “nerd out” with me much I’ve probably told you about at least one TUI that I use to make my daily work life easier. Some of my favorites include htop, tig, tmux (not sure if tmux counts), etc..

Lately I’ve been finding myself using Kubernetes/OpenShift much more and I have often thought to myself I wish a nice TUI existed to get in and navigate resources in a Kubernetes environment. The various web interfaces are nice and comprehensive, and the CLI is awesome too, but each of them are too far on the fringes of what I’ll define as my sweet spot for discoverability vs speed vs power. A well designed TUI sits right in the middle and makes me feel right at home.

Introduction

With Fedora CoreOS we currently have two ways to do a bare metal install and get our disk image onto the spinning rust of a “non-cloud” server. You can use coreos.inst* kernel arguments to automate the install, or you can boot the Live ISO and get a bash prompt where you can then run coreos-installer directly after doing whatever hardware/network discovery that is necessary. This means you either do a simple automated install where you provide all of the information up front or you are stuck doing something interactive. However, because we use a Live ISO that boots full Fedora CoreOS there is a third option.

Introduction

NetworkManager allows connections to be defined in a configuration file known as a keyfile , which is a simple .ini-style formatted file with different key=value pairs. In Fedora CoreOS we’ve elected to use NetworkManager with keyfiles as the way to configure networking. In case you have a standard networking environment with NICs requesting DHCP then you probably won’t need to configure networking. However, if you’d like to have a static networking config or if you’d like to do something more complicated (like configure network teaming for a few interfaces) then you’ll need to create a keyfile that NetworkManager will then use to configure the interfaces on the machine.

Introduction

For some time now with virt-install (developed under virt-manager) you have been able to specify a kernel and initial ramdisk to start a VM with. The only problem is that the VM will always start with that kernel/initrd (unless you change the definition manually). If you are rapidly testing operating system installations this can be problematic.

On the one hand, providing the kernel/initrd allows one to automate the install process from a Linux terminal, or even a script, by specifying the kernel/initrd and also the kernel command line options. However, it only gives us half the picture, because you’d then have to hand edit the libvirt definition of the machine to see if the installed machine was viable, OR you’d be lazy and just throw away the installed machine and assume it was good because the installation process finished without error; BAD.

Setting Up For The Lab

This lab uses a Fedora CoreOS image and several utilities (fcct, ignition-validate) to introduce a user to provisioning and exploring a Fedora CoreOS system. This lab is written targeting a Linux environment with a working libvirt/kvm setup.

To perform this lab you need to download the tar archive at this link (signed checksum file) and extract it.

We recommend extracting it into your home directory like so:

History

It’s almost 2020. Fedora 31 came out a month back and I’m just getting around to converting my desktop system to Fedora 31. As mentioned before, for my laptop systems I’ve moved on to Fedora Silverblue. As I continue to containerize my workflows I’m moving more and more of my daily workflows into Flatpaks from the Fedora registry, pet containers (via toolbox) and, single purpose containers. As I continue to convert my workflows into containers I’ll stick with the BTRFS+snapper setup for my desktop system, which still has the benefits of being able to snapshot and rollback the entire system by leveraging BTRFS snapshots, and a tool called snapper.