For some reason™ Mongo changed the minimum ARM version supported for their official builds of the MongoDB arm64 server to ARMv8.2. The Raspberry Pi 4, which runs on a Cortex A72, only supports ARMv8. This means that if you are trying to run a MongoDB server on a Raspberry Pi 4, you’ll be met with a slew of “Illegal instruction (core dumped)” messages.
This wouldn’t be much of an issue if Ubiquiti hadn’t decided to use MongoDB for their database.
After numerous years of running the majority of my web presence entirely on kubernetes (shout-out to k3s for simplifying the task for smaller deployments), I decided to migrate to a new setup. This series will explore the migration and configuration of this new setup.
Following upgrades in our on-premise environment, and the fact that ultra-high availability wasn’t a requirement, I decided to experiment with running the services on-premise, but exposing them to the internet through a remote POP.
Proxmox (the Proxmox Virtual Environment, PVE) is a great open-source virtualization platform. Built on top of the Debian Linux distribution (with a modified Ubuntu kernel), PVE leverages KVM for virtual machines and LXC for containers.
In smaller clusters, as would be typical in a home-lab environment, the presence of an odd number of nodes (3 or more) is not guaranteed. As such, PVE provides a small component, called QDevice, that augments the number of voting members to enhance the cluster resilience.
As the QDevice only provides a voter for quorum and no virtualization support, it can be installed on Raspberry Pi devices.
node-exporter (also written as node_exporter) is a prometheus exporter for hardware and OS metrics on *NIX kernels. It allows operators to have introspection into the relative health of the fleet of machines and to build dashboards and automated actions.
While prometheus does provide pre-built binaries for a number of kernels and architectures, they are only distributed as tarballs.
In the spirit of consistency, we decided to script the installation procedure for node-exporter so that we can have a repeatable setup across all of our machines.
Background For a number of reasons, my "internal" network is physically spread over two locations.
One physical location has a pfSense-based x86 router/firewall combo, which was initially setup years ago. The more-powerful router is a good fit at this location as it is where we’ve located most of the development infrastructure. We make use of VLANs for the different zones, Snort for IDS/IPS, Squid for HTTP caching (on some VLANs), and a few other services.
Kubernetes seems to have taken the IT infrastructure world by storm, with every company either providing their own distribution of kubernetes. However, if you’ve tried to provision and control your own kubeadm-managed distribution, you probably discovered that you almost need a PhD in kube-ology to make sense of the various options, settings, parameters, and configuration that are available and how they affect each other.
Instead of trying to make heads or tails of kubeadm, let’s look at k3s.
Ubiquiti’s UniFi gear is managed through a web interface called the UniFi Controller. Because the controller is distributed both as a free download and as an hardware appliance—the latter not free—users can decide where to run the software.
Here we’ll show you how to install and configure the UniFi Controller onto your Raspberry Pi. Raspberry Pis are small and power-efficient; they pack more than enough punch to run the application (even the gen 1 Model B) and control more than a few devices.
