Automation

Handmatig certificaat management is een recept voor outages. Certificaten verlopen om 3 uur ’s nachts in een feestdagenweekend. Renewal processen leven in tribal knowledge. Teams deployen services zonder HTTPS omdat “het te ingewikkeld is.” cert-manager automatiseert alles. Definieer welke certificaten je nodig hebt, en cert-manager regelt uitgifte, vernieuwing en Kubernetes Secret management. Voor altijd. Dit is een van de eerste dingen die ik installeer in elk cluster. Hoe cert-manager Werkt flowchart TD subgraph cluster["Kubernetes Cluster"] CM["cert-manager"] CERT["Certificate<br/>Resource"] SECRET["TLS Secret"] INGRESS["Ingress"] end subgraph external["Extern"] LE["Let's Encrypt<br/>ACME Server"] DNS["DNS Provider"] end CERT -->|"watched"| CM CM -->|"maakt"| SECRET CM <-->|"ACME protocol"| LE CM <-->|"DNS challenge"| DNS SECRET -->|"mount"| INGRESS Je maakt een Certificate resource cert-manager vraagt een certificaat aan bij de issuer (Let’s Encrypt, Vault, etc.) cert-manager voltooit de challenge (HTTP-01 of DNS-01) cert-manager slaat het certificaat op in een Kubernetes Secret Je Ingress/Gateway gebruikt de Secret voor TLS Vernieuwing gebeurt automatisch 30 dagen voor expiratie. ...

Versienummers zouden geen beslissing moeten zijn. Ze zouden een consequentie moeten zijn van de wijzigingen die je maakte. Semantic versioning (semver) heeft duidelijke regels: MAJOR: Breaking changes MINOR: Nieuwe features, backwards compatible PATCH: Bug fixes, backwards compatible Maar handmatig beslissen “is dit een minor of patch?” is foutgevoelig en inconsistent. Laten we het automatiseren. De Kern: Conventional Commits Het magische ingrediënt is conventional commits — een gestandaardiseerd commit message formaat dat tooling vertelt welk soort wijziging je maakte. ...