Installation Details | Validated Patterns

Installation Steps

These are the steps run by make install and what each one does:

operator-deploy

The operator-deploy task installs the Validated Patterns Operator, which in turn creates a subscription for the OpenShift GitOps operator and installs both the cluster and hub instances of it. The clustergroup application then reads the values-global.yaml and values-hub.yaml files for other subscriptions and applications to install.

The install and upgrade targets are interchangeable and handle both initial installation and updates. These targets ensure that the necessary components, including OpenShift GitOps and the clustergroup application, are deployed and updated as needed.

Imperative section

Part of the operator-deploy process is creating and running the imperative file as defined in the hub values file. This pattern includes running the playbook to deploy the metal worker.

The playbook code is here.

This Ansible Playbook deploys a node to run the Virtual Machines for the demo. The playbook uses the OpenShift machineset API to provision the node in the first availability zone it finds. Currently, AWS is the only major public cloud provider that offers the deployment of a metal node through the normal provisioning process. We hope that Azure and GCP will support this functionality soon.

Metal nodes are more expensive than standard AWS instances. However, running the demo without hardware acceleration can take about ~4x as long. It usually takes 20-30 minutes for the metal node to become available to run VMs.

Assuming your kubeconfig is currently set up to point to your cluster, list all MachineSets across all namespaces in an OpenShift cluster, using the following command:

$ oc get -A machineset

You are looking for a machineset with metal-worker in its name:

NAMESPACE               NAME                                        DESIRED   CURRENT   READY   AVAILABLE   AGE
openshift-machine-api   mhjacks-aeg-qx25w-metal-worker-us-west-2a   1         1         1       1           19m
openshift-machine-api   mhjacks-aeg-qx25w-worker-us-west-2a         1         1         1       1           47m
openshift-machine-api   mhjacks-aeg-qx25w-worker-us-west-2b         1         1         1       1           47m
openshift-machine-api   mhjacks-aeg-qx25w-worker-us-west-2c         1         1         1       1           47m
openshift-machine-api   mhjacks-aeg-qx25w-worker-us-west-2d         0         0                             47m

When the metal-worker is showing READY and AVAILABLE, the virtual machines will begin provisioning on it.

The metal node is destroyed when the cluster is destroyed. The script is idempotent and creates at most one metal node per cluster.

post-install

All the steps of post-install are idempotent. If you want or need to reconfigure vault or AAP, the recommended way to do so is to call make post-install. This might change as we move elements of this pattern into the new imperative framework in common.

Specific processes that are called by post-install include:

vault-init

The vault-init task streamlines the initialization and unsealing of Vault, ensuring that the necessary keys and configurations are in place. Its design allows for safe execution even against an already active Vault cluster, providing both efficiency and security in managing secrets.

load-secrets

This process employs an Ansible playbook to read the values-secret.yaml file and securely store its data as key-value pairs in HashiCorp Vault. The External Secrets Operator (ESO) then retrieves these secrets from Vault and injects them into the Kubernetes cluster as native Kubernetes Secrets, making them accessible to applications running within the cluster.

In this specific implementation, the pattern utilizes the SSH public key for the kiosk virtual machines (VMs) using the ESO, ensuring that sensitive information, such as SSH keys, is securely managed and available to the VMs as needed.

Re-running the script will update the secrets in Vault if there have been changes. If the secret values remain unchanged, re-execution is safe and will not adversely affect the existing configurations.

configure-controller

Key components of the configuration process:

Retrieving AAP Credentials: The script runs the ansible_get_credentials.yml playbook to obtain necessary credentials for accessing and managing the AAP instance.
Parsing Secrets: It then executes the parse_secrets_from_values_secret.yml playbook to extract and process sensitive information stored in the values_secret.yaml file, which includes passwords, tokens, or other confidential data required for configuration.
Configuring the AAP Instance: Finally, the script runs the ansible_configure_controller.yml playbook to set up and configure the AAP controller based on the retrieved credentials and parsed secrets.

OpenShift GitOps (ArgoCD)

OpenShift GitOps is central to this pattern as it is responsible for insalling all of the other components. The installation process is driven through the installation of the clustergroup cart. This in turn reads the repo’s global values file, which instructs it to read the hub values file. This is how the pattern knows to apply the Subscriptions and Applications listed further in the pattern.

OpenShift Virtualization (KubeVirt)

OpenShift Virtualization is a framework for running virtual machines as native Kubernetes resources. While it can run without hardware acceleration, the performance of virtual machines will suffer terribly; some testing on a similar workload indicated a 4-6x delay running without hardware acceleration, so at present this pattern requires hardware acceleration. The pattern provides a script deploy-kubevirt-worker.sh which will provision a metal worker to run virtual machines for the pattern.

OpenShift Virtualization currently supports only AWS and on-prem clusters; this is because of the way that baremetal resources are provisioned in GCP and Azure. We hope that OpenShift Virtualization can support GCP and Azure soon.

More details about the way we use OpenShift Virtualization are available here.

Ansible Automation Platform (AAP, formerly known as Ansible Tower)

The use of Ansible Automation Platform is really the centerpiece of this pattern. We have recognized for some time that the concept and design principles of GitOps should apply to things outside of Kubernetes, and we believe this pattern gives us a way to do that.

All of the Ansible interactions are defined in a Git Repository; the Ansible jobs that configure the VMs are designed to be idempotent (and are scheduled to run every 10 minutes on those VMs).

It is very much the intention of this pattern to make it easy to replace the specific Edge management use case with another one. Some ideas on how to do that can be found here.

Specifics of the Ansible content for this pattern can be seen here.

More details of the specifics of how AAP is configured are available here.