homelab/build/config/ansible/roles/k3s_app/defaults/main.yml
Russell Seymour 1250c9cef6
Some checks are pending
deploy / deploy (push) Waiting to run
Initial checkin of code for managing homelab
2026-08-24 20:52:36 +01:00

34 lines
1.7 KiB
YAML

---
# Ansible-side knobs for roles/k3s_app — the k3s equivalent of
# compose_stack (Unraid) and lxc_app (Proxmox): the generic role that
# deploys one *application* onto the homelab-utils cluster, as opposed to
# the k3s_* roles that deploy one *cluster service*.
#
# The distinction is worth stating, because the file layout looks similar.
# roles/k3s_metallb, k3s_monitoring, k3s_postgres and k3s_cert_manager each
# hard-code a single thing the cluster itself needs, with their config in
# defaults/ and group_vars. This role hard-codes nothing: it's driven by the
# `k3s_apps:` list in inventory/group_vars/k3s_cluster.yml and reads each
# app's config out of src/<app>/, the same src/ tree Unraid and Proxmox
# already deploy from. An app that moves between platforms gets a new
# platform vars file, not a rewrite — see CLAUDE.md → "How config is
# layered".
#
# Everything reaches the cluster the same way every other k3s role does:
# rendering a file into k3s's auto-deploying manifests directory and letting
# k3s's own controllers reconcile it. No helm binary, no kubeconfig, no
# kubernetes.core collection on the controller.
# Where k3s watches for manifests to apply. Anything written here is applied
# by k3s's deploy controller, and — importantly for remove.yml — anything
# *deleted* from here has its resources torn down again, because the
# controller tracks what each file created via an Addon CR.
k3s_manifests_dir: /var/lib/rancher/k3s/server/manifests
vault_kv_mount: kv
# Which directory under src/<app>/ansible/ holds the Kubernetes deployment.
# "kubernetes" rather than "k3s": what's in there is plain Kubernetes plus
# k3s's HelmChart CR, and an app moved to a different distribution would
# keep most of it.
k3s_app_platform_dir: kubernetes