|
| 1 | +--- |
| 2 | +title: Getting Started |
| 3 | +weight: 10 |
| 4 | +aliases: /federated-edge-observability/getting-started/ |
| 5 | +--- |
| 6 | + |
| 7 | +# Deploying the Federated Edge Observability Pattern |
| 8 | + |
| 9 | +# General Prerequisites |
| 10 | + |
| 11 | +1. An OpenShift cluster ( Go to [the OpenShift console](https://console.redhat.com/openshift/create)). Currently this pattern only supports AWS. It could also run on a baremetal OpenShift cluster, because OpenShift Virtualization supports that; there would need to be some customizations made to support it as the default is AWS. We hope that GCP and Azure will support provisioning metal workers in due course so this can be a more clearly multicloud pattern. |
| 12 | +1. A GitHub account (and, optionally, a token for it with repositories permissions, to read from and write to your forks) |
| 13 | +1. The helm binary, see [here](https://helm.sh/docs/intro/install/) |
| 14 | +1. Ansible, which is used in the bootstrap and provisioning phases of the pattern install (and to configure Ansible Automation Platform). |
| 15 | +1. Please note that when run on AWS, this pattern will provision an additional worker node, which will be a metal instance (c5n.metal) to run the Edge Virtual Machines. This worker is provisioned through the OpenShift MachineAPI and will be automatically cleaned up when the cluster is destroyed. |
| 16 | + |
| 17 | +The use of this pattern depends on having a running Red Hat |
| 18 | +OpenShift cluster. It is desirable to have a cluster for deploying the GitOps |
| 19 | +management hub assets and a separate cluster(s) for the managed cluster(s). |
| 20 | + |
| 21 | +If you do not have a running Red Hat OpenShift cluster you can start one on a |
| 22 | +public or private cloud by using [Red Hat's cloud service](https://console.redhat.com/openshift/create). |
| 23 | + |
| 24 | +# Credentials Required in Pattern |
| 25 | + |
| 26 | +In addition to the openshift cluster, you will need to prepare a number of secrets, or credentials, which will be used |
| 27 | +in the pattern in various ways. To do this, copy the [values-secret.yaml template](https://github.com/validatedpatterns-sandbox/federated-edge-observability/blob/main/values-secret.yaml.template) to your home directory as `values-secret.yaml` and replace the explanatory text as follows: |
| 28 | + |
| 29 | +* AWS Credentials (an access key and a secret key). These are used to provision the metal worker in AWS (which hosts |
| 30 | +the VMs). If the portworx variant of the pattern is used, these credentials will be used to modify IAM rules to allow |
| 31 | +portworx to run correctly. |
| 32 | + |
| 33 | +```yaml |
| 34 | +--- |
| 35 | +# NEVER COMMIT THESE VALUES TO GIT |
| 36 | +version: "2.0" |
| 37 | +secrets: |
| 38 | +``` |
| 39 | +* A username and SSH Keypair (private key and public key). These will be used to provide access to the Kiosk VMs in the demo. |
| 40 | +
|
| 41 | +```yaml |
| 42 | + - name: vm-ssh |
| 43 | + fields: |
| 44 | + - name: username |
| 45 | + value: 'Username of user to attach privatekey and publickey to - cloud-user is a typical value' |
| 46 | + |
| 47 | + - name: privatekey |
| 48 | + value: 'Private ssh key of the user who will be able to elevate to root to provision kiosks' |
| 49 | + |
| 50 | + - name: publickey |
| 51 | + value: 'Public ssh key of the user who will be able to elevate to root to provision kiosks' |
| 52 | +``` |
| 53 | +
|
| 54 | +* A Red Hat Subscription Management username and password. These will be used to register Kiosk VM templates to the Red Hat Content Delivery Network and install content on the VMs and to install the Otel collector. |
| 55 | +
|
| 56 | +```yaml |
| 57 | + - name: rhsm |
| 58 | + fields: |
| 59 | + - name: username |
| 60 | + value: 'username of user to register RHEL VMs' |
| 61 | + - name: password |
| 62 | + value: 'password of rhsm user in plaintext' |
| 63 | +``` |
| 64 | +
|
| 65 | +* A userData block to use with cloud-init. This will allow console login as the user you specify (traditionally cloud-user) with the password you specify. The value in cloud-init is used as the default; roles in the edge-gitops-vms chart can also specify other secrets to use by referencing them in the role block. |
| 66 | +
|
| 67 | +```yaml |
| 68 | + - name: cloud-init |
| 69 | + fields: |
| 70 | + - name: userData |
| 71 | + value: |- |
| 72 | + #cloud-config |
| 73 | + user: 'username of user for console, probably cloud-user' |
| 74 | + password: 'a suitable password to use on the console' |
| 75 | + chpasswd: { expire: False } |
| 76 | +``` |
| 77 | +
|
| 78 | +* A manifest file with an entitlement to run Ansible Automation Platform. This file (which will be a .zip file) will be posted to to Ansible Automation Platform instance to enable its use. Instructions for creating a manifest file can be found [here](https://www.redhat.com/en/blog/how-create-and-use-red-hat-satellite-manifest) |
| 79 | +
|
| 80 | +```yaml |
| 81 | + - name: aap-manifest |
| 82 | + fields: |
| 83 | + - name: b64content |
| 84 | + path: 'full pathname of file containing Satellite Manifest for entitling Ansible Automation Platform' |
| 85 | + base64: true |
| 86 | +``` |
| 87 | +
|
| 88 | +```yaml |
| 89 | +- name: automation-hub-token |
| 90 | + fields: |
| 91 | + - name: token |
| 92 | + value: 'An automation hub token for retrieving Certified and Validated Ansible content' |
| 93 | +``` |
| 94 | +
|
| 95 | +* An automation hub token generated at <https://console.redhat.com/ansible/automation-hub/token>. This is needed for |
| 96 | +the Ansible Configuration-as-Code tools. |
| 97 | +
|
| 98 | +```yaml |
| 99 | + - name: agof-vault-file |
| 100 | + fields: |
| 101 | + - name: agof-vault-file |
| 102 | + path: 'full pathname of a valid agof_vault file for secrets to overlay the iac config' |
| 103 | + base64: true |
| 104 | +``` |
| 105 | +
|
| 106 | +* An (optional) AGOF vault file. For this pattern, use the following (you do not need additional secrets for this |
| 107 | +pattern): |
| 108 | +
|
| 109 | +```yaml |
| 110 | +- name: agof-vault-file |
| 111 | + fields: |
| 112 | + - name: agof-vault-file |
| 113 | + value: '---' |
| 114 | + base64: true |
| 115 | +``` |
| 116 | +
|
| 117 | +```yaml |
| 118 | + - name: otel-cert |
| 119 | + fields: |
| 120 | + - name: tls.key |
| 121 | + path: 'full pathname to a pre-existing tls key' |
| 122 | + |
| 123 | + - name: tls.crt |
| 124 | + path: 'full pathname to a pre-existing tls certificate' |
| 125 | +``` |
| 126 | +
|
| 127 | +Certificates for the open telemetry collector infrastructure. "Snakeoil" (that is, self-signed) certs will automatically be generated by the makefile as follows by the `make snakeoil-certs` target, which is automatically run by `make install`: |
| 128 | + |
| 129 | +```yaml |
| 130 | +- name: otel-cert |
| 131 | + fields: |
| 132 | + - name: tls.key |
| 133 | + path: ~/federated-edge-observability-otel-collector-edge-observability-stack.key |
| 134 | +
|
| 135 | + - name: tls.crt |
| 136 | + path: ~/federated-edge-observability-otel-collector-edge-observability-stack.crt |
| 137 | +``` |
| 138 | + |
| 139 | +# How to deploy |
| 140 | + |
| 141 | +1. Login to your cluster using oc login or exporting the KUBECONFIG |
| 142 | + |
| 143 | + ```sh |
| 144 | + oc login |
| 145 | + ``` |
| 146 | + |
| 147 | + or set KUBECONFIG to the path to your `kubeconfig` file. For example: |
| 148 | + |
| 149 | + ```sh |
| 150 | + export KUBECONFIG=~/my-ocp-env/hub/auth/kubeconfig |
| 151 | + ``` |
| 152 | + |
| 153 | +1. Fork the [federated-edge-observability](https://github.com/validatedpatterns-sandbox/federated-edge-observability) repo on GitHub. It is necessary to fork to preserve customizations you make to the default configuration files. |
| 154 | + |
| 155 | +1. Clone the forked copy of this repository. |
| 156 | + |
| 157 | + ```sh |
| 158 | + git clone [email protected]:your-username/ansible-edge-gitops.git |
| 159 | + ``` |
| 160 | + |
| 161 | +1. Create a local copy of the Helm values file that can safely include credentials |
| 162 | + |
| 163 | + WARNING: DO NOT COMMIT THIS FILE |
| 164 | + |
| 165 | + You do not want to push personal credentials to GitHub. |
| 166 | + |
| 167 | + ```sh |
| 168 | + cp values-secret.yaml.template ~/values-secret.yaml |
| 169 | + vi ~/values-secret.yaml |
| 170 | + ``` |
| 171 | + |
| 172 | +1. Customize the deployment for your cluster (Optional - the defaults in values-global.yaml are designed to work in AWS): |
| 173 | + |
| 174 | + ```sh |
| 175 | + git checkout -b my-branch |
| 176 | + vi values-global.yaml |
| 177 | + git add values-global.yaml |
| 178 | + git commit values-global.yaml |
| 179 | + git push origin my-branch |
| 180 | + ``` |
| 181 | + |
| 182 | +Please review the [Patterns quick start](/learn/quickstart/) page. This section describes deploying the pattern using `pattern.sh`. You can deploy the pattern using the [validated pattern operator](/infrastructure/using-validated-pattern-operator/). If you do use the operator then skip to Validating the Environment below. |
| 183 | + |
| 184 | +1. (Optional) Preview the changes. If you'd like to review what is been deployed with the pattern, `pattern.sh` provides a way to show what will be deployed. |
| 185 | + |
| 186 | + ```sh |
| 187 | + ./pattern.sh make show |
| 188 | + ``` |
| 189 | + |
| 190 | +1. Apply the changes to your cluster. This will install the pattern via the Validated Patterns Operator, and then run any necessary follow-up steps. |
| 191 | + |
| 192 | + ```sh |
| 193 | + ./pattern.sh make install |
| 194 | + ``` |
| 195 | + |
| 196 | +The installation process will take between 45-60 minutes to complete. |
| 197 | + |
| 198 | +# Installation Validation |
| 199 | + |
| 200 | +* Check the operators have been installed using the OpenShift console |
| 201 | + |
| 202 | + ```text |
| 203 | + OpenShift Console Web UI -> Installed Operators |
| 204 | + ``` |
| 205 | + |
| 206 | + |
| 207 | + |
| 208 | +* Check all applications are synchronised |
| 209 | + |
| 210 | +Under the project `federated-edge-observability-hub` click on the URL for the `hub`gitops`server`. All applications will sync, but this takes time as ODF has to completely install, and OpenShift Virtualization cannot provision VMs until the metal node has been fully provisioned and ready. |
| 211 | + |
| 212 | + |
| 213 | + |
| 214 | +* Under Virtualization > Virtual Machines, the virtual machines will eventually show as "Running." Once they are in "Running" state the Provisioning workflow will run on them, install the OpenTelemetry collector, and start reporting metrics to the Edge Observability Stack in the hub cluster. |
| 215 | + |
| 216 | + |
| 217 | + |
| 218 | +* The Grafana graphs should be receiving data and drawing graphs for each of the nodes: |
| 219 | + |
| 220 | + |
| 221 | + |
| 222 | +Please see [Ansible Automation Platform](/federated-edge-observability/ansible-automation-platform/) for more information on how this pattern uses the Ansible Automation Platform Operator for OpenShift. |
| 223 | + |
| 224 | +# Infrastructure Elements of this Pattern |
| 225 | + |
| 226 | +## [Ansible Automation Platform](https://www.redhat.com/en/technologies/management/ansible) |
| 227 | + |
| 228 | +A fully functional installation of the Ansible Automation Platform operator is installed on your OpenShift cluster to configure and maintain the VMs for this demo. AAP maintains a dynamic inventory of kiosk machines and can configure a VM from template to fully functional kiosk in about 10 minutes. |
| 229 | + |
| 230 | +## OpenShift [Virtualization](https://docs.openshift.com/container-platform/4.16/virt/about_virt/about-virt.html) |
| 231 | + |
| 232 | +OpenShift Virtualization is a Kubernetes-native way to run virtual machine workloads. It is used in this pattern to host VMs simulating an Edge environment; the chart that configures the VMs is designed to be flexible to allow easy customization to model different VM sizes, mixes, versions and profiles for future pattern development. |
| 233 | + |
| 234 | +## HashiCorp [Vault](https://www.vaultproject.io/) |
| 235 | + |
| 236 | +Vault is used as the authoritative source for the Kiosk ssh pubkey via the External Secrets Operator. |
| 237 | +As part of this pattern HashiCorp Vault has been installed. Refer to the section on [Vault](https://validatedpatterns.io/secrets/vault/). |
| 238 | + |
| 239 | +# Next Steps |
| 240 | + |
| 241 | +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) |
| 242 | +## [Report Bugs](https://github.com/validatedpatterns-sandbox/federated-edge-observability/issues) |
0 commit comments