How Caddy Serves a Static Site: The Request Flow
See how Caddy handles a request for a static site, from DNS resolution through container routing to file_server, and how TLS and redirects fit into the flow.
Loading post…
Red HatAjay KanseTutorial
Build a multi-tenant platform with OpenShift Dev Spaces
Summary
Local developer workstations introduce three concrete operational risks: production-parity risk from environment drift, slow time-to-first-commit for new engineers, and unmanaged security exposure from misconfigured tools. Red Hat OpenShift Dev Spaces addresses these by moving compute and tooling into containerized workspaces running directly on the cluster, with environments declared as code in a devfile. A production deployment requires four-zone namespace isolation separating control (openshift-devspaces), core server (devspaces-checluster), secure asset (devspaces-openvsx), and sandbox (username-devspaces) zones to prevent operator reconciliation from overriding custom configurations. Resource governance uses a two-tier model with defaultContainerResources fallback limits and containerResourceCaps absolute per-container ceilings, while automated cleanup cron jobs (monthly on the 1st) and inactivity idling (after 4 hours) protect etcd health by removing stopped workspaces after 30 days. The guide concludes with next steps for authentication and private extension registries.
Context
Local developer workstations introduce operational risks: environment drift, slow onboarding, and unmanaged security exposure. The solution is a cloud development environment (CDE) where compute and tooling move off laptops onto a governed platform. Red Hat OpenShift Dev Spaces implements this model with containerized workspaces declared as code in a devfile.
Approach / What changed
Deploy OpenShift Dev Spaces with four isolated namespaces (control, core server, secure asset, sandbox) to separate operator configs from workloads. Use defaultContainerResources and containerResourceCaps for two-tier resource limits. Enable workspace cleanup CronJob with 30-day retention and inactivity idling of 4 hours to protect etcd.
Takeaways
Four-zone namespace isolation prevents the operator’s reconciliation loop from silently overriding custom DevWorkspaceOperatorConfig parameters by placing the CheCluster CR in its own dedicated namespace.
Two-tier resource governance uses defaultContainerResources as a system-wide fallback and containerResourceCaps as an absolute per-container ceiling, preventing memory over-provisioning while allowing multi-container workspaces.
Automated cleanup of stopped workspaces (30-day retention via CronJob) combined with inactivity idling (4 hours) keeps etcd state footprint within safe limits (under 8 GB) to maintain cluster stability.
FAQ
How does namespace isolation prevent config overrides?
Placing the CheCluster custom resource in its own namespace (devspaces-checluster) prevents the operator's reconciliation loop from resetting custom parameters like workspace pruning rules and idle timeouts to factory defaults.
What is the two-tier resource governance model?
defaultContainerResources sets per-container fallback limits (e.g., 500m CPU, 2Gi memory), while containerResourceCaps enforces an absolute ceiling per container (e.g., 4 CPU, 32Gi memory). Caps apply per container, not per workspace pod.
How does automated cleanup protect etcd health?
Stopped workspaces hold state as custom resources in etcd. The cleanup CronJob deletes workspaces stopped for more than 30 days, and inactivity idling stops pods after 4 hours, keeping etcd footprint under the recommended 8 GB limit.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Visual explainers
BYOC in Five Checkpoints: Name, Split, Land, Govern, Operate
A five-checkpoint walkthrough of BYOC: name the control you need, split control and data planes, build the landing zone, govern data in place, then operate inside your own tenant.
Five Checkpoints to Bitwise-Deterministic Training Runs
A five-checkpoint workflow for making large-scale training runs bitwise reproducible: pick the guarantee, fingerprint the run, and trace divergence down to the kernel.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.