Designing Air-Gapped OpenShift & CI/CD Delivery Without Direct Internet Access
Architectural trade-offs, mirror registry patterns, and Ansible day-2 automation when running enterprise Kubernetes inside isolated networks.
Most cloud-native tutorials assume unrestricted egress to Docker Hub, Quay.io, GitHub, and public Helm repositories. In regulated public-sector and financial infrastructure, outbound internet access from production clusters simply does not exist.
Here is the reference architecture and the practical trade-offs involved in operating Red Hat OpenShift with Azure DevOps and Ansible inside restricted networks.
Reference Topology
Key Architectural Decisions & Trade-Offs
1. Declarative Image Mirroring Over Ad-Hoc Tarballs
Manually copying container .tar archives across bastion hosts works once and fails at scale. Especially during OpenShift minor version upgrades, missing a single operator digest breaks cluster reconciliation.
- Decision: Enforce an internal enterprise registry acting as the single source of truth, paired with OpenShift
ImageDigestMirrorSet. - Trade-off: Higher upfront storage footprint for mirroring operator catalogs, traded for deterministic, repeatable rolling upgrades.
2. Why Combine Azure DevOps Pipelines with Ansible?
Kubernetes excels at managing workloads inside the cluster boundary, but enterprise reliability frequently breaks underneath or around it:
- Configuring load balancers, VIPs, DNS records, and firewall zones.
- OS-level hardening, custom CA trust bundles, and multipath storage prerequisites on bare-metal or VMware nodes.
- Automating pre-flight and post-flight cluster health assertions before Azure DevOps promotes a release stage.
3. Stateful Workloads: Knowing Where Block Ends and S3 Begins
- Block Storage (SAN via CSI): Reserved strictly for low-latency transactional databases and cluster monitoring TSDBs.
- S3-Compatible Object Storage: Used for build artifacts, backup snapshots, container registry backends, and unstructured assets.