Pi Kube
Centralized Authentication Part 1: Overview

Maintaining a cluster of single-board computers can be a headache at times. Keeping a bunch of computers that should all be configured the same actually the same is a challenge. Fortunately, there are some tools available for managing your cluster that help make some of it easier. In this series, I’m going to discuss my home lab setup, and describe some of the components I’ve built to take some of the headache out of running it. Along the way, we will use ansible, k3s and docker, as well as some other open-source projects. Nothing I’m recommending here is necessarily the “best” way to do any of it; the whole point of a lab is to experiment and learn.

Let’s start out by listing the commponents of my lab. I have the following systems running:

  • oort is a Lenovo ThinkCenter M93p Small Pro that I bought off EBay for $72. As delivered, it has an Intel core I5 Haswell CPU running at 3.4Ghz with 4GB of RAM and a 500GB Seagate Baracuda drive. While the system has integrated graphics and I planned to use them, the unit I received also has a low-profile NVIDIA Geforce GT 620 card in it, which was a nice bonus. Besides a thorough dusting, I’ve replaced the RAM with a pair of 8GB DDR3 DIMM modules, and pulled the hard drive in favor of a 250GB Western Digital SSD. _oort is my principle development machine in the lab. It runs Ubuntu 20.04 Desktop flawlessly, and is more than capable for the task.
  • atomic is an Atomic Pi SBC based on an Intell Atom x5-Z8350. It boots Ubuntu 20.04 from a Hitachi 1TB HDD that I rescued from a laptop. This system is primary used for CI/CD builds, although I used it to manage the cluster before I got the M93p.
  • pi.hole is a Raspberry Pi 4b with 2GB of RAM. It runs Ubuntu 20.04 server, and pi-hole as a DHCP and DNS server for my home network. Occasionally, we turn the filters on, but my partner works as a sales trainer for a media company, so not being able to see how sales links work gets in the way of her work.
  • pi_kube is a cluster of five 4GB Raspberry Pi boards that runs k3s on Ubuntu 20.04. The kubernetes cluster hosts this website, as well as a Gitea instance, a Docker registry and a Drone CI instance.
  • rockpi-4b is, as you would expect, a Rock PI-4b with 4GB running an experimental Armbian 20.04 build. It’s been upgraded with a 16GB EMMC for booting and a 128GB NVME for storage. This currently houses an instance of Rancher I’ve been experimenting with, and is also joined as a node to the pi_kube cluster.
  • files is an Odroid XU-4 in a Cloudshell 2 case, with a pair of Seagate Iron Wolf 1TB drives configured as a RAID-1 array. It’s currently my main file server, used for
    • NFS mounts to the cluster (I have an NFS mount on the local-storage target directory for the whole cluster.)
    • Persistent Volume Claims using the nfs-client provisioner for Kubernetes. This is eventually going to be my main PV/PVC storage as I move away from using local-storage.
    • Samba mount space for the Windows computers on my network, used for file sharing between my partner and I.
    • NFS mounts to each of the SBCs in the lab, which I will discuss later in this series.
  • rock64 is a 2GB Rock64 system with EMMC boot, which is the system I will be setting up as an OpenLDAP server in this series. It runs Armbian 20.04.
  • My latest SBC is an Odroid C4. It’s running Ubuntu 20.04 from EMMC, and has a 500GB Western Digital SSD attached via USB. I’m not sure what I’m going to do with this system yet.

The immediate goal for this series is to build an OpenLDAP server and configure my lab systems to use it as a user directory, and to set up home drives on NFS. In the next article, I will go over how I build docker images, as a guide for providing armhf and arm64 images for some Docker Hub-distributed tools that aren’t currently available for those architectures.

9 Jun 2020
Design pdevty