homelab/build/config/ansible/roles/k3s_postgres/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

71 lines
3.5 KiB
YAML

---
# Ansible-side knobs for roles/k3s_postgres — CloudNativePG (CNPG), the
# Postgres operator for the homelab-utils cluster's shared database.
# Installed via k3s's own bundled helm-controller, same mechanism as
# roles/k3s_metallb and roles/k3s_monitoring (see tasks/main.yml) — no helm
# binary or extra Ansible collection needed on the controller.
#
# Chosen over Bitnami's postgresql-ha (repmgr+pgpool, more moving parts per
# pod, and Bitnami's free chart/image catalog was restructured into a
# "legacy" repo in 2025 — a risky long-term dependency) and the Zalando
# operator (mature but Patroni-based, heavier, and its own config
# conventions fit less naturally into this repo's lean HelmChart-CR-only
# pattern). CNPG installs as one operator chart plus one plain Cluster CR —
# the same "HelmChart + plain config manifest" shape already used for
# MetalLB (chart + IPAddressPool).
#
# The app-portable half of this config (instance count, storage size/class)
# lives with the app it belongs to instead: see
# src/shared/postgres/ansible/kubernetes/vars.yml, loaded into `pg_config`
# by tasks/main.yml — same common/vars.yml + platform-vars.yml split
# compose_stack and lxc_app use for every other app.
k3s_postgres_operator_namespace: cnpg-system
k3s_postgres_chart_repo: https://cloudnative-pg.github.io/charts
# Pinned, same reasoning as k3s_monitoring_chart_version/k3s_metallb_chart_version
# — a rebuild months from now should reproduce today's operator, not
# whatever's newest at the time. Bump deliberately; check the current
# release first at https://github.com/cloudnative-pg/charts/releases.
k3s_postgres_chart_version: "0.29.0"
# Where the actual Postgres Cluster (not the operator) lives.
k3s_postgres_namespace: shared-postgres
# Postgres major/minor pinned via the operand image, independent of the
# chart/operator version above. This is a separate physical instance from
# the Docker-based shared/postgres (pinned to 13 there — see
# src/shared/postgres/common/vars.yml), so there's no need to match; pin to
# a current stable major instead. Multi-arch (amd64/arm64) upstream, same
# as every other image this cluster runs.
k3s_postgres_image: ghcr.io/cloudnative-pg/postgresql:18.4
# Same Vault path the Unraid/Proxmox shared-postgres instances already use
# (see docs/vault-secrets.md) — a separate physical instance, but one
# superuser identity for the "shared postgres" concept everywhere it runs.
k3s_postgres_vault_path: homelab/shared/postgres
# The LAN address the primary is published on, via the LoadBalancer Service
# declared in templates/postgres-cluster.yaml.j2. Must be inside
# k3s_metallb_address_range — MetalLB only assigns from its own pools, and a
# request for anything outside them leaves the Service pending forever rather
# than failing loudly.
#
# Empty here on purpose, same reasoning as k3s_metallb_address_range's own
# default: the address is a property of the LAN, not of this role, so it's set
# in inventory/group_vars/k3s_cluster.yml next to the pool it has to fall
# inside. Unlike the pool, leaving it empty is survivable — the Service is
# still created and MetalLB assigns the next free address; you just don't know
# which one until you look, which is fine for in-cluster clients and no good
# for anything that has to write the address down.
k3s_postgres_loadbalancer_ip: ""
# Resource requests/limits per instance — sized for a Raspberry Pi 4, not a
# datacenter node, same reasoning as k3s_monitoring_values.
k3s_postgres_resources:
requests:
cpu: 100m
memory: 256Mi
limits:
memory: 512Mi