Merge pull request #295 from burigolucas/minor-fixes

Minor fixes, re-wording

docs/1-the-manual-menace/1-the-basics.md

@@ -1,7 +1,7 @@
 ## 🐌 The Basics - CRW, OCP & Helm
 ## DevSpaces setup
 
-1. Login to your Red Hat OpenShift DevSpaces Editor. The link to this will be provided by your instructor.
+1. Login to your Red Hat OpenShift DevSpaces Editor. The link to this will be provided by your instructor. Note that several authentication providers might be enabled, if that is the case, check with the instructor which provider to use.
 
     ![devspaces](./images/devspaces.png)
 
@@ -19,7 +19,7 @@
     <span style="color:blue;"><a id=crw_dev_filelocation_4.11 href=""></a></span>
     </p>
 
-2. In your IDE (it may take some time to open ... ⏰☕️), open a new terminal by hitting the hamburger menu on top left then select `Terminal > New Terminal` from the menu.
+2. In your IDE (it may take some time to open ... ⏰☕️), open a new terminal by hitting the hamburger menu on top left and then selecting `Terminal > New Terminal` from the menu.
 
     ![new-terminal](./images/new-terminal.png)
 
@@ -106,13 +106,13 @@ Let's deploy a simple application using Helm.
 
     ![todolist](./images/todolist.png)
 
-4. You can overwrite the default <span style="color:blue;">[values](https://github.com/rht-labs/todolist/blob/master/chart/values.yaml)</span> in a chart from the command line. Let's upgrade our deployment to show this. We'll make a simple change to the values to scale up our app. By default, we only have 1 replica.
+4. You can overwrite the default <span style="color:blue;">[values](https://github.com/rht-labs/todolist/blob/master/chart/values.yaml)</span> in a chart from the command line. Let's upgrade our deployment to show this. We'll make a simple change to the values to scale up our app. By default, we only have one replica of our application.
 
     ```bash#test
     oc get pods -n ${TEAM_NAME}-ci-cd
     ```
 
-    By default, we only have one replica of our application. Let's use helm to set this to 5.
+    Let's use Helm to set the number of replicas to 5.
 
     ```bash#test
     helm upgrade my tl500/todolist --set replicas=5 --namespace ${TEAM_NAME}-ci-cd
@@ -154,6 +154,6 @@ Let's deploy a simple application using Helm.
     * `Chart.yaml` - is the manifest of the chart. It defines the name, version and dependencies for our chart.
     * `values.yaml` - is the sensible defaults for our chart to work, it contains the variables that are passed to the templates. We can overwrite these values on the command line.
     * `templates/*.yaml` - they are our k8s resources. 
-    * `_helpers.tpl` - is a collection of reusable variables an yaml snippets that are applied across all of the k8s resources uniformly for example, labels are defined in here and included on each k8s resource file as necessary.
+    * `_helpers.tpl` - is a collection of reusable variables and YAML snippets that are applied across all of the K8s resources uniformly for example, labels are defined in here and included on each K8s resource file as necessary.
 
 🪄🪄 Now, let's continue with even more exciting tools... !🪄🪄

docs/1-the-manual-menace/2-argocd.md

@@ -15,7 +15,7 @@ From ArgoCD's website, it is described as a tool that:
     to a specific version of manifests at a Git commit.
 </pre></div>
 
-When something is seen as not matching the required state in Git, an application becomes out of sync. Depending on how you have implemented your GitOps, ArgoCD can then resync the changes to apply whatever is in Git immediately or fire a warning to initiate some other workflow. In the world of Continuous Delivery as implemented by ArgoCD, Git is the single source of truth, so we should always apply the changes as seen there.
+When something is seen as not matching the desired state in Git, an application becomes out of sync. Depending on how you have implemented your GitOps, ArgoCD can then immediately resync the changes to apply whatever is in git or fire a warning to initiate some other workflow. In the world of Continuous Delivery as implemented by ArgoCD, Git is the single source of truth, so we should always apply the changes as seen there.
 
 ### ArgoCD Basic Install
 > ArgoCD is one of the most popular GitOps tools. It keeps the state of our OpenShift applications synchronized with our git repos. ArgoCD is a fancy-pants controller that reconciles what is stored in our git repo (desired state) against what is live in our cluster (actual state). We can configure ArgoCD to take actions based on these differences, such as auto sync the changes from git to the cluster or fire a notification to say things have gone out of whack.
@@ -65,7 +65,7 @@ When something is seen as not matching the required state in Git, an application
 
 2. Let's perform a basic install of ArgoCD. Using most of the defaults defined on the chart is sufficient for our use case.
 
-    We're are also going to configure ArgoCD to be allowed pull from our git repository using a secret 🔐.
+    We're are also going to configure ArgoCD to be allowed to pull from our git repository using a secret 🔐.
 
     Configure our ArgoCD instance with a secret in our <TEAM_NAME>-ci-cd namespace by creating a small bit of yaml 😋:
 
@@ -99,7 +99,7 @@ EOF
     ```
 
     <p class="tip">
-    ⛷️ <b>NOTE</b> ⛷️ - It's also worth noting we're allowing ArgoCD to run in a fairly permissive mode for these exercise, it can pull charts from anywhere. If you're interested in securing ArgoCD a bit more, checkout the <span style="color:blue;"><a href="/#/1-the-manual-menace/666-here-be-dragons?id=here-be-dragons">here-be-dragons</a></span> exercise at the end of this lab.
+    ⛷️ <b>NOTE</b> ⛷️ - It's also worth noting we're allowing ArgoCD to run in a fairly permissive mode for these exercises, it can pull charts from anywhere. If you're interested in securing ArgoCD a bit more, checkout the <span style="color:blue;"><a href="/#/1-the-manual-menace/666-here-be-dragons?id=here-be-dragons">here-be-dragons</a></span> exercise at the end of this lab.
     </p>
 
 3. If we check in OpenShift we should see the Operator pod coming to life and (eventually) the argocd-server, dex and other pods spin up. To do this, we are going to run a command with a 'watch' flag to continuousy monitor pod creation.
@@ -110,7 +110,7 @@ EOF
 
     ![argocd-pods](images/argocd-pods.png)
 
-    *You must do Control+C to break the 'watch' mode to continue to the next step. Once all your pods are running*
+    *You must do Control+C to break the 'watch' mode to continue to the next step once all your pods are running.*
 
 4. When all the pods are up and running, we can login to the UI of ArgoCD. Get the route and open it in a new browser tab.
 
@@ -126,7 +126,7 @@ EOF
 6. Select `Allow selected permissions` for the initial login.
 ![argocd-allow-permission](images/argocd-allow-permission.png)
 
-7. You just logged into ArgoCD 👏👏👏! Lets deploy a sample application through the UI. In fact, let's get ArgoCD to deploy the `todolist` app you manually deployed previously. On ArgoCD - click `CREATE APPLICATION`. You should see see an empty form. Let's fill it out by setting the following:
+7. You just logged into ArgoCD 👏👏👏! Lets deploy a sample application through the UI. In fact, let's get ArgoCD to deploy the `todolist` app you manually deployed previously. On ArgoCD - click `CREATE APPLICATION`. You should see an empty form. Let's fill it out by setting the following:
    * On the "GENERAL" box
       * Application Name: `our-todolist`
       * Project: `default`
@@ -157,4 +157,4 @@ EOF
     echo https://$(oc get route/our-todolist -n ${TEAM_NAME}-ci-cd --template='{{.spec.host}}')
     ```
 
-🪄🪄 Magic! You've now deployed ArgoCD and got it to manually deploy an application for you. Next up, we'll make ArgoCD do some *REAL* GitOps 🪄🪄
+🪄🪄 Magic! You've now deployed ArgoCD and manually got it to deploy an application for you. Next up, we'll make ArgoCD do some *REAL* GitOps 🪄🪄

docs/1-the-manual-menace/3-ubiquitous-journey.md

@@ -8,13 +8,13 @@ This repo is available on the Red Hat Labs GitHub organization – <span style="
 - **Traceable** - We can easily see where changes have occurred and most importantly trace exactly what git tag/commit is in which environment.
 - **Discoverable** - By making the source code easy to follow, with supporting and inline documentation, new team members can easily discover how application are built, tested and deployed.
 - **Auditable** - Git logs and history are the single source of truth for building our software. We can create compliance reports and easily enhance the toolset to support more advanced techniques such as code signing and attestations for all our pipeline steps if needed.
-- **Reusable** - Many parts of CICD are reusable. A good example are the reusable pipelines and tasks. Its not only the code however, solid foundational practices such as build once, tag and promote code through a lifecycle can be codified.
+- **Reusable** - Many parts of CICD are reusable. A good example are the reusable pipelines and tasks. It's not only the code however, solid foundational practices such as build once, tag and promote code through a lifecycle can be codified.
 - **Flexible** - Product teams often want to use both standard tools and be able to experiment with new ones. The *tool box* mentality helps a lot, so as a team you can work with the tools you are familiar with. We will see this in action with Jenkins and Tekton.
 
 All of these traits lead to one outcome - the ability to build and release quality code into multiple environments whenever we need to.
 
 ### Get GitLab Ready for GitOps
-> In this exercise we'll setup our git project to store our code and configuration. We will then connect ArgoCD (our gitOps controller) to this git repository to enable the GitOps workflow. Tooling will be shared by all members of your team, so do this exercise as a mob please!
+> In this exercise we'll setup our git project to store our code and configuration. We will then connect ArgoCD (our GitOps controller) to this git repository to enable the GitOps workflow. Tooling will be shared by all members of your team, so do this exercise as a mob please!
  
 1. Log into GitLab with your credentials. GitLab URL:
 
@@ -37,7 +37,7 @@ All of these traits lead to one outcome - the ability to build and release quali
 5. On the new view, use `tech-exercise` as Project Name, select **Internal** for Visibility level, then hit Create project. Make sure the project is in the group you created previously and not the username's.
 ![gitlab-new-project](images/gitlab-new-project-2.png)
 
-6. We are going to create a Gitlab Personal Access Token (PAT). The token is a more secure and reliable method for accessing Gitlab from our scripts later on. Note, that for reference's sake, you can also generate a PAT in Gitlab under User > Settings > Access Tokens in the Web UI. We use a helper script here to help automate that process. To generate the token, open a terminal if you have not got one open and run the following commands.
+6. We are going to create a Gitlab Personal Access Token (PAT). The token is a more secure and reliable method for accessing Gitlab from our scripts later on. Note, that for reference's sake, you can also generate a PAT in Gitlab under User > Settings > Access Tokens in the Web UI. We use a helper script here to help automate that process. To generate the token, open a terminal in the CodeReady Workspace if you have not got one open and run the following commands.
 
     Export your Gitlab username.
 
@@ -101,7 +101,7 @@ All of these traits lead to one outcome - the ability to build and release quali
 ### Deploy Ubiquitous Journey 🔥🦄
 > In this exercise, we'll create our first namespaces and tooling using a repeatable pattern - GitOps.
 
-1. The Ubiquitous Journey (🔥🦄) is just another Helm Chart with a pretty neat pattern built in to create App of Apps in ArgoCD. Let's get right into it - in the your IDE, Open the `values.yaml` file in the root of the project. Update it to reference the git repo you just created and your team name. This values file is the default ones for the chart and will be applied to all of the instances of this chart we create. The Chart's templates are not like the previous chart we used (`services`, `deployments` & `routes`) but an ArgoCD application definition, just like the one we manually created in the previous exercise when we deployed an app in the UI of ArgoCD.
+1. The Ubiquitous Journey (🔥🦄) is just another Helm Chart with a pretty neat pattern built in to create App of Apps in ArgoCD. Let's get right into it - in your IDE, Open the `values.yaml` file in the root of the project. Update it to reference the git repo you have just created and your team name. This values file contains the default values for the chart and will be applied to all of the instances of this chart we create. The chart's templates are not like the previous chart we used (`services`, `deployments` & `routes`) but an ArgoCD application definition, just like the one we manually created in the previous exercise when we deployed an app in the UI of ArgoCD.
 
     ```yaml
     source: "https://<GIT_SERVER>/<TEAM_NAME>/tech-exercise.git"
@@ -156,9 +156,7 @@ All of these traits lead to one outcome - the ability to build and release quali
     ⛷️ <b>NOTE</b> ⛷️ - Bootstrap step also provides the necessary rolebindings. That means now the other users in the same team can access <b><TEAM_NAME></b> environments.
   </p>
 
-4. In order for ArgoCD to sync the changes from our git repository, we need to provide access  to it. We'll deploy a secret to cluster, for now *not done as code* but in the next lab we'll add the secret as code and store it encrypted in Git. In your terminal
-
-    Add the Secret to the cluster:
+4. In order for ArgoCD to sync the changes from our git repository, we need to provide access  to it. We'll deploy a secret to cluster, for now *not done as code* but in the next lab we'll add the secret as code and store it encrypted in Git. In your terminal, add the Secret to the cluster:
 
     ```bash#test
     cat <<EOF | oc apply -n ${TEAM_NAME}-ci-cd -f -
@@ -197,4 +195,4 @@ EOF
     oc get pods -n ${TEAM_NAME}-ci-cd
     ```
 
-🪄🪄 Magic! You've now deployed an app of apps to scaffold our tooling and projects in a repeatable and auditable way (via git!). Next up, we'll make extend the Ubiquitous Journey with some more tooling 🪄🪄
+🪄🪄 Magic! You've now deployed an app of apps to scaffold our tooling and projects in a repeatable and auditable way (via git!). Next up, we'll extend the Ubiquitous Journey with some more tooling 🪄🪄

docs/1-the-manual-menace/4-extend-uj.md

@@ -1,5 +1,5 @@
 ## Extend UJ with a another tool, eg Nexus 
-Now, we have our projects, necessary rolebindings and Jenkins up and running. We also need a repository to manage and store our artifacts. Nexus is here to help! We can use Nexus helm chart to deploy it. And since this is GitOps, all we need to do is extend UJ! Because if it is not in Git, it's not REAL! ;)
+Now, we have our projects, necessary rolebindings and Jenkins up and running. We also need a repository to store and manage our artifacts. Nexus is here to help! We can use Nexus helm chart to deploy it. And since this is GitOps, all we need to do is extend UJ! Because if it is not in Git, it's not REAL! ;)
 
 <p class="warn">
     ⛷️ <b>NOTE</b> ⛷️ - If you switch to a different CodeReady Workspaces environment, please run below commands before going forward.
@@ -21,7 +21,7 @@ git pull
     echo https://$(oc get route argocd-server --template='{{ .spec.host }}'/api/webhook  -n ${TEAM_NAME}-ci-cd)
     ```
 
-2. Go to `tech-exercise` git repository on GitLab. From left panel, go to `Settings > Integrations` and add the URL you just copied from your terminal to enable the WebHook. Now whenever a change is made in Git, ArgoCD will instantly reconcile and apply the differences between the current state in the cluster and the desired state in git 🪄. Click `Add webhook`.
+2. Go to `tech-exercise` git repository on GitLab. From left panel, go to `Settings > Integrations` and add the URL you just copied from your terminal to enable the WebHook. Now, whenever a change is made in Git, ArgoCD will instantly reconcile and apply the differences between the current state in the cluster and the desired state in git 🪄. Click `Add webhook`.
 
     ![gitlab-argocd-webhook](images/gitlab-argocd-webhook.png)
 

docs/1-the-manual-menace/666-here-be-dragons.md

@@ -14,7 +14,7 @@ For the `todolist` application we deploy you can take a look at the file by brow
 
 ![images/helm-index.png](images/helm-index.png)
 
-This lists the versions and details that the helm repository contains. So when you `helm repo add` it adds the repo url to your operating system dependent config file. This from `man helm`:
+This lists the versions and details that the helm repository contains. So, when you `helm repo add`, it adds the repo url to your operating system dependent config file. This from `man helm`:
 
 ```bash
 | Operating System | Cache Path                | Configuration Path             | Data Path               |
@@ -26,7 +26,7 @@ This lists the versions and details that the helm repository contains. So when y
 
 In OpenShift you can create `HelmChartRepository` objects that populate the WebUI, read more about that <span style="color:blue;">[here](https://docs.openshift.com/container-platform/4.12/applications/working_with_helm_charts/configuring-custom-helm-chart-repositories.html).</span>
 
-When installing the helm chart into your namespace, the helm command line actually uploads your full chart, stores it in a secret that the Helm Controller in your OpenShift cluster can act upon.
+When installing the helm chart into your namespace, the helm command line actually uploads your full chart and stores it in a secret that the Helm Controller in your OpenShift cluster can act upon.
 
 <div class="highlight" style="background: #f7f7f7">
 <pre><code class="language-bash">

docs/1-the-manual-menace/README.md

@@ -1,7 +1,7 @@
 # Exercise 1 - The Manual Menace
 > A GitOps approach to perform and automate deployments.
 ## 👨‍🍳 Exercise Intro
-In this exercise, we will use GitOps to set up our working environment. We will set up Git projects, create `dev`, `test` and `stage` projects in OpenShift, and deploy tools like Jenkins and Nexus to enable CI/CD in the next exercise. In order to do that, we'll use a popular approach called _GitOps_
+In this exercise, we will use GitOps to set up our working environment. We will set up Git projects, create `dev`, `test` and `stage` projects in OpenShift, and deploy tools like Jenkins and Nexus to enable CI/CD in the next exercise. In order to do that, we'll use a popular approach called _GitOps_.
 
 ## 🖼️ Big Picture
 ![big-picture-tools](images/big-picture-tools.jpg)
@@ -13,6 +13,6 @@ In this exercise, we will use GitOps to set up our working environment. We will
 
 ## 🔨 Tools used in this exercise
 * <span style="color:blue;">[Helm](https://helm.sh/)</span> - Helps us to define, install, and upgrade Kubernetes application.
-* <span style="color:blue;">[ArgoCD](https://argoproj.github.io/argo-cd/)</span> - A controller which continuously monitors application and compare the current state against the desired
+* <span style="color:blue;">[ArgoCD](https://argoproj.github.io/argo-cd/)</span> - A controller which continuously monitors application and compare the current state against the desired state.
 * <span style="color:blue;">[Nexus](https://www.sonatype.com/nexus-repository-sonatype)</span> - Repository manager for storing lots of application types. Can also host `npm` and `Docker` registries.
 * <span style="color:blue;">[Jenkins](https://jenkins.io/)</span> - OpenSource Build automation server. Highly customisable with plugins.