Solution Pattern: Instant Multi Cloud

Workshop

In the workshop, we will be deploying an application OsToy to managed OpenShift clusters running in AWS, Azure and GCP.

1. Installing the workshop environment

These managed OpenShift clusters are required for the workshop:

  • Two Red Hat Openshift Service on AWS (ROSA) clusters(one for dev and second for prod)

  • One Azure Red Hat Openshift (ARO) cluster

  • One Openshift Dedicated on GCP cluster

Once clusters are ready, you can move to "Delivering the workshop" part.

If you are a Red Hatter, you can follow the below steps to get these above clusters created.

  • Login to Red Hat Demo Platform and create the managed OpenShift clusters:

    • Two Red Hat Openshift Service on AWS (ROSA) clusters(one for dev and second for prod) using this link ROSA

    • Azure Red Hat Openshift (ARO) using this link ARO

    • Openshift Dedicated on GCP by following this video.

2. Delivering the workshop

  • Fork this repo using workshop branch: Repository link

  • Once forked, go to your repo in Github UI and go to Settings → Security → Secrets and Variables → Actions.

wkshp secrets

  • Under Secrets, click on the “New repository secret” button to create a secret. We will be creating the following secrets which will be used by our workflow to access and deploy our applications:

    • ROSA_SERVER: API server url for ROSA cluster.

    • ROSA_TOKEN: Token for ROSA cluster.

    • ARO_SERVER: API server url for ARO cluster.

    • ARO_TOKEN: Token for ARO cluster.

    • GCP_SERVER: API server url for GCP cluster.

    • GCP_TOKEN: Token for GCP cluster.

    • ROSA_SERVER_PROD: API server url for ROSA PROD cluster.

    • ROSA_TOKEN: Token for ROSA PROD cluster.

    • QUAY_TOKEN: Token for pushing and pulling container images to Quay container registry.

wkshp secrets2

  • Go to Settings → Security → Secrets and Variables → Actions → Variables tab. We will be creating variables that will control the flow of the workflow:

    • ARO_LIVE: if set to true, it will deploy the application to the ARO cluster.

    • GCP_LIVE: if set to true, it will deploy the application to the GCP cluster.

    • ROSA_LIVE: if set to true, it will deploy the application to the ROSA DEV cluster.

    • ROSA_PROD: if set to true, it will deploy the application to the ROSA PROD cluster.

wkshp vars

  • Now let us go through the contents of the workflow file: .github/workflows/openshift.yml. Workflow is divided into the following stages:

    1. Build and Push to Quay: This stage will build the container image from source code and push to container registry Quay.

    2. ROSA deployment Dev: This stage deploys the application to the Dev ROSA environment/cluster.

    3. ROSA deployment PROD: This stage deploys the application to PROD ROSA environment/cluster.

    4. ARO deployment: This stage deploys the application to the ARO environment/cluster.

    5. GCP deployment: This stage deploys the application to the OSD GCP Openshift cluster.

  • As our workflow is ready, we can go to the Actions tab in GitHub UI and start the workflow using the workshop branch.

  • Once completed, the workflow UI will show the completed stages in green as shown below. We can expand the steps in the stage and check the logs for it.

wkshp run1
wkshp run2

  • Now we can browse the application by using the respective cloud’s Openshift console → Networking → Route → search for ostoy and open the ostoy route url.

    • ARO console UI:

      wkshp aro console

    • ARO - Ostoy application UI:

wkshp aro ostoy

  • Similarly we will access the OSToy application from Openshift clusters running in GCP and AWS.

    • GCP - OStoy application UI:

      wkshp gcp ostoy

    • ROSA - OStoy application UI:

      wkshp rosa ostoy

  • We can use third party Load Balancer Service such as Cloudflare to route the traffic to the application running in one of the clouds. For the end user, it will be seamless access.