It hurts us
  • Shell 88.8%
  • Go Template 7.3%
  • Dockerfile 3.9%
Find a file
2026-08-07 09:52:21 -05:00
.forgejo/workflows Use shared container action 2026-07-31 14:07:18 -05:00
admin Headlamp v0.43.0 2026-06-23 11:39:42 -05:00
common Gwaihir! 2026-05-14 18:28:39 -05:00
core Traefik: v3.7.9 2026-07-31 12:18:28 -05:00
fdwg duckdb-cli PV (maybe) 2026-08-07 09:52:21 -05:00
git-hooks Add kustomize git hook 2026-05-11 11:53:17 -05:00
shared-services vmalert 2026-08-07 09:51:03 -05:00
.gitignore ignore the keycloak export stuff 2026-07-24 23:51:20 +02:00
fnox.toml Argo: add mutexes and rbac for iceberg-write 2026-07-30 22:41:07 -05:00
mise.toml Add cmctl 2026-07-21 16:45:09 -05:00
README.md sqlmesh init 2026-07-17 11:54:37 -05:00
renovate.json Add renovate.json 2026-07-10 17:19:15 +00:00

Hatlas ArgoCD

This is the Kubernetes "ops" repo for Hatlas, leveraging ArgoCD. Join us in #data!

Overview / Setup

Mise

@mwinters heavily uses mise (basically direnv + homebrew), and there is a mise.toml file in the root directory. This is the easiest way to ensure that you're using the correct versions of the CLI tools.

Secrets Handling

  1. We use fnox + age to share encrypted secrets between operators. This uses your SSH key(s) as encryption keys. See the quickstart for setup, though you'll need to have an existing admin add your key first.
    • Note: you must use an SSH key which is not password protected. Yes, this sucks. Don't use your golden keys.
  2. We use the Sealed Secrets operator to deliver secrets to the cluster. Anywhere there is a secret, there is also a generate_secrets.sh or similar which reads the raw secret from fnox (or a manual override) and creates the sealed secret which is safe to commit to git.

For onboarding, someone with existing access will have to add your public key to fnox.toml and run fnox reencrypt. Then to decrypt, you can just put this in mise.local.toml:

[env]
FNOX_AGE_KEY_FILE="$HOME/.ssh/your-passwordless-private-key"

To add a new secret:

# Otherwise it will make a new one
cd wherever-fnox.toml-is

fnox set FOO
# It will prompt you for the value

Repo Layout

  • /bootstrap (kubectl apply -k):
    • argocd
  • /core: Foundational Services
  • /admin: Tools for Admins
  • /shared-services:
  • /fdwg:

Argo App-of-Apps dependencies

  1. kubectl apply -k
  2. core 1. admin 2. shared-services 3. fdwg (in default project; declares the fdwg and fdwg-bridge AppProjects)
    1. fdwg-apps (in fdwg-bridge project; constrained to produce only Application objects in the fdwg-argocd namespace)
    2. ... (child Applications in fdwg project, sourced from fdwg repo

DNS

Only @mwinters has admin on the Cloudflare account, but we are running external-dns with a Kyverno policy that allows any subdomain of hatlas.mwinters.net to be created by DNSEndpoint objects within the cluster.

Our pattern is to generally create all Ingress / IngressRoute objects at ArgoCD sync wave 10, and ensure that the DNSEndpoint objects are created in a previous wave. The sync wave should give us a 50% chance of the subdomain being created before Traefik tries to provision a cert for it, and retries will handle the other 50%.

Config you can't see here

Keycloak

  • Realm is name "hatlas"
  • Realm setting for access token timeout is 12 hours
  • We have configured Fedora Account System (FAS) as an OIDC identity provider with group mapping:
    • FAS fdwg -> fdwg-analyst
    • FAS fdwg-maintainer -> fdwg-maintainer

Onboarding new Ops

See: https://forge.fedoraproject.org/fdwg/fdwg/src/branch/main/work-areas/ops