Migrating OpenShift Applications Using Cluster Application Migration Tool and F5 CloudServices GSLB
May 27, 2020 | by
The Red Hat cluster application migration tool (CAM) migrates stateful and stateless applications from a source cluster to a destination cluster. This tool was originally built to help the migration from OpenShift Container Platform (OCP) 3 to 4, but can also be used between OCP4 clusters. CAM is available as an operator, and provides a rich user experience to simplify the migration process of your applications. This tool works at the namespace level, and will migrate all your Kubernetes objects as well as your persistent volumes (PVs). That said, after the migration is completed, you typically have to update your DNS record to send application traffic to your new cluster. When migrating applications at scale, this can become tricky as many DNS records might have to be updated, and your application has to be tested to assure it is running correctly after the migration is completed.
This is where the F5 CloudServices GSLB solution can significantly reduce the complexity of your migration. With GSLB, your overall migration process is fully automated, including any DNS update or application health check. The solution also provides an easy way to rollback your application in case of failure, or even slowly send traffic to your new cluster if your application is able to run in an active-active configuration.
Getting started is really easy. F5 Cloud Services provides a SaaS DNS LB solution that doesn’t require any provisioning or access to the OpenShift infrastructure.Using Ansible Playbooks, it automatically retrieves the routes of a given cluster on a per-project basis, populates these routes in your GSLB service, and even automatically creates application probes for health-checking purposes. You can then delegate the authoritative DNS for your OCP3 sub domain to F5, and get started with your migrations.
Here is a deep-dive demo showing end to end how this process works:
In CAM 1.2, it will be possible to have pre- or post-migration hooks. Hooks are simply a container that can run before or after a migration, allowing you to run an Ansible Playbook, or any other script of your choice. Using those hooks, it will be really easy to send a callback to F5 when a migration begins, or when a migration is successfully completed. As an example, you could then decide to send traffic to a temporary site while your migration maintenance is in progress, and ensure full, automatic control of your traffic for each migrated application.
Combining F5 CloudServices GSLB and the Red Hat cluster application migration tool is a great way to get full application mobility between all your OpenShift clusters.