Looking back at 2023 part 2: Embracing Docker Containers

Funny things may happen in a year, especially those you don’t expect. One thing I definitely didn’t expect was embracing Docker Containers as I was completely unfamiliar with them nor couldn’t I mention a use case for deploying them. But here at home I finally have and I may see potentially use cases for organizations as well. I consider Docker Containers extremely useful for running light-weight applications using very little resources.

One machine having very little resources I use is an HP t520 Flexible Thin Client that I equipped with 8 GB RAM and a 256 GB M.2 SATA SSD. As this model is discontinued, it’s fine for me as I don’t intend to use these for their original purpose. See https://support.hp.com/us-en/product/product-specs/hp-t520-flexible-thin-client/6875920 for more information.

I bought a bunch of these a while ago as they may be a cheap alternative to SBC’s like Raspberry Pi’s that may still be a challenge to buy. As many of these thin clients are being decommissioned, it should be really easy to find these on the used market. However, I wouldn’t spend too much money on them. Consider being fleeced if someone asks an unreasonable price for such devices. You may consider using 1L PC’s as an alternative if more resources (like CPU, RAM and storage) are required for your scenario.

During the year, one aspect I was looking into it is choosing the OS to ‘host’ the Docker Containers. My main requirement was to have it setup in such a way that it just works and I don’t get too much ‘noise’ by frequently needing to update them. I chose to install Debian 12 (Bookworm) as I know Debian uses ‘stable’ releases only. While some components of Debian 12 may be older than other Linux distros, it does what it needs to do and I don’t need bleeding edge versions of said components. I tried using Ubuntu, both as Desktop and Server, in the past. It just doesn’t work for me as it creates too much noise. I don’t consider myself a Linux expert as I shamelessly have to look up everything a follow guides, not to mention some YouTube ‘binge watching’ sessions learning something new. I like the ‘quietness’ and the ‘fire and (more or less) forget’ vibes Debian 12 is giving me. Installing Debian 12 on an HP t520 Flexible Thin Client was a flawless experience, no issues with hardware support or driver issues, great…

At time of writing, Debian 12 (Bookworm) is the latest release. I used the steps described at https://linuxiac.com/how-to-install-docker-on-debian-12-bookworm/ to install Docker. At first, I used some ‘Docker Management’ frontend tools like Portainer to install and manage Docker Containers. Eventually, as I prefer to work with Docker Compose allowing me to use the .yaml files to build and deploy my Docker Containers, I learned to appreciate using Visual Studio Code to manage my Docker Containers. I found a very useful YouTube video that I used to reproduce the steps so go watch it if you like to know more: https://www.youtube.com/watch?v=huiQd2QojXY

I use Visual Studio Code myself for writing scripts or templates either in ARM or Terraform (note to self: really need look into Azure Bicep). What I like in Visual Studio Code, is that it works great on various platforms. I use it on Windows, Linux and Mac and it works fine for this idiot of an author.

So, at time of writing I am running the following Containers at home:

– Pi-hole (pihole/pihole:latest); DNS sinkhole for blocking ads and other potentially nasty stuff

– Nut UPSD (upshift/nut-upsd); for collecting telemetry data of my UPS directly connected by USB I use to protect my network equipment for voltage fluctuations (pretty common when using solar panels) and potential outages

– Netbootxyz (ghcr.io/netbootxyz/netbootxyz); for installing Linux OS based VMs on my home lab which saves me the hassle of managing ISO

– Samba Server (gists/samba-server); for having a small SMB share when PXE has issues but also as a share for installing Windows using Microsoft Deployment Toolkit

– Corosync Qdevice (debian-qdevice:latest); Here’s the Qdevice container I mentioned in my previous post (insert link). I used the instructions mentioned at https://raymii.org/s/tutorials/Proxmox_VE_7_Corosync_QDevice_in_Docker.html but made small modifications to make it work for Proxmox VE 8 using Debian 12 (bookworm)

– Uptime Kuma (louislam/uptime-kuma); a small leightweight monitoring service that I need to use more intensively

– Home Assistant (ghcr.io/home-assistant/home-assistant:stable); yes, I started getting myself familiar with Smart Home automation. I expect to expand on this more in the future. The main feature I use it for is to collect telemetry data my DSMR Smart Meter using a USB cable directly connected to my Docker host.

Regarding monitoring my DSMR Smart Meter, I used different approaches in the past. I discarded them once I discovered I can directly integrate them in Home Assistant. These tools may be useful if Home Assistant is cannot be directly connected to a DSMR Smart Meter.

More containers may be installed later as I noticed that thin client is far from fully utilized.

Here’s a screenshot of the Sensor data of my thin client running Docker Containers:

As you can see, still lots of room to run more stuff.

This was a lot of fun. Heck, now that I have a running home lab, I may even go crazy deploying my own Kubernetes Cluster but that’s for next year…

 

Looking back at 2023 part 1: Embracing a home lab

2023 has been an interesting year getting new insights next to what I do professionally on a full-time basis. Yes, working with organizations on their cloud journey, in my case Microsoft Azure, is a lot of fun but there’s more than just the public cloud. Scenarios may exist that are not be really viable to run on public clouds. While I tried to limit the amount of having an infrastructure at home, the nerd/geek inside me woke up again wanting to run something at home. So the interest in having a home lab returned.

Some prerequisites needed were already present by means of having a home network using some decent equipment (in my humble opinion) using devices from Ubiquity.At time of writing, I use the following devices since I moved into this home in late 2020:

– Unify Dream Machine Pro

– Unifi US-16-150W switch

– 3 Unifi UAP-AC-IW access points

– 1 Unifi UAP-IW-HD access point

So, having such network equipment running a NAS, an HTPC and a work related laptop may be overkill and covers my needs quite a bit. So, why not having a home lab and start exploring multiple scenarios before deciding what to build myself?

After reading a lot of websites and extensive YouTube video sessions (man, there’s soooo much to find about the topic) I decided to go for something compact yet flexible.

The approach that really caught my attention was ‘Project TinyMiniMicro’ from Servethehome: https://www.servethehome.com/introducing-project-tinyminimicro-home-lab-revolution/

As I am not particularly interested in having a huge rack populated with 19 inch rack-mount servers (the Unifi equipment fits in my utility closet), this approach really suited me well. Nothing has changed much since the article regarding the availability of used/refurbished 1L PC’s. Plenty of them are available for a good price and they introduce lots of use cases next to home labs.

I purchased 3 HP Elitedesk 705 G4 boxes and 2 of them will be used for my home lab.The 3rd is used a emulation station for retro gaming running Batocera, but that’s outside the scope of this post.

I purchased some additional memory and SSD disks as the initial configuration was quite minimal, but the seller equipped both boxes with a 256 GB NVME SSD which I use a boot drive. The data disks chose may not be the fastest ones, but they were cheap and fit my needs.

As these boxes don’t have any KVM or Lights Management solution, I need to take them out nd put them back in if I need to do some hardware maintenance or reinstall the OS.

These are desktops so what do you expect?

After testing and installing the boxes I installed it in my utility closet. A perfect fit…

During the year, I’ve been trying out various software solutions to run on my home lab environment. With software solutions, I mean hypervisor. By lack of any interest, I ruled out Microsoft Hyper-V and VMware vSphere before investigating other solutions. I went for the KVM route using two methods of running the hypervisor:

1. Rocky Linux in conjunction with Cockpit

2. Proxmox Virtual Environment

Initially, I ran both machines as stand-alone. Eventually, I moved to Proxmox Virtual Environment running both machines in a cluster.

As I don’t have any requirements for failover, I chose to have the Virtual Machines and LXC Containers replicated and do some manual migration to the other node if maintenance is required that results into a reboot, i.e. after installing a new kernel.

This raises one issue: 2 cluster nodes insufficient for failover and cluster voting as at least 3 nodes are required and I don’t have a 3rd Proxmox machine available. Fortunately, some more YouTube sessions provided a solution using a Corosync Qdevice for voting purposes. How I managed to deploy that is part of part 2 of looking back at 2023.

Stay tuned!!!