fixes

Author: nexus-Six

content/14-advanced-pipeline/_index.md

@@ -98,6 +98,10 @@ ACS is now able to detect and enforce the vulnerability. It is time now to imple
 
 ### Let's go: Create our advanced Pipeline
 
+Our current pipeline is quite simple. In production you will have more complex flows with conditionals and parallel execution. To learn more abou these have a look a the [Tekton Documentation]{https://tekton.dev/docs/}.
+
+To make it bit easier we have prepared a pipeline for you. But do take the time to look at the genera flow and tasks.
+
 In the **OpenShift Web Console**:
 
 - Make sure you are in the `workshop-int` Project

content/2-prepare-cluster/_index.md

@@ -60,6 +60,8 @@ In the cloned repository you'll find a `devfile.yml`. We will need the URL to th
 
 ## Install and Prepare CodeReady Workspaces (CRW)
 
+**Codeready Workspaces** is a browser-based IDE for Cloud Native Development. All the heavy lifting is done though a container running your workpsace on OpenShift. All you really need is a laptop. You can easily switch and setup customized environment, plugin, build tools and runtimes. So switching from one project context to another is as easy a switching a website. No more endless installation and configuration marathons on your dev laptop. It is already part your OpenShift subscription. If you want to find out more have a look [here]{https://www.redhat.com/en/technologies/jboss-middleware/codeready-workspaces}
+
 - Install the **Red Hat CodeReady Workspaces for Devfile v1 and v2** Operator from OperatorHub (not the Tech Preview one!) with default settings
 - Go to **Installed Operators -> CodeReady Workspaces** and create a new instance (**CodeReady Workspaces instance Specification**) using the default settings in the project `openshift-workspaces`
 - Wait until deployment has finished. This may take a couple of minutes as several components will be deployed.
@@ -73,7 +75,7 @@ We could create a workspace from one of the templates that come with CodeReady W
 {{% /notice %}}
 
 - At the top click on **Custom Workspace**
-- Copy the **raw**(!) URL of the `devfile.yml` file in your `Gitea` repository by clicking on the file and then on the **Raw** button (or **Originalversion** in German).
+- Copy the **raw**(Klick in the **Raw** Button) URL of the `devfile.yml` file in your `Gitea` repository by clicking on the file and then on the **Raw** button (or **Originalversion** in German).
 - Paste the full URL into the **Enter devfile URL** field and click **Load Devfile**
   ![Gitea](../images/crw.png)
 - Once the content of the devfile is loaded click on **Create & Open** at the button

content/3-inner-loop/_index.md

@@ -11,10 +11,11 @@ In this part of the workshop you'll experience how modern software development u
 As an example you'll create a new Java application. You don't need to have prior experience programming in Java as this will be kept really simple.
 
 {{% notice tip %}}
-We will use a Java application based on the [Quarkus](https://quarkus.io/) stack. Quarkus enables you to create much smaller and faster containerized Java applications than ever before.  You can even transcompile these apps to native Linux binaries that start blazingly fast.  The app that we will use is just a starter sample created with the [Quarkus Generator](https://code.quarkus.io/) with a simple RESTful API that answers to http Requests. But at the end of the day this setup will work with any Java application. **Fun fact:** Every OpenShift Subscription already comes with a Quarkus Subscription.      
+We will use a Java application based on the [Quarkus](https://quarkus.io/) stack. Quarkus enables you to create much smaller and faster containerized Java applications than ever before. You can even transcompile these apps to native Linux binaries that start blazingly fast. The app that we will use is just a starter sample created with the [Quarkus Generator](https://code.quarkus.io/) with a simple RESTful API that answers to http Requests. But at the end of the day this setup will work with any Java application. **Fun fact:** Every OpenShift Subscription already comes with a Quarkus Subscription.  
 {{% /notice %}}
 
 Let's clone our project into our workspace :
+
 - Bring up your `CodeReady Workspaces` in your browser
 - In the bottom left click on **Clone Repository** and then enter the `Git URL` to your `Gitea` Repo (You can copy the URL by clicking on the clipboard icon)
 - Press enter and select the default location.
@@ -23,6 +24,8 @@ You should be greeted by the `README.md` file.
 
 ## Install odo
 
+**odo** or 'OpenShift do' is a cli that enables developers to get started quickly with cloud native app development without being a Kubernetes expert. It offers support for multiple runtimes and you can easily setup microservice components, push code changes into running containers and debug remotely with just a few simple commands. To find out more, have look [here]{https://odo.dev/}
+
 To install the `odo` cli into your workspace, run the following steps:
 
 - From the CRW shortcuts menu to the right (the "cube icon") run `install odo`
@@ -41,38 +44,45 @@ Now we want to create a new OpenShift project for our app:
   - In **My Workspace** (cube icon) to the right click `New Terminal`
 - Copy the `oc login` command from your OpenShift cluster (At the top right **Username > Copy login command**) and execute in the `terminal` to log into the OpenShift cluster
 - Create a new project `workshop-dev`
+
 ```
 oc new-project workshop-dev
 ```
 
 ## Use odo to Deploy and Update our Application
 
 First use `odo` ("OpenShift Do") to list the programming languages/frameworks it supports
+
 ```
 ./odo catalog list components
 ```
+
 Now initialize a new Quarkus application
+
 ```
 ./odo create java-quarkus
 ```
-Make the app accessible via http (create a Route)
-```
-./odo url create workshop-app
-```
+
 And finally push the app to OpenShift
+
 ```
 ./odo push
 ```
+
 To test the app:
+
 - In OpenShift open the `workshop-dev` project and switch to the **Developer Console**
 - Open the **Topology** view and click on the top right link of Application icon to display the website of the app
 - Your app should show up as a simple web page. In the `RESTEasy JAX-RS` section click the `@Path` endpoint `/hello` to see the result.
 
 Now for the fun part: Using `odo` you can just dynamically change your code and push it out again without doing a new image build! No dev magic involved:
+
 - In your CRW Workspace on the left, expand the file tree to open file `src/main/java/org/acme/GreetingRessource.java` and change the string "Hello RESTEasy" to "Hello Workshop" (CRW saves every edit directly. No need to save)
 - Push the code to OpenShift again
+
 ```
 ./odo push
 ```
+
 - And reload the app webpage.
-- Bam! The change should be there in a matter of seconds  
+- Bam! The change should be there in a matter of seconds

content/5-gitops/_index.md

@@ -3,26 +3,27 @@ title = "Configure GitOps"
 weight = 10
 +++
 
-Now that our CI/CD build and integration stage is ready we could promote the app version directly to a production stage.  But with the help of the GitOps approach, we can leverage our Git System to handle promotion that is tracked through commits and can deploy and configure the whole production environment.  This stage is just too critical to configure manually and without audit.
+Now that our CI/CD build and integration stage is ready we could promote the app version directly to a production stage. But with the help of the GitOps approach, we can leverage our Git System to handle promotion that is tracked through commits and can deploy and configure the whole production environment. This stage is just too critical to configure manually and without audit.
 
-## Install OpenShift GitOps 
+## Install OpenShift GitOps
 
-So let's start be installing the OpenShift GitOps Operator based on project ArgoCD. 
+So let's start be installing the OpenShift GitOps Operator based on project ArgoCD.
 
 - Install the **Red Hat OpenShift GitOps** Operator from OperatorHub with default settings
-{{% notice tip %}}
-The installation of the GitOps Operator will give you a clusterwide ArgoCD instance available at the link in the top right menu, but since we want to have an instance to manage just our prod namespaces we will create another ArgoCD in that specific namespace.    
-{{% /notice %}}
+  {{% notice tip %}}
+  The installation of the GitOps Operator will give you a clusterwide ArgoCD instance available at the link in the top right menu, but since we want to have an instance to manage just our prod namespaces we will create another ArgoCD in that specific namespace.  
+  {{% /notice %}}
 - Create a new OpenShift Project `workshop-prod`
 - Then in the project `workshop-prod` click on **Installed Operators** and then **Red Hat OpenShift GitOps**.
 - On the **ArgoCD** "tile" click on **Create instance** to create an ArgoCD instance in the `workshop-prod` project.
 
 <!-- ![ArgoCD](../images/argo.png) -->
+
 {{< figure src="../images/argo.png?width=50pc&classes=border,shadow" title="Click image to enlarge" >}}
 
-- Keep the settings as they are and click **Create**  
+- Keep the settings as they are and click **Create**
 
-## Prepare the GitOps Config Repository 
+## Prepare the GitOps Config Repository
 
 - In `Gitea` create a **New Migration** and clone the Config GitOps Repo which will be the repository that contains our GitOps infrastructure components and state
 - The URL is https://github.com/devsecops-workshop/openshift-gitops-getting-started.git
@@ -33,21 +34,25 @@ Have quick look at the structure of this project :
 
 **environments/dev** - contains the `kustomization.yaml` which will be modified by our builds with new Image versions. ArgoCD will pick up these changes and trigger new deployments.
 
-
 ## Setup GitOps Project
 
-Let's setup the project that tells ArgoCD to watch our config repo and updated resources in the `workshop-prod` project accordingly. 
+Let's setup the project that tells ArgoCD to watch our config repo and updated resources in the `workshop-prod` project accordingly.
 
 - Give namespace `workshop-prod` permissions to pull images from `workshop-int`
+
 ```
 oc policy add-role-to-user \
     system:image-puller system:serviceaccount:workshop-prod:default \
     --namespace=workshop-int
 ```
+
 - Find the local **ArgoCD URL** by going to **Networking > Routes** in namespace `workshop-prod`
 - Open the ArgoCD website ignoring the certificate warning
 - Don't login with OpenShift but with username and password
 - User is `admin` and password will be in Secret `argocd-cluster`
+
+ArgoCD works with the concept of **Apps**. We will create an App and point it to the Config Git Repo. ArgoCD will look for k8s yaml files in the repo and path and deploy them to the defined namespace. Additionally ArgoCD will also react to changes to the repo and reflect these to the namespace. You can also enable self-healing to prevent configuration drift. If you want find out more about OpenShift GitOps have look [here]{https://docs.openshift.com/container-platform/4.10/cicd/gitops/understanding-openshift-gitops.html} :
+
 - Create App
   - Click the **Manage your applications** icon on the left
   - Click **Create Application**
@@ -59,13 +64,14 @@ oc policy add-role-to-user \
   - **Cluster URL**: https://kubernetes.default.svc
   - **Namespace**: workshop-prod
   - Click **Create**
-  - Click on **Sync** and then  **Synchronize** to manually trigger the first sync
+  - Click on **Sync** and then **Synchronize** to manually trigger the first sync
+  - Click on the `workshop` to show the deployment graph
 
-Watch the resources (`Deployment`, `Service`, `Route`) get rolled out to the namespace `workshop-prod`. Notice we have also scaled our app to 2 pods in the prod stage as we want some HA. 
+Watch the resources (`Deployment`, `Service`, `Route`) get rolled out to the namespace `workshop-prod`. Notice we have also scaled our app to 2 pods in the prod stage as we want some HA.
 
-Our complete prod stage is now configured and controlled though GitOps. But how do we tell ArgoCD that there is a new version of our app to deploy? Well, we will add a step to our build pipeline updating the config repo. 
+Our complete prod stage is now configured and controlled though GitOps. But how do we tell ArgoCD that there is a new version of our app to deploy? Well, we will add a step to our build pipeline updating the config repo.
 
-As we do not want to modify our original repo file we will use a tool called [Kustomize](https://kustomize.io/) that can add incremental change layers to YAML files. Since ArgoCD permanently watches this repo it will pick up these Kustomize changes.  
+As we do not want to modify our original repo file we will use a tool called [Kustomize](https://kustomize.io/) that can add incremental change layers to YAML files. Since ArgoCD permanently watches this repo it will pick up these Kustomize changes.
 
 {{% notice tip %}}
 It is also possible to update the repo with a Pull request. Then you have an approval process for your prod deployment.
@@ -77,6 +83,7 @@ Let's add a new custom Tekton task that can update the Image `tag` via Kustomize
 
 - In the namespace `workshop-int` switch to the **Administrator** Perspective and go to **Pipelines > Tasks > Create Task**
 - Replace the YAML definition with the following and click **Create**:
+
 ```yaml
 apiVersion: tekton.dev/v1beta1
 kind: Task
@@ -87,7 +94,7 @@ metadata:
   name: git-update-deployment
   namespace: workshop-int
   labels:
-    app.kubernetes.io/version: '0.1'
+    app.kubernetes.io/version: "0.1"
     operator.tekton.dev/provider-type: community
 spec:
   description: This Task can be used to update image digest in a Git repo using kustomize
@@ -110,14 +117,14 @@ spec:
     - description: The commit SHA
       name: commit
   steps:
-    - image: 'docker.io/alpine/git:v2.26.2'
+    - image: "docker.io/alpine/git:v2.26.2"
       name: git-clone
       resources: {}
       script: |
         rm -rf git-update-digest-workdir
         git clone $(params.GIT_REPOSITORY) git-update-digest-workdir
       workingDir: $(workspaces.workspace.path)
-    - image: 'quay.io/wpernath/kustomize-ubi:latest'
+    - image: "quay.io/wpernath/kustomize-ubi:latest"
       name: update-digest
       resources: {}
       script: >
@@ -159,7 +166,7 @@ spec:
 
         cat kustomization.yaml
       workingDir: $(workspaces.workspace.path)
-    - image: 'docker.io/alpine/git:v2.26.2'
+    - image: "docker.io/alpine/git:v2.26.2"
       name: git-commit
       resources: {}
       script: >
@@ -225,19 +232,19 @@ spec:
   workspaces:
     - description: The workspace consisting of maven project.
       name: workspace
-
 ```
 
 ## Add Tekton Task to Your Pipeline
 
 - Go to **Pipeline > Pipelines > workshop** and then YAML
 
 {{% notice tip %}}
-You can edit pipelines either directly in YAML or in the visual **Pipeline Builder**. We will see how to use the Builder later on so let's edit the YAML for now. 
+You can edit pipelines either directly in YAML or in the visual **Pipeline Builder**. We will see how to use the Builder later on so let's edit the YAML for now.
 {{% /notice %}}
- 
+
 Add the new Task to your Pipeline by adding it to the YAML like this:
-- In the YAML view insert it at the **tasks** level after the `deploy` task 
+
+- In the YAML view insert it at the **tasks** level after the `deploy` task
 - For the `param` `GIT_REPOSITORY` use your git config repo url (eg. replace {YOUR DOMAIN})
 - Make sure to fix indentation after pasting into the YAML!
 
@@ -275,45 +282,47 @@ In the OpenShift YAML viewer/editor you can mark multiple lines and use **tab**
          workspace: workspace
 
 ```
+
 The `Pipeline` should now look like this
 
 <!-- ![workshop Pipeline](../images/tekton.png) -->
-{{< figure src="../images/tekton.png?width=50pc&classes=border,shadow" title="Click image to enlarge" >}}
+
+{{< figure src="../images/pipeline1.png?width=50pc&classes=border,shadow" title="Click image to enlarge" >}}
 
 - Create a secret with credentials for your `Gitea` repository, so the `task` can authenticate and push to `Gitea`. Replace {YOUR DOMAIN} here to match your `Gitea`URL
 - You can add this by clicking on the **+** on the top right ob the Web Console
+
 ```yaml
 kind: Secret
 apiVersion: v1
 metadata:
   name: gitea
   namespace: workshop-int
   annotations:
-    tekton.dev/git-0: 'https://repository-git.apps.{YOUR DOMAIN}'
+    tekton.dev/git-0: "https://repository-git.apps.{YOUR DOMAIN}"
 data:
   password: Z2l0ZWE=
   username: Z2l0ZWE=
 type: kubernetes.io/basic-auth
 ```
-Now we need to add the secret to the `serviceaccount` that runs our pipelines so the `task` can push to our config repo. 
+
+Now we need to add the secret to the `serviceaccount` that runs our pipelines so the `task` can push to our config repo.
 
 - Go to **User Management > ServiceAccounts > pipeline**
 - To make the secret available during a pipeline run: Open the YAML and in the `secrets` section add:
 
 ```yaml
-  - name: gitea
+- name: gitea
 ```
+
 - Save and ignore the warning
 
 ## Update our Prod Stage via Pipeline and GitOps
 
 - Run the pipeline and see that in your Gitea repo `/environment/dev/kustomize.yaml` is updated with the new image version
-{{% notice tip %}}
-Notice that the `deploy` and the `git-update` steps now run in parallel. This is one of the powers of Tekton. It can scale natively with pods on OpenShift.    
-{{% /notice %}}
- 
+  {{% notice tip %}}
+  Notice that the `deploy` and the `git-update` steps now run in parallel. This is one of the powers of Tekton. It can scale natively with pods on OpenShift.  
+  {{% /notice %}}
 
 - This will tell ArgoCD to update the `Deployment` with this new image version
 - Check that the new image is rolled out (you may need to sync manually in ArgoCD to speed things up)
-
-