nunogrl.com - infrastructure

Homelab Network Overview

2024-08-01T00:00:00+01:00

My homelab network is designed to provide a secure, efficient, and self-hosted environment for various automation, development, and personal infrastructure needs. This setup prioritizes network segmentation, security, and performance optimization, while being flexible enough to scale or adapt for experimentation.

Problem & Solution

Problem: I needed a reliable and secure environment for automation, CI/CD testing, Git hosting, and local infrastructure— without relying on cloud platforms or exposing services to the internet.

Additionally, the solution had to run on low-powered, repurposed hardware with minimal overhead and support remote access, internal DNS resolution, and segmented security domains.

Solution: I architected a network centered around an OpenWRT-based router with VLAN segmentation, isolated zones for each function, and layered services:

Tailscale provides secure access to internal services, even when offsite.
Cloudflare Tunnel allows for secure access to internal services from the internet.
AdGuard Home filters DNS-based ads and trackers at the router level.
TinyDNS + BIND handle authoritative DNS within the homelab.
Traefik serves as the reverse proxy using a wildcard cert via DNS verification.
Prometheus + Grafana provide observability for all infrastructure nodes.
A D-Link 3782 router is used as a wireless bridge to isolate the IoT network.

The OpenWRT router also provides wireless access to mobile and personal devices, which are segmented into their own VLAN. These include laptops, phones, and tablets used for managing or testing infrastructure services.

For mobile devices, Syncthing is used to selectively back up content to the NAS. While backups are not fully automated, this gives more control over what is stored. I am considering adding a backup option to Dropbox for external redundancy.

The entire infrastructure is provisioned via Ansible playbooks, which manage deployment and configuration across the environment. These playbooks live on an internal Git server and may be shared publicly in the future.

The system emphasizes modularity, resilience, and observability, ensuring that each component is isolated but observable.

Full Network Topology (Combined)

flowchart TD %% ingress egress Internet --> Router Router -->|VPN: Site2Site| VPNCloudflare Router -->|VPN: host| VPNTailscale %% DNS Router -.-> AdGuard AdGuard -.-> BIND BIND -.-> TinyDNS %% Traefik --> Router %% Traefik --> IoT_Bridge %% Prometheus --> NAS %% Prometheus --> Server1 %% Prometheus --> CIService %% Prometheus --> Router %% Grafana --> Prometheus Router ==>|VLAN: NAS| NAS Router ==>|VLAN: Dev| Server1 Router ==>|VLAN: CI| Zeus Router ==>|VLAN: IoT| IoT_Bridge Router ==>|VLAN: WiFi| Wireless_Clients IoT_Bridge -->|Wireless| IoT_Devices %%subgraph rproxy [reverse proxy] %% Traefik --> GitServer %% Traefik --> CIService %% Traefik --> Grafana %% Traefik --> Syncthing %% Traefik --> Portainer %% Traefik --> Prometheus %% Traefik --> NASUI %% Traefik --> binrepo %% end %% description VPNCloudflare((VPN fa:fa-lock cloudflared tunnel)) VPNTailscale((VPN fa:fa-lock tailscale server )) Router{{Router}} IoT_Bridge{{IoT Bridge}} Internet(((Internet fa:fa-cloud))) %% NASUI([homepage fab:fa-docker]) %% GitServer([git fab:fa-docker]) %% CIService([CIService fab:fa-docker]) %% Grafana([grafana fab:fa-docker]) %% Portainer([Portainer fab:fa-docker]) %% Traefik([traefik fab:fa-docker]) %% Syncthing([Syncthing fab:fa-docker]) %% Prometheus([Prometheus fab:fa-docker]) %% binrepo([Binary Repo fab:fa-docker]) Server1[Raspberry Pi] %% styles classDef default fill:#f9f,stroke:#333,stroke-width:1px; classDef net fill:#fff; classDef hardware fill:#f96; classDef dns fill:#AFF; classDef container fill:#EF0; classDef vpn fill:#EF0; classDef network fill:#CCCCCC; Internet:::net VPNCloudflare:::vpn VPNTailscale:::vpn AdGuard:::dns BIND:::dns TinyDNS:::dns Router:::network IoT_Bridge:::network NAS:::hardware Server1:::hardware Zeus:::hardware Wireless_Clients:::hardware IoT_Devices:::hardware %% NASUI:::container %% GitServer:::container %% CIService:::container %% binrepo:::container %% Grafana:::container %% Portainer:::container %% Traefik:::container %% Syncthing:::container %% Prometheus:::container

This shows how DNS resolution, secure access, proxy routing, and monitoring interconnect.

Layered Views (Progressive Breakdown)

DNS Resolution Flow

flowchart TD Client --> AdGuard AdGuard --> BIND BIND -.-> I BIND -.-> L BIND --> TinyDNS BIND -.-> LXC L((Local network)) I((Internet)) LXC((LXC_Containers))

Traefik Reverse Proxy Flow

flowchart TD Internet -->|DNS Challenge| Traefik Traefik --> GitServer Traefik --> Grafana Traefik --> CIService Traefik --> binRepo Traefik --> Syncthing Traefik --> Portainer Traefik --> RouterUI Traefik --> NASUI Traefik --> IoT_Bridge

Prometheus Monitoring Flow

flowchart TD Prometheus --> NAS Prometheus --> Server1 Prometheus --> CIService Prometheus --> Router Prometheus --> IoT_Bridge Grafana --> Prometheus

Each layer can be inspected individually or in combination via Grafana dashboards and log collectors. This layered view mirrors how the infrastructure is designed, monitored, and interacted with.

Change Sets with Sceptre: Controlled AWS Changes in ITIL Environments

2024-03-21T00:00:00+00:00

🚀 Problem & Solution

📌 Context / Backstory

We needed to add a stop-instance Lambda to our existing AWS stack — but in a production environment governed by ITIL change control. That meant:

No untracked infrastructure changes
No direct "deploy and hope" workflows
Every change needed visibility, approval, and a rollback path

⚠️ The Problem

CloudFormation makes changes declarative — but deployments are immediate by default. In an ITIL environment, we needed:

A way to preview the change
A record of the proposed change
A controlled execution, ideally during a change window

💡 The Solution

We used Sceptre's built-in support for CloudFormation Change Sets to decouple proposing changes from executing them. This gave us:

Change Set visibility before applying
A file-based workflow for review and audit
Controlled deployments aligned with ITIL practices

👥 Who This Helps

Engineers working in regulated environments (finance, enterprise IT, healthcare)
DevOps teams needing pre-deployment approvals
Anyone trying to bridge automation with change control

⚙️ Technical Implementation

Let's visualize the change management workflow:

1️⃣ Add a Stop-Lambda to Your CloudFormation Template

For example, we extended our template with:

StopInstanceLambda:
  Type: AWS::Lambda::Function
  Properties:
    Handler: index.handler
    Role: !GetAtt LambdaExecutionRole.Arn
    Runtime: python3.9
    Timeout: 30
    Code:
      ZipFile: |
        import boto3
        import os
        def handler(event, context):
            ec2 = boto3.client('ec2')
            ec2.stop_instances(InstanceIds=[os.environ['INSTANCE_ID']])
    Environment:
      Variables:
        INSTANCE_ID: !Ref InstanceId

We committed this change to Git but did not deploy yet.

2️⃣ Preview with Sceptre Change Set

In your Sceptre stack config (stop-tests.yaml):

template_path: start-stop-template.yaml
stack_name: start-tests-scheduler
parameters:
  InstanceId: i-0123456789abcdef0

Then run:

sceptre create-change-set dev/stop-tests.yaml

This creates a named Change Set in CloudFormation.

3️⃣ Review the Change Set

You can now inspect the proposed changes via:

sceptre describe-change-set dev/stop-tests.yaml

This outputs a diff-like summary of added/removed/modified resources.

4️⃣ Execute the Change Set in a Controlled Window

Once approved:

sceptre execute-change-set dev/stop-tests.yaml

This applies only what was reviewed and approved, nothing more.

🛠️ Troubleshooting & Debugging

Change Sets fail if resources are renamed instead of replaced — use Retain policies or snapshots carefully.
If nothing appears in the Change Set, verify your stack is actually different from the current state.
Include --no-execute-changeset in manual aws cloudformation calls if testing outside Sceptre.

🔁 ITIL Alignment & Best Practices

Why this works for change management:

✅ Pre-approved changes: Reviewable before execution
✅ Audit trail: Change Set IDs + Git commits form a traceable chain
✅ Rollback-ready: No impact until applied; easy to cancel
✅ Automatable: Integrates with GitOps, CI/CD, and approval gates

Compare to a traditional ITIL CAB process: - Sceptre's Change Set becomes the RFC payload - Execution timing maps to change windows - Logs & ChangeSet name tie into CMDB or ticketing systems

✅ Conclusion & Takeaways

By using Sceptre's Change Sets, we introduced governed change control without sacrificing automation. It's a clean way to blend DevOps practices with ITIL compliance — reducing risk while maintaining velocity.

💬 Comments & Next Steps

Have you implemented similar change control processes in your AWS infrastructure? Share your experience or ask questions below!