Consuming Validated Patterns

Topic Objectives

In this topic we will discuss:

  • Validated Pattern Deployment workflow

  • Describing a pattern

  • Using the patterns operator

    • And the patterns.sh script

  • Preparing your environment

  • Understand our base pattern

  • To fork or not to fork

Validated Pattern workflow

Let’s dive into what happens when we deploy a pattern! Take a look at the following graphic to see what is deployed on the hub clusterGroup cluster.

Hub Cluster

  1. The patterns operator deploys an instance of Red Hat OpenShift GitOps and creates the initial application

  2. ArgoCD then deploys the operators, namespaces, projects and applications defined in the values files

  3. If deploying across multiple clusters, the framework uses Red Hat Advanced Cluster Management for Kubernetes policies to create the instance of Red Hat OpenShift GitOps on the remote cluster

values-hub.yaml is the primary values file for the hub cluster
Managed Cluster

  1. When a managed cluster is joined to Red Hat Advanced Cluster Management for Kubernetes it needs to have a clusterGroup label applied to it for the correct policies and applications to be deployed.

  2. Red Hat Advanced Cluster Management for Kubernetes will confirm the cluster is managed then deploy a rhacm agent

  3. A placement policy is then deployed to the managed cluster which installs an instances of Red Hat OpenShift GitOps

  4. The managed cluster’s instance of ArgoCD will then deploy the resources declared in values-clustergroup.yaml

Deploying the pattern through the OpenShift Console or via pattern.sh will deploy the patterns operator.

Element Layering

The base component of every Validated Pattern is common - which is a Github Repo

common

Without further configuration, common is actually quite boring. So let’s add another layer!

Your specific industry or use-case is layered into the framework and utilizes the underlying common. In this example the solution includes a bespoke application, cloud-native cluster storage, Red Hat Advanced Cluster Security for Kubernetes, and an enterprise container registry. The framework will deploy and configure these components through Helm charts, kustomize manifests or Ansible if necessary.

consuming common solution layering

What if we wanted to swap these products out with a similar or like-in-kind solution? The workflow remains the same:

  • remove the undesired application declaration

  • declare the new application in your values file

  • declare where the helm charts reside (path, repo)

The following graphic illustrates swapping components in the framework:

consuming common solution layering modular

Multiple ArgoCDs

You may be asking yourself …​

consuming multipleArgos