Post

Mom Told Me To Organize My Gear So I Built This

Mom Told Me To Organize My Gear So I Built This

IntroductionWhen a family member vacated a spare bedroom, the opportunity arose to transform that space into a compact yet powerful self‑hosted environment. The initial impulse was simple: organize the growing collection of servers, networking gear, and storage devices. What began as a request from a parent quickly evolved into a full‑blown DIY rack project that now sits at the heart of a modern homelab.

For DevOps engineers and seasoned sysadmins, the challenge of consolidating disparate hardware into a tidy, manageable footprint is more than a cosmetic concern. It directly impacts automation pipelines, service reliability, and the ability to scale infrastructure on demand. This guide unpacks the entire workflow — from selecting the right rack dimensions and mounting hardware, to configuring Docker containers that run the actual workloads, and finally to hardening the setup for production‑grade resilience. Readers will walk away with a clear roadmap that covers:

  • The underlying concepts of rack‑based homelab design and why a custom solution often trumps off‑the‑shelf alternatives.
  • A step‑by‑step installation of Docker Engine, illustrated with placeholders that respect Jekyll templating constraints ($CONTAINER_ID, $CONTAINER_STATUS, etc.).
  • Practical configuration patterns for networking, storage, and security that align with industry best practices.
  • Real‑world troubleshooting tactics and performance tuning tips that keep the rack humming under load.

By the end of this comprehensive article, you’ll have a reproducible blueprint for turning a cluttered spare room into a disciplined, automated infrastructure hub — exactly the kind of project that earns a nod of approval from even the most demanding “mom”.


Understanding the Topic

What is a DIY Rack in a Homelab Context?

A DIY rack is a self‑constructed mounting framework that houses servers, network switches, power distribution units (PDUs), and storage arrays within a defined footprint. Unlike commercial 19‑inch or 10‑inch rack enclosures, a homemade rack can be tailored to exact dimensions, budget constraints, and aesthetic preferences.

Key characteristics:

ComponentTypical SpecificationWhy It Matters
Frame material1.5 mm steel or aluminumProvides structural rigidity while keeping weight manageable
Height30–45 U (units)Allows room for future expansion without crowding
Depth450–600 mmAccommodates most blade servers and networking gear
CoolingPassive vents + optional fansPrevents overheating of densely packed hardware
Power distribution2‑kW PDU with metered outletsEnables precise power monitoring and load balancing

The rise of open‑source virtualization platforms, notably Docker, has turned the rack into a living laboratory for infrastructure automation. Containers can be spun up, torn down, and redeployed with a single command, making the rack a testbed for CI/CD pipelines, monitoring stacks, and edge‑computing experiments. ## Historical Evolution

The concept of rack‑mountable equipment dates back to the early 20th century telephone exchanges, where standardized “racks” housed switchboards. In the 1990s, data centers adopted 19‑inch racks to house blade servers, and the same standard filtered down to small‑scale environments. However, the high cost of commercial enclosures and the lack of modular accessories forced many enthusiasts to fabricate their own solutions using sheet metal, aluminum extrusions, and repurposed furniture.

With the advent of virtualization (VMware ESXi, KVM, Xen) and later containerization (Docker, Podman), the emphasis shifted from merely housing physical machines to managing virtual workloads efficiently. Today, a modern homelab rack often doubles as a devops playground, where Infrastructure‑as‑Code (IaC) scripts, monitoring agents, and logging pipelines are orchestrated alongside the underlying hardware.

Core Features and Capabilities

  1. Modular Mounting System – Adjustable rails and shelves let you accommodate devices of varying depths and heights.
  2. Cable Management Channels – Integrated trays and Velcro‑compatible ties keep power, network, and fiber optics tidy.
  3. Power Redundancy – Dual PDUs or UPS units provide failover capability for critical services.
  4. Thermal Control – Strategically placed fans or liquid cooling loops maintain safe operating temperatures.
  5. Scalability – Open architecture permits adding extra shelves or expanding the frame vertically.

These attributes make the DIY rack a cornerstone for self‑hosted environments that demand both physical organization and programmatic control.

Pros and Cons

AdvantagesDisadvantages
Cost‑effective – can be built for under €100 in materialsRequires mechanical skill and tools (drill, saw, etc.)
Tailored to exact dimensions and aesthetic preferencesTime investment for design and assembly
Full control over power and cooling configurationsPotential for inadequate structural support if not engineered properly
Seamless integration with container orchestration platformsLimited warranty or professional support

Understanding these trade‑offs helps you decide whether a DIY approach aligns with your operational goals.

Real‑World Use Cases

  • CI/CD Sandbox – Deploy a GitLab Runner container that builds and tests code against multiple language versions.
  • Edge Computing Node – Run a K3s cluster on a rack‑mounted NUC to process IoT sensor data locally.
  • Home Media Server – Host Plex, Jellyfin, and Nextcloud containers behind a reverse proxy for personal media consumption.
  • Network Lab – Provide a dedicated environment for BGP routing experiments using FRR containers.

Each scenario leverages the rack’s physical organization to simplify troubleshooting, monitoring, and scaling. —

Prerequisites

Hardware Requirements

ItemMinimum SpecificationRecommended Model
Frame30 U steel rack with 450 mm depthDIY steel angle‑iron with welded corners
Power2 kW PDU with IEC‑C13 outletsAPC AP7901 or homemade relay‑based PDU
Cooling2× 120 mm fans or passive ventingNoctua NF‑A12 PWM fans
Storage2× 2.5″ SSD (OS) + optional HDD arraySamsung 970 EVO Plus (OS)
NetworkingGigabit switch (24‑port)Netgear GS108Ev3
Servers2× Intel NUC or equivalentIntel NUC8i7BEH

All components can be sourced from local electronics stores, online marketplaces, or repurposed from decommissioned office equipment.

Software Requirements

ComponentVersionPurpose
Operating SystemUbuntu 22.04 LTSStable base with long‑term support
Docker Engine24.0.xContainer runtime for workloads
Docker Compose2.20.xMulti‑container orchestration
Prometheus2.51.xMetrics collection
Grafana10.2.xVisualization of metrics
Fail2Ban1.9.xIntrusion prevention for SSH

The OS must be installed on the primary SSD, leaving ample space for container images and log files.

Network and Security Considerations

  • Assign a static IP address to the rack’s management interface (e.g., 192.168.1.10/24).
  • Configure firewall rules to allow only SSH (port 22) and HTTPS (port 443) from trusted LAN segments.
  • Enable key‑based authentication for all remote access.
  • Harden Docker daemon by setting userns-remap and disabling experimental features unless required.

User Permissions

  • Create a dedicated docker group and add the primary admin user to it.
  • Use sudo only for system‑level tasks; day‑to‑day container management should be performed as a non‑root user.

Pre‑Installation Checklist

  1. Verify that the rack is level and securely anchored to the floor.
  2. Install the operating system and apply all pending security updates.
  3. Confirm that the network switch ports are functional and that VLAN tagging works if needed.
  4. Test the PDU outlets with a multimeter to ensure proper voltage and amperage.
  5. Run a basic Docker sanity check (docker run hello-world).

Installation & Setup

1. Installing Ubuntu Server

1
2
3
4
5
6
7
8
9
10
11
# Update package index
sudo apt-get update -y

# Install base system (replace with your preferred installation method)
sudo debootstrap --arch=amd64 focal /mnt/ubuntu http://archive.ubuntu.com/ubuntu/
sudo mount /dev/sda1 /mnt/ubuntu/boot
sudo chroot /mnt/ubuntu /bin/bash <<'EOF'
apt-get install -y linux-image-generic linux-headers-generic
grub-install /dev/sda
update-grubreboot
EOF

After reboot, configure a static IP via /etc/netplan/01-netcfg.yaml and apply with sudo netplan apply. ## 2. Installing Docker Engine ```bash

Remove any older Docker packagessudo apt-get remove -y docker docker-engine docker.io containerd runc

Install prerequisites

sudo apt-get update -y sudo apt-get install -y ca-certificates curl gnupg lsb-release

Add Docker’s official GPG key

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Set up the stable repository

echo
“deb [arch=$(dpkg –print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg]
https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable” |
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Update the package databasesudo apt-get update -y

Install Docker Engine

sudo apt-get install -y docker-ce docker-ce-cli containerd.io

Verify installation

docker version

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## 3. Configuring Docker Daemon  

Create `/etc/docker/daemon.json` with the following content:  

```json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "userns-remap": "default"
}

Restart the daemon:

1
2
sudo systemctl enable docker
sudo systemctl restart docker

4. Adding a Non‑Root User to the Docker Group

```bashsudo usermod -aG docker $USER newgrp docker

1
2
3
4
5
6
7
8
9
10
11
Verify that you can run Docker without `sudo`:  ```bash
docker run --rm hello-world```  

## 5. Installing Docker Compose  

```bash
sudo curl -L "https://github.com/docker/compose/releases/download/v2.20.0/docker-compose-$(uname -s)-$(uname -m)" \
  -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

6. Verifying Container Operations

Run a test container to illustrate placeholder usage:

1
2
3
docker run -d --name $CONTAINER_NAMES --restart unless-stopped \
  -p $CONTAINER_PORTS:80 \
  $CONTAINER_IMAGE

Check the container status:

1
docker ps --filter "name=$CONTAINER_NAMES" --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"

Inspect logs for troubleshooting:

1
docker logs $CONTAINER_ID

Configuration & Optimization

1. Network Configuration

Create a dedicated bridge network for internal services:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# docker-compose.ymlversion: "3.8"
services:
  web:
    image: nginx:alpine    ports:
      - "8080:80"
    networks:
      - internal
    restart: unless-stopped

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_PASSWORD: example
    networks:
      - internal
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stoppednetworks:
  internal:
    driver: bridge
volumes:
  db_data:

Apply with:

1
docker-compose up -d

2. Security Hardening

  • Enable SELinux or AppArmor profiles for Docker.
  • Set no-new-privileges:true for privileged containers.
  • Use Docker Content Trust (DCT) to verify image signatures.

Example AppArmor profile snippet (/etc/apparmor.d/docker):

#include <tunables/global>
profile docker {
  #include <abstractions/base>
  #include
This post is licensed under CC BY 4.0 by the author.