Incubating projects are experimental or prototypal. They're being actively developed and aren't ready for production deployment. These projects may appear and disappear without warning and are not stable. There is no minimum requirement for a project to be in incubation.

Graduated projects are in-use, stable, and production ready. They met the graduation requirements and are actively maintained.

Retired projects are no longer in use or recommended. They are kept for reference. Retired projects must meet the retirement requirements

Supported Projects

All projects will fall into one of the following categories:

hardware
infrastructure
cloud
systemd
podman
docker
kubernetes

Hardware will contain projects that relate to specific machines or equipment. 3D printers, Raspberry Pis, and other IOT devices qualify as specialized hardware that needs documentation and configuration.

Infrastructure will contain projects that set up the environments for the remaining listed project types. For example, infrastructure will contain "how to set up a linux box with docker" or "how to set up a k3s cluster for kubernetes".

Cloud projects are for specific cloud providers.

Systemd projects are designed to be installed with ansible and run via systemd on a linux VM or other linux hardware.

Podman projects are either designed to be run as quadlets or as podman containers outright.

Docker projects are either docker-compose or some form of docker run command.

Kubernetes projects are helm, kustomize, kubectl, or some other kubernetes compliant deployment.

Graduation Requirements

Installation is documented
Installation configuration examples are provided
Hardening guidelines are documented
Upgrade procedures are documented
Maintenance procedures are documented
Uninstall procedures are documented
Backup and restore procedures are documented and tested

Retirement Requirements

A reason for retirement is documented
If applicable, a replacement has been identified and documented
If applicable, backup data locations are documented

Apps (TODO: Move these into their respective folders)

Gitea

Gitea provides a helm chart here. We're not going to modify much, but we are going to solidify some of the default values in case they decide to change things. This is the first chart (besides ingress-nginx) where we need to pay attention to the MetalLB annotation. This has been set in the values.yaml file.

Staging

There is a gitea-staging.yaml file with staging values. This should be installed in the gitea-staging namespace. Follow the instructions below, but replace the gitea namespace with gitea-staging. Staging is useful for testing major release upgrades, especially since Gitea tends to change how values.yaml is structured.

Install

First we need to create the gitea admin secret

kubectl create namespace gitea
kubectl create secret generic gitea-admin-secret \
    -n gitea \
    --from-literal=username='gitea-admin' \
    --from-literal=password="$(pwgen -c -s 64 | head -n 1)" \
    --from-literal=email=''

helm repo add gitea-charts https://dl.gitea.io/charts/
helm repo update
helm upgrade --install \
    gitea \
    gitea-charts/gitea \
    --values gitea/gitea-values.yaml \
    --namespace gitea \
    --create-namespace

If you need to backup your database you can run:

# Backup
kubectl exec -it -n gitea gitea-postgresql-0 -- \
    pg_dump \
    --no-owner \
    --dbname=postgresql://gitea:gitea@localhost:5432 > gitea_backup.db

# Take gitea down to zero pods
kubectl scale statefulset gitea --replicas 0

# Drop the existing database
kubectl exec -it -n gitea gitea-postgresql-0 -- psql -U gitea

\c postgres;
drop database gitea;
CREATE DATABASE gitea WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
exit

# restore from backup
kubectl exec -it -n gitea gitea-postgresql-0 -- \
    psql \
    postgresql://gitea:gitea@localhost:5432 gitea < gitea_backup.db

# Restore gitea to 1 pod
kubectl scale statefulset gitea --replicas 1

Minecraft

Minecraft is available through the custom helm chart (including a server downloader). The example below installs nimcraft. For each installation you'll want to create your own values.yaml with a new port. The server-downloader is called "minecraft_get_server" and is available on Github.

Testing

helm upgrade --install \
    testcraft \
    ./minecraft \
    --namespace minecraft \
    --create-namespace

Nimcraft

helm upgrade --install \
    nimcraft \
    ./minecraft \
    --namespace minecraft \
    --create-namespace

Courtnie

helm upgrade --install \
    courtniecraft \
    ./minecraft \
    --namespace minecraft \
    --create-namespace

Snapdrop

Snapdrop is a file sharing app that allows airdrop-like functionality over the web

helm upgrade --install \
    snapdrop \
    ./snapdrop \
    --namespace snapdrop \
    --create-namespace

Jellyfin

This assumes you have a media NFS share.

helm upgrade --install \
    jellyfin \
    ./jellyfin \
    --namespace jellyfin \
    --create-namespace

Iperf3

This creates a basic iperf3 server.

helm upgrade --install \
    iperf3 \
    ./iperf3 \
    --namespace iperf3 \
    --create-namespace

Wordpress

The bitnami wordpress chart allows enough customization to work on a custom K3S server. With some tweaks it's quite good. Use the values in bitnami/wordpress.yaml as a starting point.

helm upgrade --install \
    wordpress \
    -f bitnami/wordpress.yaml \
    --set wordpressUsername=admin \
    --set wordpressPassword=password \
    --set mariadb.auth.rootPassword=secretpassword \
    oci://registry-1.docker.io/bitnamicharts/wordpress

Grafana

https://grafana.com/docs/grafana/latest/setup-grafana/installation/kubernetes/

Grafana has a kubernetes yaml they prefer you use. See kubectl/grafana.yaml.

kubectl apply -f kubectl/grafana.yaml

Languages

Python 61%

Shell 19.6%

Dockerfile 13%

Jinja 5%

DIGITAL Command Language 1.4%

README.md

Homelab

Table of Contents

Project Lifecycle