109 lines
5.5 KiB
YAML
109 lines
5.5 KiB
YAML
# An Argo CD Application pointing at this directory. EXAMPLE — read it, do not apply it unedited.
|
|
#
|
|
# It is `.example.` for the same reason `01-secret.example.yaml` is: it names a repository that is
|
|
# not yours. Copy it into whatever repository holds your Argo Applications, change the three values
|
|
# marked below, and apply it there.
|
|
#
|
|
# ─── WHAT TO POINT IT AT ──────────────────────────────────────────────────────────────────────
|
|
#
|
|
# You have two honest choices, and the second is the one to grow into.
|
|
#
|
|
# DIRECTLY AT THIS DIRECTORY, as written below. Simplest, and it works — but the image digests live
|
|
# in `kustomization.yaml` here, so pinning a version means committing to a repository you do not
|
|
# own. Fine for reading, for a first cluster, and for tracking `main` on a lab estate.
|
|
#
|
|
# OR AS A BASE UNDER YOUR OWN OVERLAY, which is what most estates end up wanting:
|
|
#
|
|
# # your-repo/jarvis/kustomization.yaml
|
|
# apiVersion: kustomize.config.k8s.io/v1beta1
|
|
# kind: Kustomization
|
|
# resources:
|
|
# - https://git.luxit.be/Luxit/jarvis-selfhost//kubernetes?ref=main
|
|
# images:
|
|
# - name: git.luxit.be/luxit/jarvis-api
|
|
# digest: sha256:<the one you are running>
|
|
# - name: git.luxit.be/luxit/jarvis-web
|
|
# digest: sha256:<the one you are running>
|
|
# patches:
|
|
# - path: replicas.yaml # your node count, your ingress host, your storage class
|
|
#
|
|
# Then the Application points at YOUR repository, your digests are in a commit you control, and
|
|
# upgrading is a one-line diff you can review and revert. `?ref=` pins the base to a tag or a commit
|
|
# rather than tracking a branch that moves under you — pin it.
|
|
#
|
|
# ─── WHAT IS NOT IN GIT, AND MUST NOT BE ──────────────────────────────────────────────────────
|
|
#
|
|
# `jarvis-secrets`. See the note at the top of `kustomization.yaml`: a controller that reconciles a
|
|
# Secret full of placeholders will overwrite your real credentials with them, repeatedly, and
|
|
# nothing about the sync will look unhealthy while it does. Write it by hand or through
|
|
# SealedSecrets / ExternalSecrets / Vault, whose ciphertext IS safe to commit.
|
|
#
|
|
# `jarvis-generated` is minted in-cluster by the hook in `01-secret-job.yaml` and never exists in
|
|
# git at all. Back the vault key up out of the cluster the first time it is minted — see that file.
|
|
apiVersion: argoproj.io/v1alpha1
|
|
kind: Application
|
|
metadata:
|
|
name: jarvis
|
|
namespace: argocd
|
|
# Argo deletes an Application's resources when the Application is deleted. On something holding a
|
|
# database's credentials and a vault key, that should be a deliberate act rather than a
|
|
# consequence of `kubectl delete app jarvis` — so the finalizer is left OFF and pruning of the
|
|
# namespace is not automatic. Add it when you have decided that is what you want:
|
|
#
|
|
# finalizers:
|
|
# - resources-finalizer.argocd.argoproj.io
|
|
spec:
|
|
project: default
|
|
|
|
source:
|
|
# CHANGE ME — your repository, or the public one if you are only reading.
|
|
repoURL: https://git.luxit.be/Luxit/jarvis-selfhost.git
|
|
# CHANGE ME — a tag or a commit, not a branch. A branch moves; a cluster that follows one is a
|
|
# cluster whose version is decided by somebody else's merge.
|
|
targetRevision: main
|
|
path: kubernetes
|
|
|
|
destination:
|
|
server: https://kubernetes.default.svc
|
|
# Matches the namespace the manifests declare. They carry it explicitly, so this is agreement
|
|
# rather than instruction.
|
|
namespace: jarvis
|
|
|
|
syncPolicy:
|
|
# DELIBERATELY MANUAL, and this is the one setting to think hardest about before changing.
|
|
#
|
|
# Every sync runs the migration hook against your production schema. Automated, that means a
|
|
# commit to the tracked revision applies a schema change with nobody watching — and the one
|
|
# thing this whole directory is arranged to make visible (a migration that REFUSES because it
|
|
# would drop a column) becomes a failed sync notification instead of a person deciding.
|
|
#
|
|
# Turn it on once you trust the pipeline in front of it, not before:
|
|
#
|
|
# automated:
|
|
# prune: true
|
|
# selfHeal: true
|
|
|
|
# NOTHING HERE, and the absence is deliberate in one specific place.
|
|
#
|
|
# `CreateNamespace=true` is the option most Applications carry, and this one must not. The
|
|
# namespace is `00-namespace.yaml` at wave -3, and it carries the Pod Security labels that
|
|
# decide whether any of these pods are admitted at all. A namespace Argo creates for you has no
|
|
# labels — so the first sync would admit pods under no policy and enforce `restricted` a moment
|
|
# later, which is the one ordering this directory exists to get right.
|
|
#
|
|
# syncOptions: []
|
|
|
|
# The HorizontalPodAutoscaler in `05-web.yaml` targets the web Deployment, which also declares
|
|
# `replicas: 2`. Once the autoscaler acts, git and the cluster disagree about that field forever —
|
|
# and it is the autoscaler working, not drift. Without this, a `selfHeal` policy and the HPA push
|
|
# the replica count back and forth at each other indefinitely.
|
|
#
|
|
# The api Deployment is deliberately NOT here: nothing autoscales it, so git owns its replica
|
|
# count and a difference there is a real one worth showing.
|
|
ignoreDifferences:
|
|
- group: apps
|
|
kind: Deployment
|
|
name: jarvis-web
|
|
jsonPointers:
|
|
- /spec/replicas
|