consuming-patterns.adoc

menu	workshop
title	Validated Patterns
weight	50

Table of Contents

• Consuming Validated Patterns
• Element Layering
• The Base Architecture
  • GitOps
  • Secrets Management
  • ACM
  • Imperative Jobs

modules/comm-attributes.adoc :imagesdir: /images/workshop

Consuming Validated Patterns

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.

1. The patterns operator deploys an instance of {rh-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 {rhacm} policies to create the instance of {rh-gitops} on the remote cluster

Note	values-hub.yaml is the primary values file for the hub cluster

1. When a managed cluster is joined to {rhacm} it needs to have a clusterGroup label applied to it for the correct policies and applications to be deployed.

2. {rhacm} 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 {rh-gitops}

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

Important

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

Element Layering

Architecturally, Patterns share a very similar base structure, as seen below.

Your specific industry or use-case is layered into the framework and utilizes the underlying base structure. In this example, the solution includes a bespoke application, cloud-native cluster storage, {rhacs}, and an enterprise container registry. The framework will deploy and configure these components through Helm charts, Kustomize manifests or Ansible if necessary.

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:

The Base Architecture

So where exactly are these different architectural components defined?

GitOps

The {validated-patterns-op} automatically deploys an instance of {rh-gitops-short} when a Pattern CR is installed on the cluster.

Check out an example Pattern CR for an {mcg-pattern} installation:

apiVersion: gitops.hybrid-cloud-patterns.io/v1alpha1
kind: Pattern
metadata:
  name: multicloud-gitops
  namespace: openshift-operators
spec:
  clusterGroupName: hub
  gitSpec:
    targetRepo: https://github.com/validatedpatterns/multicloud-gitops.git
    targetRevision: main

When the {validated-patterns-op} reconciles this CR, it creates an Argo Application using the Validated Patterns Clustergroup Chart and the values-<.spec.clusterGroupName>.yaml values from the CR above.

Secrets Management

The default secrets backend uses Vault and ESO.

As you can see in our values-hub.yaml, we provide a namespace, subscription and an application for both of these components.

When we run ./pattern.sh make install it ultimately calls the rhvp.cluster_utils.load_secrets playbook and loads a secrets file from our home directory into Vault as part of the pattern installation process.

ACM

Similar to the secrets management, ACM is provided in values-hub.yaml as a namespace, subscription and an application. By providing a managedClusterGroups block in our values-hub.yaml we are able to provision spoke clusters with the Validated Patterns framework as well.

clusterGroup:
  managedClusterGroups:
    exampleRegion:
      name: group-one
      acmlabels:
        - name: clusterGroup
          value: group-one

Any cluster that ACM sees labeled with clusterGroup=group-one will be provisioned with our Clustergroup chart and linkhttps://github.com/validatedpatterns/multicloud-gitops/blob/main/values-group-one.yaml[values-group-one.yaml].

Imperative Jobs

The example imperative job in the {mcg-pattern} is

clusterGroup:
  imperative:
    jobs:
      - name: hello-world
        playbook: rhvp.cluster_utils.hello_world
        timeout: 234

This gets transformed by the Clustergroup chart into several resources. This process is a bit complex and we will cover it in more detail later.