Sync the self-hosting stack
This commit is contained in:
@@ -0,0 +1,75 @@
|
||||
# The entry point for `kubectl apply -k` and for Argo CD.
|
||||
#
|
||||
# It exists so that a GitOps tool has ONE path to point at, and so that the two images are pinned in
|
||||
# ONE place instead of three. The manifests beside it are unchanged and still apply individually
|
||||
# with `kubectl apply -f` — this aggregates them, it does not replace them.
|
||||
#
|
||||
# ─── WHAT IS DELIBERATELY NOT HERE ────────────────────────────────────────────────────────────
|
||||
#
|
||||
# `01-secret.example.yaml`, and its absence is the most important line in this file.
|
||||
#
|
||||
# It is a TEMPLATE carrying placeholder values. A GitOps controller applies what it is pointed at,
|
||||
# continuously, without asking — so a Secret full of `REPLACE_ME` inside the source of truth is a
|
||||
# controller that will overwrite your real credentials with placeholders on its next reconcile, and
|
||||
# then keep putting them back every time you fix them. The api would fail to reach its database, the
|
||||
# vault key would be wrong, and nothing in the sync would look unhealthy.
|
||||
#
|
||||
# Write `jarvis-secrets` into the cluster by another route entirely: by hand, or through
|
||||
# SealedSecrets, ExternalSecrets or Vault — anything whose ciphertext is safe to commit. The
|
||||
# generated half (`jarvis-generated`) is minted in-cluster by the hook in `01-secret-job.yaml` and
|
||||
# is likewise never in git.
|
||||
#
|
||||
# ─── ORDER ────────────────────────────────────────────────────────────────────────────────────
|
||||
#
|
||||
# Filenames do not order anything: `kubectl apply -k` and Argo both read this list as a set. The
|
||||
# order is carried by `argocd.argoproj.io/sync-wave` annotations on the resources themselves, so
|
||||
# that it lives beside the thing being ordered rather than in a list somebody has to keep in step.
|
||||
# See the table in README.md.
|
||||
apiVersion: kustomize.config.k8s.io/v1beta1
|
||||
kind: Kustomization
|
||||
|
||||
resources:
|
||||
- 00-namespace.yaml
|
||||
# The identity that mints the generated secrets, and the Job that uses it. The Job is a sync hook;
|
||||
# its ServiceAccount, Role and RoleBinding are ordinary resources in an earlier wave.
|
||||
- 01-secret-job.yaml
|
||||
- 02-config.yaml
|
||||
- 03-migrate-job.yaml
|
||||
- 04-api.yaml
|
||||
- 05-web.yaml
|
||||
- 06-ingress.yaml
|
||||
- 07-disruption.yaml
|
||||
# Remove this line if you point REDIS_URL at a managed Redis. It deploys three Redis processes and
|
||||
# three sentinels; see the README on what that costs on three nodes.
|
||||
- 08-redis-sentinel.yaml
|
||||
|
||||
# ─── THE THREE IMAGES ───────────────────────────────────────────────────────────────────────────
|
||||
#
|
||||
# By DIGEST, not by tag, and the manifests carry `@sha256:REPLACE_ME` so that an unedited copy fails
|
||||
# loudly rather than quietly pulling something.
|
||||
#
|
||||
# A tag is a name that can be repointed; a digest is the bytes. It matters more here than in most
|
||||
# places because the migration Job and the api Deployment must be the SAME BUILD — a schema applied
|
||||
# by one version and served by another is the failure this whole ordering exists to prevent, and two
|
||||
# copies of a mutable tag pulled a minute apart can be two different images.
|
||||
#
|
||||
# `dev` and `stable` are channels, so they are exactly the kind of name not to pin to. Resolve one
|
||||
# to its digest and put that here:
|
||||
#
|
||||
# docker buildx imagetools inspect git.luxit.be/luxit/jarvis-api:stable --format '{{.Manifest.Digest}}'
|
||||
#
|
||||
# This is also the whole of a version bump: change these lines, commit, and let the controller do
|
||||
# the rest.
|
||||
#
|
||||
# THREE, not two. `jarvis-agent-dist` is easy to miss — it is an initContainer in 04-api.yaml rather
|
||||
# than a container of its own — and missing it is the worst possible half-fix: two images pinned
|
||||
# from here and one left carrying `REPLACE_ME` in the file, so the render succeeds and the api pod
|
||||
# never starts. It is also the one that may legitimately be absent: leaving that initContainer out
|
||||
# is supported, and the installer then answers 503 saying no agent build is published.
|
||||
images:
|
||||
- name: git.luxit.be/luxit/jarvis-api
|
||||
digest: sha256:REPLACE_ME
|
||||
- name: git.luxit.be/luxit/jarvis-web
|
||||
digest: sha256:REPLACE_ME
|
||||
- name: git.luxit.be/luxit/jarvis-agent-dist
|
||||
digest: sha256:REPLACE_ME
|
||||
Reference in New Issue
Block a user