A bank’s digital channels ran on OpenShift 3, past its end of life. We moved production to OpenShift 4 inside one short change window, rebuilt disaster recovery across two sites, then ran the platform and its DevSecOps toolchain around the clock.
The bank’s digital channels, from onboarding and eKYC to lending, wealth, insurance, securities and anti-money-laundering, run as dozens of microservices on one container platform, behind an API gateway and a service mesh that reach core banking, next to traditional Java middleware.
Drawn new for this page. No screens or data from the client's systems.
Production moves from OpenShift 3, past its end of life, to OpenShift 4 at the primary site. A second cluster at the DR site receives continuous replication. The cutover runs as pre-sync, delta sync, final sync and go-live, with the last two inside one change window. Afterwards the platform is run 24x7 across production, DR and non-production.
OpenShift 3 has no in-place upgrade to OpenShift 4, so this was a migration to a new platform, not an update.
Inventoried every persistent volume and service before planning any downtime. Real usage was well above what had been provisioned and several services shared one NFS volume, so the plan was resized and shared volumes split before the move.
Pre-synced the data to OpenShift 4 through the bastion with rsync, then ran delta syncs verified by checksum, so the cutover had little left to move.
Stopped the workloads on OpenShift 3, ran the final sync, exported and imported the remaining data, deployed and verified on OpenShift 4, then went live, all inside one short change window.
Built the DR cluster on the regional DR pattern: OpenShift Data Foundation mirrors block volumes to the DR site, Red Hat Advanced Cluster Management places applications and fails them over, and Submariner links the cluster networks. A full initial sync, then continuous replication, then rehearsed runbooks for switching production to DR and back.
Froze a NeoLoad release, mirrored its images and Helm charts into the internal registry, and deployed it on the platform fully offline, working around gaps in the vendor’s own install guide, then smoke-tested it.
Transition, stabilize, operate: the platform, the middleware and the whole toolchain (Jenkins, Argo CD, SonarQube, Nexus, Trivy, Prometheus and Grafana) across production, DR and non-production, with SLAs per incident priority.
How a change reaches production with no internet access, and how production reaches the DR site.
Vendor images, operators and charts come in from outside through an approved, checksummed transfer into the internal registry; nothing inside the air gap reaches the internet. Inside, a change moves from Git through a Jenkins build, a Kaniko image build, the SonarQube quality gate and scans by Trivy and Red Hat Advanced Cluster Security into Sonatype Nexus, and Argo CD syncs it to OpenShift 4. Red Hat Advanced Cluster Management places applications on the primary and DR sites and fails them over; OpenShift Data Foundation mirrors volumes from the primary site to the DR site, and Submariner links the cluster networks. Both sites run on VMware vSphere. Prometheus, Thanos, Grafana and Loki observe the platform.
Every product and practice in this work, named so an engineer can check it.
No. OpenShift 4 is a new platform, so the move is a migration: workloads and persistent volumes are copied to a new cluster. We measure every volume first, pre-sync the data, run checksum-verified delta syncs, and leave only the final sync, deployment and checks for the change window.
With two clusters, one per site. OpenShift Data Foundation mirrors block volumes to the DR site, Red Hat Advanced Cluster Management places applications and fails them over, and Submariner connects the cluster networks. Runbooks cover switching to DR and back, including data that has not replicated yet.
Yes. Release images, operators, Helm charts and tool images are mirrored into an internal registry, and every install runs from that mirror, including load-testing tools that expect to download at install time.
Tell us what you run and what is getting in the way. You get a reply within 24 hours.
