From the CI/CD, Terraform, Helm and "whole flow" parts of your Conrad DevOps note.
_nuxt assets to Cloud Storage for the CDN → Terraform (secrets from Secret Manager, Helm release) → Helm fills the chart → Kubernetes pulls the image and rolls out the pods.app.cdnURL (runtime config NUXT_APP_CDN_URL) makes the HTML reference the CDN; upload before rollout, never delete old builds during a deploy.runtimeConfig, never baked into the image.mr-123.preview.… on wildcard DNS), declared as a GitLab environment with on_stop and auto_stop_in, pointed at shared staging backends, torn down with helm uninstall on merge or close.Your notes describe Kaniko correctly. It is worth knowing that Google archived the project in June 2025: if they still use it, ask whether a move to BuildKit or a maintained fork is planned, rather than presenting it as a problem.
helm upgrade --install --atomic --set image.tag=$CI_COMMIT_SHA deploy job from memory.--atomic rollbacks."GitLab CI runs the tests and the linter, then Kaniko builds the image without root privileges and pushes it tagged with the commit SHA. CI also uploads the hashed _nuxt assets to Cloud Storage for the CDN, so pods only render HTML. For the deployment, Terraform reads the secrets from Secret Manager and applies the Helm release, Helm fills the chart with the new tag and this environment's values, and Kubernetes rolls out new pods next to the old ones, sending them traffic once their readiness checks pass."
"For a while two versions serve traffic side by side, and cached HTML and open tabs still point at the old build's chunks. So assets are published before the pods roll out and old ones are kept for days, the HTML cache is versioned or purged so stale pages don't outlive their assets, Nuxt reloads the page when a chunk fails to load, and API changes stay backward compatible during the overlap. On top of that: images tagged by SHA for instant rollbacks, health checks gating traffic, and canaries for risky changes."
Nothing yet. Notes filed here show up on this page and the section overview.
Cloudflare at the edge
What Cloudflare does in front of Conrad's storefront and why the app runs on GKE rather than Workers, with answers to the open questions in your notes — WAF, Snippets, the CF-Device-Type header, Cloudflare Access, Apigee and the 512-character limit — and edge versus origin caching.
Docker and Kubernetes
The container and cluster basics from your Conrad notes — images and containers, a Nuxt multi-stage Dockerfile, what the image contains, .dockerignore, Compose and volumes, Deployment, Service, HPA and Istio VirtualService, probes, rolling updates and Service types.