Solution Pattern: Instant Multi Cloud

Architecture

1. An in-depth look at the solution’s architecture

This solution pattern uses the following components:

  • GitHub Repository: It contains the application code and we will use GitHub Actions to create a workflow that will deploy the application to Managed Openshift clusters.

  • Red Hat Openshift Service on AWS (ROSA): It is a fully-managed, turnkey application platform that allows you to focus on delivering value to your customers by building and deploying applications. Red Hat and AWS Site reliability engineering (SRE) experts manage the underlying platform so you do not have to worry about the complexity of infrastructure management. ROSA provides seamless integration with a wide range of AWS compute, database, analytics, machine learning, networking, mobile, and other services to further accelerate the building and delivering of differentiating experiences to your customers. We will be using ROSA to deploy our containerized application.

  • Azure Red Hat Openshift (ARO): It is a fully managed Red Hat Openshift service on Azure. It is jointly engineered, operated and supported by Microsoft and Red Hat with an integrated support experience. We will be using ARO to deploy our containerized application.

  • Openshift Dedicated in Google Cloud Platform: Openshift Dedicated is a complete Openshift Container Platform cluster as a cloud service, configured for high availability and dedicated to a single customer. OpenShift Dedicated is professionally managed by Red Hat and hosted on Google Cloud Platform (GCP). Each OpenShift Dedicated cluster comes with a fully managed control plane (Control and Infrastructure nodes), application nodes, installation and management by Red Hat Site Reliability Engineers (SRE), premium Red Hat Support, and cluster services such as logging, metrics, monitoring, notifications portal, and a cluster portal. We will be using OSD in GCP to deploy our containerized application.

arch diagram

2. More about the technology stack

2.1. What is Managed Openshift

  • More than Kubernetes: Kubernetes is a powerful orchestration engine. OpenShift delivers a complete application development, deployment and runtime platform adding features such as build pipelines, monitoring, security, service mesh, etc on top of upstream Kubernetes.

  • More than Software: Leverage our self-service dashboard and out-of-the-box optimized configuration to get fully-managed clusters in minutes, configured to meet your needs and on your preferred public cloud.

  • More than “Managed”: Unlike other ‘managed’ services on the market, Red Hat manages the full stack not just the Kubernetes control plane and is backed by the experience of our specialized 24x7 global SRE team.

2.2. What are Red Hat Openshift offerings:

openshift offerings

2.3. What is GitHub Actions:

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. We can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or we can host your own self-hosted runners in your own data center or cloud infrastructure.

Components of GitHub Actions:

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that we define or run an action, which is a reusable extension that can simplify your workflow.

  • Workflows: A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked into your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule. Workflows are defined in the .github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.

  • Events: An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a schedule, by posting to a REST API, or manually.

  • Jobs: A job is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

  • Actions: An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider. You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.

  • Runners: A runner is a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine.