Gerwim's blog

Home network

2020-10-14 home

People sometimes ask me what my personal network is like, so here I will give some insight.

Global overview

network diagram

Home

  • pfSense: here’s where it all starts. It handles my inbound and outbound traffic.
  • Raspberry Pi: running Domoticz to manage my lights, read electricity usage
  • ESXi1
    • Adguard: network wide tracking and ad blocker
    • App01: Unifi controller, Confluence, Bamboo, TeamCity
    • GitLab: self hosted git repositories (and much more)
    • mx1: running email filter appliance
    • DC01: domain controller
    • Exchange 2019: Microsoft Exchange
    • GitLab Runner: build agent
  • ESXi2
    • DC02: domain controller
    • dockerhost1: running some docker containers
    • Icinga: my monitoring system (still using Icinga 1.14)
    • Paperless: digitize paper documents
    • Rancher: Rancher 2 host to manage my Kubernetes cluster
    • TimeCapsule: MacOS backup target (using avahi and netatalk)

Plans

pfSense, used to be a master / slave setup but due to my ISP not supporting this in bridge mode (Ziggo) I was forced to remove the redundancy. However I switched ISP recently, so pfSense will be virtualized again to allow a master / slave setup.

Domoticz will be migrated to this box (also as a VM) and use USB passthrough for the P1 cable to read my electricity usage.

Hetzner

Hetzner, an awesome low cost provider. Hetzner is running my personal “cloud”. Yes, my personal cloud. Where’s it’s always sunny and never rains 😅.

  • node01: Kubernetes master and worker
  • node02: Kubernetes master and worker
  • node03: Kubernetes master and worker
  • postal: Outbound mail gateway

All three Kubernetes nodes are behind a Hetzner load balancer.

Storage

Most of the time when I’m trying to run a persistent service I have trouble with the storage. I don’t want to tie a service to a specific host. I want to be able to take one host offline for maintenance and keep everything running. I guess most of us do ;-). Hetzner has a storage driver available for Kubernetes, but it has a minimum of 10GB storage (which is 0,50 EUR a month). Well I’m not running a single persistent application. I’m running a dozen. And they don’t need 10 GB of storage. So saving a little bit of money there by doing it ourselves is great. Plus, there’s no backups 😱.

Meet Longhorn. Longhorn is a distributed block storage system, using only containers made for Kubernetes. longhorn

With Longhorn, you can schedule backups to any S3 compatible target (I’m backing up to Backblaze B2), it also creates snapshots of your volume which means a quick rollback to a previous state is possible. pvc view As you can see in the screenshot above, there are three replicas (on every host one), it’s currently mounted on node01 and has a size of 1.32 GiB (this size is bigger than the allotted 1 GiB because of snapshots). The great thing about this system is that everything is happening on block level. It doesn’t need to know about the consuming application. Of course, if you’re running databases you’d rather have a backup in a clean and consistent state and you’d want to use a complimentary backup strategy.

Service deployments

As I’m using GitLab, I’m also using a GitLab runner to perform my builds. This blog (and most of my other services) are built on each commit (and sometimes deployed). This blog is build and deployed on each commit (see the used yaml file below).

What it does in short:

  • only builds the develop branch
  • creates an nginx image (with the commit sha as tag (to create unique images), to allow rollbacks - e.g. reg.gerwim.nl/gerwim/gerwim.nl:0dbae38f)
  • updates the gerwimnl deployment with this new image (using the rancher-cli-k8s Docker image)

.gitlab-ci.yml

stages:
  - develop
  - deploy

services:
  - docker:dind

variables:
  GIT_SUBMODULE_STRATEGY: recursive
 
develop:
  stage: develop
  image: docker:latest
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY

    - docker build -t $CI_REGISTRY_IMAGE:develop -f Dockerfile src
    - docker tag $CI_REGISTRY_IMAGE:develop $CI_REGISTRY_IMAGE:latest
    - docker tag $CI_REGISTRY_IMAGE:develop $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

    - docker push $CI_REGISTRY_IMAGE:latest
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - develop
  tags:
    - docker-unrestricted

deploy:
  stage: deploy
  image: gerwim/rancher-cli-k8s:latest
  script:
    - rancher login $RANCHER2_SERVER_URL --token $RANCHER2_BEARER_TOKEN --context $KUBE_CONTEXT
    - rancher kubectl --namespace=gerwim-website set image deployment/gerwimnl gerwimnl=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA --record
  only:
    - develop

Dockerfile

# This Dockerfile is used as: docker build -t image -f Dockerfile src
FROM klakegg/hugo:0.76.3-onbuild AS builder

FROM nginx:1.19-alpine
COPY --from=builder /target /usr/share/nginx/html
© 2024 Gerwim Feiken