Zen

Source string Source string

230/10000 · 230

The string is read only.

English Actions
The terrain: pad ↔ infinix
Two places, one private network:
pad (your notebook) infinix (the cluster, k3s)
───────────────────── ─────────────────────────────
• you build + test the app here • runs the live workloads
• the project source lives here • holds /root/k8s-gitops/ (the truth)
• iSecrets (pass) lives here, your store • Flux reads the LOCAL repo + reconciles
• a dev/test keypair was minted here • Harbor registry on the VPN IP
• production keys are GENERATED here
│ ▲
└──────── Headscale VPN (100.64.x) ───────┘
private mesh; infinix reachable at 100.64.0.8
Why some things only happen on infinix: the **production private key** is born on infinix and never leaves it; the **image push** targets the registry that lives on the infinix VPN. pad is where you *author*; infinix is where it *lives*. (More terrain detail in the German companion, Station 1.)
The five characters
A deploy is a short play with five parts. Meet them — each is just "a thing with one job":
| Character | Plain role | The real name here |
|-----------|------------|--------------------|
| **gitops-write** | the only write-pen for the truth folder | `sudo gitops-write` (a lock-based commit) |
| **Flux** | the gardener: reads the YAML, makes the cluster match | FluxCD, reading `/root/k8s-gitops/` |
| **the registry** | the image warehouse the app runs from | Harbor, `docker.registry.infinity.labs` |
| **iSecrets** | the audited key-ring for passwords + keys | `pass.manager` (`pass` / `pass_get`) |
| **cert-manager** | fetches the HTTPS certificate automatically | cert-manager + `letsencrypt-prod` |
The first two are the heart. **You write a file with the one pen (`gitops-write`); Flux reads it and tends the cluster to match.** That single loop — *write → Flux reconciles* — is all of GitOps. Everything else (the registry, the key-ring, the cert) is a supporting actor that loop pulls from.
The two honesty rules of a safe deploy
A deploy is the one place where a mistake is *irreversible* (you can't un-serve a leaked key, un-break a live site for users mid-request). So iDeploy front-loads all the cheap, reversible work and gates the irreversible part behind it. Two rules do most of that safety.
Rule 1 — structure-live-first (`replicas: 0`)
Bring up the **whole structure first, with zero running copies of the app.** Namespace, resource quota, service, ingress, **and the TLS certificate** — all created while the deployment is scaled to `replicas: 0`. No image is pulled, no pod runs, nothing can crash. You prove that DNS resolves, the ingress routes, and Let's Encrypt issues a real certificate — *while the app is still dark.*
> In the real lernreise-garden deploy, the Let's Encrypt cert
> (`lernreise-grow-tls`) issued successfully at **0/0 replicas** — proving DNS,
> ingress, and ACME all work end-to-end *before any image existed.* If something
> was going to break, it broke here, where breaking is free.
Rule 2 — verify in the cluster, not in your head
"`kubectl apply` succeeded" is **not** "it works." Done means the cluster
*demonstrably serves the thing*: `curl -sI https://<domain>` returns 200, the
served certificate is the issued one, and the app's **own gate** passes (a
request with a valid token succeeds; one without is rejected). You read reality
back from the cluster, not from your intentions.
> This is the same spirit as iState's *"the moon is not an alarm"* (see
> [iState](../istate/OVERVIEW.md)): never let a hopeful belief stand in for a
> confirmed fact. A green `apply` is a hope; a 200 from the live URL is a fact.
Together: **make the reversible structure real and prove it (Rule 1), then — only then — flip the one irreversible switch and confirm reality (Rule 2).**
The big picture (one diagram)
The whole shape, left to right. The **bold** path is what decides reality; the side-boxes are what that path pulls from.
AUTHOR (pad) THE TRUTH (infinix) THE CLUSTER
─────────── ──────────────────── ───────────

project source ──┐
manifests (YAML) │ ┌──────────────────────────┐ ┌────────────────┐
├───▶ │ /root/k8s-gitops/ │ │ Flux │ ◀ the gardener
sudo gitops-write│ pen │ applications/<app>/ │ ───▶ │ reconciles │
(lock-based commit) │ clusters/production/<CR> │ read │ YAML → cluster│
└────────────┬─────────────┘ └───────┬────────┘
│ │
┌────────────────────┼────────────────────┐ ▼
▼ ▼ ▼ namespace · quota
┌──────────────┐ ┌──────────────────┐ ┌───────────────┐ · service
│ registry │ │ iSecrets │ │ cert-manager │ · ingress
│ (Harbor): │ │ (pass.manager): │ │ + letsencrypt │ · TLS cert ✓
│ the image │ │ robot cred (R2) │ │ → HTTPS cert │ · deployment
│ warehouse │ │ + the keypair │ └───────────────┘ (replicas: 0→1)
└──────────────┘ └──────────────────┘
Read it left to right: you **author** on pad; the one write-pen commits the YAML into the **truth folder** on infinix; **Flux** reads that folder and makes the **cluster** match — pulling the image from the **registry**, the secrets from **iSecrets**, and the cert from **cert-manager** as it goes.
The full mechanism — producer by producer, with the real commit `14ce433`, the per-app CR, and a tiny build-it-yourself GitOps loop — is in the [deep dive](DEEPDIVE.md).
What was real in this deploy (the honest ledger)
This module is grounded in one real deploy: the **lernreise coop garden**, staged onto infinix on 2026-06-12 → 13. To stay honest, here is exactly what is **live** versus **pending** as of writing.
**Live (done, verifiable):**
Committed `14ce433` to `/root/k8s-gitops/` via `gitops-write`; the per-app Flux `Kustomization` CR applied; Flux reconciled to that commit.
In namespace `lernreise-garden`: ResourceQuota, Service, Ingress (`lernreise.grow.b0x.store`), and **deployment at `replicas: 0`** (no pods, no image needed yet).
**TLS certificate ISSUED** — `lernreise-grow-tls = True` (Let's Encrypt prod).
The parent **`flux-system` was resumed** cleanly (staged, with a diff-gate before every mutating step; zero deletions, zero pruned real objects). All 19 Kustomizations `Ready`. Legacy `lernreise` and `grow-main` untouched.
**Pending (the two residuals — honestly not yet done):**
**R1 — the missing GitLab deploy-key.** The 13 GitOps commits are written and live *on infinix* (Flux reads the local repo), but pushing them to the durable mirror `git.labs.ooo` **failed on SSH auth** — root on infinix holds no key the GitLab server accepts. We *correctly stopped and did not force.* This is a **durability/mirroring** gap, not a cluster-state issue. *(You wrote the letter; you lack the key to the postbox.)*

Loading…

User avatar None

String added in the repository

  1. infinity-learn
  2. docs
  3. English
> This is the same spirit as iState's *"the moon is not an alarm"* (see
> [iState](../istate/OVERVIEW.md)): never let a hopeful belief stand in for a
> confirmed fact. A green `apply` is a hope; a 200 from the live URL is a fact.
> This is the same spirit as iState's *"the moon is not an alarm"* (see
> [iState](../istate/OVERVIEW.md)): never let a hopeful belief stand in for a
> confirmed fact. A green `apply` is a hope; a 200 from the live URL is a fact.
a month ago
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Consecutive duplicated words: German, German

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
md-text, no-wrap, read-only
Source string location
ideploy/OVERVIEW.md:147
String age
a month ago
Last updated
a month ago
Source string age
a month ago
Translation file
po/infinity-learn.pot, string 430