My 3 Update Of Orange Rack

My 3 Update Of Orange Rack

INTRODUCTION

If you have been running a self‑hosted homelab for any length of time, you know that the moment you add a new piece of hardware or a fresh rack‑mount unit, the entire network topology shifts. The “Orange Rack” – a nickname many of us give to a bright‑colored, high‑density server rack that houses the core of our home labs – is no exception. When you decide to perform a third major update to that rack, you are essentially re‑architecting the infrastructure that powers everything from CI/CD pipelines to personal cloud services.

This guide is written for experienced sysadmins and DevOps engineers who already have a working homelab but are looking to modernize their rack‑scale setup. We will walk through the entire update cycle, from planning and prerequisites through installation, configuration, optimization, and finally troubleshooting. By the end of this article you will have a clear roadmap for executing a safe, repeatable, and well‑documented upgrade of your Orange Rack, while keeping performance, security, and observability front‑and‑center.

Key topics covered include:

• The rationale behind a staged update of a network‑centric rack
• How to assess current hardware, software, and service dependencies
• Step‑by‑step installation of updated networking services and containerized workloads * Configuration hardening and performance tuning for a 2 Gbps fiber edge
• Monitoring, backup, and recovery strategies that keep your homelab resilient

Whether you are pulling retired enterprise gear from the trash or integrating the latest MikroTik RB5009UPr+S+IN router, the principles outlined here will help you execute a smooth “My 3 Update Of Orange Rack” with minimal downtime and maximum reliability.

UNDERSTANDING THE TOPIC

What is an “Orange Rack” Update? In the context of modern homelabs, the term “Orange Rack” typically refers to a dedicated, color‑coded enclosure that houses the primary networking and compute nodes. It often includes:

• A high‑performance edge router (e.g., MikroTik RB5009UPr+S+IN) that terminates the ISP fiber line
• A set of homogeneous server blades or chassis that run Docker containers for services such as GitLab, Nextcloud, and Home Assistant
• Power distribution units (PDUs) and environmental sensors that monitor temperature, humidity, and power draw

An “Update” in this scenario means upgrading the underlying firmware, swapping out legacy hardware with newer equivalents, or migrating services to newer container images. The third update (“My 3 Update”) usually represents a major milestone: moving from a single‑router, single‑node architecture to a multi‑node, high‑availability design.

Historical Context

Early homelab builds often relied on consumer‑grade routers and a single tower server. As the community embraced open‑source infrastructure tools, enthusiasts began stacking rack‑mount hardware, adding 10 GbE switches, and deploying Kubernetes‑lite clusters. The “Orange Rack” emerged as a visual cue for a purpose‑built enclosure that could accommodate these expansions while keeping cabling tidy.

Over the past five years, three distinct update cycles have been documented:

1. Initial Deployment – Setting up the rack, installing the edge router, and provisioning basic services.
2. Scaling Phase – Adding more compute nodes, introducing Docker Swarm or Nomad, and integrating monitoring stacks.
3. Consolidation & Hardening – Migrating legacy VMs to containers, applying security patches, and optimizing power consumption.

Your current project aligns with the third phase, where the focus shifts from pure expansion to operational excellence. ### Core Features of the Update

• Zero‑downtime service migration – Using rolling updates and health checks to move workloads without interrupting user traffic.
• Power‑aware design – Leveraging solar‑generated electricity to keep idle power draw under 350 W, as demonstrated in the original Reddit post.
• Container‑native networking – Deploying an overlay network that respects the existing VLAN structure while providing isolated service discovery.

Pros and Cons | Pros | Cons |

|——|——| | Improved scalability through modular node addition | Increased complexity in network segmentation | | Better resource utilization via container orchestration | Higher learning curve for advanced Docker commands | | Lower idle power consumption with solar integration | Potential for firmware incompatibilities between router and switches | | Centralized configuration management with GitOps practices | Need for additional monitoring instrumentation |

Use Cases

• High‑throughput edge routing – Supporting 2 Gbps fiber connections for remote work, gaming, and media streaming.
• Self‑hosted CI/CD pipelines – Running GitLab Runner containers that can scale on demand. * Network‑level services – Deploying DHCP, DNS, and VPN services inside isolated containers for easier upgrades.

Comparison to Alternatives

Traditional approaches would involve adding a second physical router and manually re‑cabling downstream switches. The container‑centric update described here eliminates many of those manual steps, reduces human error, and provides a single source of truth for service definitions. Competing solutions such as full‑blown Kubernetes may be overkill for a homelab, whereas a lightweight Docker Swarm mode offers sufficient orchestration without the overhead of a control‑plane cluster.

Current State and Future Trends

The industry is moving toward “network‑as‑code” where routers and switches are configured via declarative JSON or YAML files stored in version‑controlled repositories. The upcoming trend for homelabs is the integration of AI‑driven telemetry that can predict power spikes and automatically throttle non‑critical containers. By adopting these practices now, your Orange Rack will be positioned to take advantage of future tooling without a complete redesign.

PREREQUISITES

Hardware Requirements

• Edge Router – MikroTik RB5009UPr+S+IN with at least two Ethernet ports for WAN and LAN, supporting PoE output for downstream devices.
• Compute Nodes – Minimum of three 2U servers with 32 GB RAM, 8‑core CPUs, and 2 TB NVMe storage each, capable of running Docker Engine 24.x.
• Power Infrastructure – A PDU that can monitor per‑outlet consumption, paired with a solar inverter that can supply at least 500 W continuous power.
• Networking Gear – A 10 GbE switch with VLAN tagging support, or a dedicated VLAN‑aware switch for internal traffic segregation.

Software Requirements

Component	Minimum Version	Reason
Docker Engine	24.0	Provides the latest security patches and experimental features like rootless mode.
Docker Compose	2.20	Enables multi‑service orchestration with a single YAML file.
Prometheus	2.50	For metrics collection across the rack.
Grafana	10.2	Visualization of collected metrics.
Ansible	2.15	For idempotent configuration management of routers and servers.
OpenSSH	9.2	Secure remote administration.

Network and Security Considerations

• All management interfaces (router SSH, Docker API) must be restricted to a dedicated management VLAN (e.g., VLAN 100).
• Use SSH key‑based authentication exclusively; disable password logins.
• Enable firewall rules that only allow inbound traffic to essential ports (e.g., 22 for SSH, 80/443 for web services).

User Permissions

• Create a dedicated system user homelab with sudo privileges for Docker commands.
• Ensure that the user belongs to the docker group to avoid sudo usage in scripts.

Pre‑Installation Checklist

1. Verify firmware version on the MikroTik router (minimum 7.14).
2. Confirm that all compute nodes report healthy health‑checks via IPMI.
3. Validate that the solar inverter’s output matches the rack’s idle power draw (≤ 350 W).
4. Back up current Docker images and configuration files to an off‑site location.
5. Document the current VLAN assignments and IP address plan.

INSTALLATION & SETUP

Step 1 – Upgrade Router Firmware

ssh admin@192.168.88.1 "system package update check-for-updates"
ssh admin@192.168.88.1 "system package update download-install 7.14"
ssh admin@192.168.88.1 "system reboot"

The above commands pull the latest stable MikroTik firmware and reboot the device. Verify the new version with system print.

Step 2 – Provision Compute Nodes

Install Docker Engine on each node using the official convenience script:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker homelab
newgrp docker

Step 3 – Deploy Overlay Network

Create a Docker network that maps to the VLAN used for internal services:

docker network create \
  --driver bridge \
  --subnet 10.10.10.0/24 \
  --gateway 10.10.10.1 \
  --opt com.docker.network.enable_ipv6=false \
  orange_overlay
```  ### Step 4 – Install Monitoring Stack  ```bash
git clone https://github.com/prometheus-community/helm-charts.gitcd helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false

(External link: https://github.com/prometheus-community/helm-charts)

Step 5 – Configure Docker Compose for Core Services

Create a docker-compose.yml file with placeholders for container identifiers:

version: "3.9"

services:
  gitlab:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES
    restart: unless-stopped
    environment:
      - GITLAB_OMNIBUS_CONFIG=...
    ports:
      - "80:80"
      - "443:443"
    networks:
      - orange_overlay    volumes:
      - gitlab_data:/var/lib/gitlab
      - gitlab_config:/etc/gitlab

  nextcloud:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES
    restart: unless-stopped
    ports:
      - "8080:80"
    networks:
      - orange_overlay
    volumes:
      - nextcloud_data:/var/www/html

networks:
  orange_overlay:
    external: true

volumes:
  gitlab_data:
  gitlab_config:
  nextcloud_data:

Replace $CONTAINER_IMAGE and $CONTAINER_NAMES with the appropriate values before running docker compose up -d.

Step 6 – Verify Service Health

docker ps --filter "name=$CONTAINER_NAMES" --format "table $CONTAINER_ID $CONTAINER_STATUS $CONTAINER_IMAGE $CONTAINER_PORTS"

The output should show each container in Up state with the expected ports mapped.

Step 7 – Enable Automatic Backups

Schedule a nightly backup of Docker volumes using cron:

```bash0 2 * * * docker run –rm
-v /var/run/docker.sock:/var/run/docker.sock \

```