|
1 |
| -== Consuming Patterns |
2 |
| - |
| 1 | +== Consuming Validated Patterns |
3 | 2 | include::_attributes.adoc[]
|
4 | 3 |
|
5 | 4 | include::main@vp-workshop:ROOT:partial$topicHeader.adoc[]
|
| 5 | + |
| 6 | +* Validated Pattern Deployment workflow |
| 7 | +* Describing a pattern |
| 8 | +* Using the patterns operator |
| 9 | +** And the patterns.sh script |
| 10 | +* Preparing your environment |
| 11 | +* Understand our base pattern |
| 12 | +* To fork or not to fork |
| 13 | +
|
| 14 | +== Validated Pattern workflow |
| 15 | +[#workflow] |
| 16 | + |
| 17 | +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. |
| 18 | + |
| 19 | +image::consuming-vpWorkflow-hub.png[Hub Cluster] |
| 20 | + |
| 21 | +1. The patterns operator deploys an instance of {rh-gitops} and creates the initial application |
| 22 | +2. ArgoCD then deploys the operators, namespaces, projects and applications defined in the values files |
| 23 | +3. If deploying across multiple clusters, the framework uses {rhacm} policies to create the instance of {rh-gitops} on the remote cluster |
| 24 | + |
| 25 | +INFO: `values-hub.yaml` is the primary values file for the `hub` cluster |
| 26 | + |
| 27 | +IMPORTANT: Deploying the pattern through the OpenShift Console or via `pattern.sh` will deploy the patterns operator. |
| 28 | + |
| 29 | +image::consuming-vpWorkflow-managedCluster.png[Managed Cluster] |
| 30 | + |
| 31 | +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. |
| 32 | +2. {rhacm} will confirm the cluster is managed then deploy a rhacm agent |
| 33 | +3. A placement policy is then deployed to the managed cluster which installs an instances of {rh-gitops} |
| 34 | +4. The managed cluster's instance of ArgoCD will then deploy the resources declared in `values-clustergroup.yaml` |
| 35 | + |
| 36 | +=== Element Layering |
| 37 | +[#layering] |
| 38 | + |
| 39 | +The base component of every Validated Pattern is `common` - which is a link:https://github.com/validatedpatterns/common[Github Repo] |
| 40 | + |
| 41 | +image::consuming-common.png[common] |
| 42 | + |
| 43 | +Without further configuration, common is acutally quite boring. So let's add another layer! |
| 44 | + |
| 45 | +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, {rhacs}, and an enterprise container registry. The framework will deploy and configure these components through Helm charts, kustomize manifests or Ansible if necessary. |
| 46 | + |
| 47 | +image::consuming-common-solution-layering.png[] |
| 48 | + |
| 49 | +What if we wanted to swap these products out with a similar or like-in-kind solution? The workflow remains the same: |
| 50 | + |
| 51 | +- remove the undesired application declaration |
| 52 | +- declare the new application in your values file |
| 53 | +- declare where the helm charts reside (path, repo) |
| 54 | + |
| 55 | +The following graphic illustrates swapping components in the framework: |
| 56 | + |
| 57 | +image::consuming-common-solution-layering-modular.png[] |
| 58 | + |
| 59 | +[#multiArgos] |
| 60 | + |
| 61 | +You may be asking yourself ... |
| 62 | + |
| 63 | +image::consuming-multipleArgos.png |
| 64 | + |
| 65 | + |
| 66 | + |
0 commit comments