Complete re-write of the workshop so it follows the Katacoda scenario

Author: joellord

.workshop/setup

@@ -7,4 +7,4 @@
 # the steps having already been run. This is because this script will be
 # run a second time if the container were restarted for some reason.
 
-envsubst < exercise/image-pipeline-resource.yaml.in > exercise/image-pipeline-resource.yaml
+envsubst < resources/image-pipeline-resource.yaml.in > resources/image-pipeline-resource.yaml

code/exercise/deploy-pipeline.yaml renamed to code/pipeline/deploy-pipeline.yaml

@@ -0,0 +1,75 @@
+OpenShift Pipelines is provided as an OpenShift add-on that can be installed via an operator that is available in the OpenShift OperatorHub.
+
+Operators may be installed into a single namespace and only monitor resources in that namespace, but the OpenShift Pipelines Operator installs globally on the cluster and monitors and manage pipelines for every single user in the cluster.
+
+To install the operator globally, you need to be a cluster administrator user. In this workshop environment, the operator has already been installed for you. Nevertheless, this is the process we followed in order to install the operator. **These instructions are for reference, as you will not be able to see these screens in the embedded console in the workshop due to your user's lack of the required privileges.**
+
+== Install process
+
+To install the OpenShift Pipelines operator on an OpenShift 4 cluster, you would go to the **Catalog > OperatorHub** tab in the OpenShift web console. You can see the list of available operators for OpenShift provided by Red Hat as well as a community of partners and open-source projects.
+
+Next, you would click on the **Integration & Delivery** category to find the **OpenShift Pipeline Operator** as shown below:
+
+image:images/operatorhub.png[OpenShift OperatorHub]
+
+Click on **OpenShift Pipelines Operator**, **Continue**, and then **Install** as shown below:
+
+image:images/operator-install-1.png[OpenShift Pipelines Operator]
+
+Leave the default values after clicking **Install**. The operator will install globally and it will run in the `openshift-operators` project, as this is the pre-configured project for all global operators. Click on **Subscribe** in order to subscribe to the installation and update channels as shown below:
+
+image:images/operator-install-2.png[OpenShift Pipelines Operator]
+
+The operator is installed when you see the status updated from `1 installing` to `1 installed` as shown in the photo below:
+
+image:images/operator-install-3.png[OpenShift Pipelines Operator]
+
+This operator automates installation and updates of OpenShift Pipelines on the cluster as well as applying all configurations needed.
+
+== Verify installation
+
+The OpenShift Pipelines Operator provides all its resources under a single API group: tekton.dev. You can see the new resources by running: 
+
+[source,bash,role=execute]
+----
+oc api-resources --api-group=tekton.dev
+----
+
+=== Verify user roles
+
+To validate that your user has the appropriate roles, you can use the `oc auth can-i` command to see whether you can create Kubernetes custom resources of the kind needed by the OpenShift Pipelines Operator.
+
+The custom resource you need to create an OpenShift Pipelines pipeline is a resource of the kind pipeline.tekton.dev in the tekton.dev API group. To check that you can create this, run:
+
+[source,bash,role=execute]
+----
+oc auth can-i create pipeline.tekton.dev
+----
+
+Or you can use the simplified version:
+
+[source,bash,role=execute]
+----
+oc auth can-i create Pipeline
+----
+
+When run, if the response is yes, you have the appropriate access.
+
+Verify that you can create the rest of the Tekton custom resources needed for this workshop by running the commands below. All of the commands should respond with yes.
+
+[source,bash,role=execute]
+----
+oc auth can-i create Task
+----
+
+[source,bash,role=execute]
+----
+oc auth can-i create PipelineResource
+----
+
+[source,bash,role=execute]
+----
+oc auth can-i create PipelineRun
+----
+
+Now that we have verified that you can create the required resources let's start the workshop.

code/exercise/git-pipeline-resource.yaml renamed to code/resources/git-pipeline-resource.yaml

@@ -0,0 +1,20 @@
+In this workshop, the pipeline you create uses tools such as https://github.com/openshift/source-to-image[s2i] and https://buildah.io/[Buildah] to create a container image for an application and build the image.
+
+Building container images using build tools (such as s2i, Buildah and Kaniko) require privileged access to the cluster. OpenShift default security settings do not allow access to privileged containers unless correctly configured.
+
+This operator has created a `ServiceAccount` with the required permissions to run privileged pods for building images. The name of this service account is easy to remember. It is named _pipeline_.
+
+You can verify that the pipeline has been created by running the following command:
+
+[source,bash,role=execute]
+----
+oc get serviceaccount pipeline
+----
+
+In addition to privileged security context constraints (SCC), the _pipeline_ service account also has the edit role. This set of permissions allows _pipeline_ to push a container image to OpenShift's internal image registry.
+
+_pipeline_ is only able to push to a section of OpenShift's internal image registry that corresponds to your OpenShift project namespace. This namespacing helps to separate projects on an OpenShift cluster.
+
+The pipeline service account executes PipelineRuns on your behalf. You can see an explicit reference for a service account when you trigger a pipeline run later in this workshop.
+
+In the next section, you will set up the sample application on OpenShift that is deployed in this workshop.

code/exercise/image-pipeline-resource.yaml.in renamed to code/resources/image-pipeline-resource.yaml.in

@@ -0,0 +1,68 @@
+For this tutorial, you're going to use a simple Node.js application that interacts with a MongoDB database. This application needs to deploy in a new project (i.e. Kubernetes namespace). This project was already created for you and you can see which project you are currently in by using:
+
+[source,bash,role=execute]
+----
+oc project
+----
+
+For this tutorial, you will deploy the _nodejs-ex_ sample application from the https://github.com/sclorg[sclorg] repository.
+
+To prepare for _nodejs-ex _'s eventual deployment, you create Kubernetes objects that are supplementary to the application, such as a route (i.e. URL). The deployment will not complete since there are no container images built for the _nodejs-ex_ application yet. You will complete this deployment in the following sections through a CI/CD pipeline.
+
+Create the supplementary Kubernetes objects by running the command below:
+
+[source,bash,role=execute]
+----
+oc create -f sampleapp/sampleapp.yaml
+----
+
+_nodejs-ex_ also needs a MongoDB database. You can deploy a container with MongoDB to your OpenShift project by running the following command:
+
+[source,bash,role=execute]
+----
+oc new-app centos/mongodb-36-centos7 -e MONGODB_USER=admin MONGODB_DATABASE=mongodb MONGODB_PASSWORD=secret MONGODB_ADMIN_PASSWORD=super-secret
+----
+
+You should see `--> Success` in the output of the command, which verifies the successful deployment of the container image.
+
+The command above uses a container image with a CentOS 7 operating system and MongoDB 3.6 installed. It also sets environment variables using the -e option. MongoDB needs these environment variables for its deployment, such as the username, database name, password, and the admin password.
+
+A service is an abstract way to expose an application running on a set of pods as a network service. Using a service name allows _nodejs-ex_ to reference a consistent endpoint in the event the pod hosting your MongoDB container is updated from events such as scaling pods up or down or redeploying your MongoDB container image with updates.
+
+You can see all the services, including the one for _nodejs-ex_ in your OpenShift project by running the following command:
+
+[source,bash,role=execute]
+----
+oc get services
+----
+
+Now that you are familiar with Kubernetes services go ahead and connect _nodejs-ex_ to the MongoDB. To do this, set the connection string in an environment variable by running the following command:
+
+[source,bash,role=execute]
+----
+oc set env dc/nodejs-ex MONGO_URL="mongodb://admin:secret@mongodb-36-centos7:27017/mongodb"
+----
+
+== Verify the deployment
+
+To verify the creation of the resources needed to support _nodejs-ex_ and the MongoDB, you can head out to the OpenShift web console.
+
+You can make your way to the web console by clicking on the Console tab next to the Terminal tab at the center top of the workshop in your browser.
+
+You need to log in with username `admin` and password `admin`.
+
+Make sure the Developer option from the dropdown in the top left corner of the web console is selected as shown below:
+
+image:images/developer-view.png[Developer View]
+
+Next, select the Project dropdown menu shown below and choose the project namespace you have been working with (_lab-tekton_).
+
+Next, click on the Topology tab on the left side of the web console if you don't see what's in the image below. Once in the Topology view, you can see the deployment config for the _nodejs-ex_ application and the MongoDB, which should look similar to the image below:
+
+image:images/topology-view.png[Topology View]
+
+You'll notice the white circle around the _nodejs-ex_ deployment config. This highlight means that the _nodejs-ex_ application isn't running yet. More specifically, no container hosting the _nodejs-ex_ application has been created, built, and deployed yet.
+
+The _mongodb-36-centos7_ deployment config has a dark blue circle around it, meaning that a pod is running with a MongoDB container on it. The MongoDB should be all set to support the _nodejs-ex_ application at this point.
+
+In the next section, you'll learn how to use Tekton tasks.

workshop/content/01install-op.adoc

@@ -0,0 +1,148 @@
+`Tasks` consist of some steps that get executed sequentially. Each step gets executed in a separate container within the same task pod. They can have inputs and outputs to interact with other `Tasks` as part of a pipeline.
+
+For this exercise, you will create the _s2i-nodejs_ task from the catalogue repositories using oc. This is the first of two tasks you add to your pipeline for this workshop.
+
+The _s2i-nodejs_ task has been broken into pieces below to help highlight its key aspects.
+
+_s2i-nodejs_ starts by defining a property called inputs, as shown below. Underneath inputs, a property called resources specify that a resource of type _git_ is required. This property indicates that this task takes a git repository as an input.
+
+[source,yaml]
+----
+spec:
+  inputs:
+    resources:
+      - name: source
+        type: git
+----
+
+The params property below defines fields that must be specified when using the task (e.g. the version of Node.js to use).
+
+[source,yaml]
+----
+    params:
+      - name: VERSION
+        description: The version of the nodejs
+        default: '12'
+      - name: PATH_CONTEXT
+        description: The location of the path to run s2i from.
+        default: .
+      - name: TLSVERIFY
+        description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
+        default: "true"
+----
+
+There is also an _outputs_ property shown below that is used to specify that something is output as a result of running this task. The type of output is _image_. This property specifies that this task creates an image from the git repository provided as an input.
+
+Many resource types are possible and not only limited to git and image. You can find out more about the possible resource types in the https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#resource-types[Tekton documentation].
+
+[source,yaml]
+----
+  outputs:
+    resources:
+      - name: image
+        type: image
+----
+
+For each step of the task, a steps property is used to define what steps will run during this task. Each step is denoted by its name. _s2i-nodejs_ has three steps:
+
+generate
+
+[source,yaml]
+----
+    - name: generate
+      image: quay.io/openshift-pipeline/s2i
+      workingdir: /workspace/source
+      command: ['s2i', 'build', '$(inputs.params.PATH_CONTEXT)', 'centos/nodejs-$(inputs.params.VERSION)-centos7', '--as-dockerfile', '/gen-source/Dockerfile.gen']
+      volumeMounts:
+        - name: gen-source
+          mountPath: /gen-source
+      resources:
+        limits:
+          cpu: 500m
+          memory: 1Gi
+        requests:
+          cpu: 500m
+          memory: 1Gi
+----
+
+build
+
+[source,yaml]
+----
+    - name: build
+      image: quay.io/buildah/stable
+      workingdir: /gen-source
+      command: ['buildah', 'bud', '--tls-verify=$(inputs.params.TLSVERIFY)', '--layers', '-f', '/gen-source/Dockerfile.gen', '-t', '$(outputs.resources.image.url)', '.']
+      volumeMounts:
+        - name: varlibcontainers
+          mountPath: /var/lib/containers
+        - name: gen-source
+          mountPath: /gen-source
+      resources:
+        limits:
+          cpu: 500m
+          memory: 1Gi
+        requests:
+          cpu: 500m
+          memory: 1Gi
+      securityContext:
+        privileged: true
+----
+
+push
+
+[source,yaml]
+----
+    - name: push
+      image: quay.io/buildah/stable
+      command: ['buildah', 'push', '--tls-verify=$(inputs.params.TLSVERIFY)', '$(outputs.resources.image.url)', 'docker://$(outputs.resources.image.url)']
+      volumeMounts:
+        - name: varlibcontainers
+          mountPath: /var/lib/containers
+      resources:
+        limits:
+          cpu: 500m
+          memory: 1Gi
+        requests:
+          cpu: 500m
+          memory: 1Gi
+      securityContext:
+        privileged: true
+----
+
+Each step above runs serially in its own container. Since the generate step uses an s2i command to generate a Dockerfile from the source code from the git repository input, the image used for its container has s2i installed.
+
+The build and push steps both use a Buildah image to run commands to build the Dockerfile created by the generate step and then push that image to an image registry (i.e. the output of the task).
+
+You can see the images used for both these steps via the image property of each step.
+
+The order of the steps above (i.e. 1. generate 2. build 3. push) is used to specify when these steps should run. For _s2i-nodejs_, this means _generate_ will run followed by build and then the push step will execute last.
+
+Under the resources property of each step, you can define the amount of resources needed for the container in terms of CPU and memory.
+
+[source,yaml]
+----
+resources:
+limits:
+    cpu: 500m
+    memory: 1Gi
+requests:
+    cpu: 500m
+    memory: 1Gi
+----
+
+You can view the full definition of this task in the https://github.com/openshift/pipelines-catalog/blob/master/s2i-nodejs/s2i-nodejs-task.yaml[OpenShift Pipelines Catalog GitHub repository] or by using:
+
+[source,bash,role=execute]
+----
+cat ./tektontasks/s2i-nodejs-task.yaml
+----
+
+Create the _s2i-nodejs_ task that defines and builds a container image for the _nodejs-ex_ application and push the resulting image to an image registry:
+
+[source,bash,role=execute]
+----
+oc create -f tektontasks/s2i-nodejs-task.yaml
+----
+
+In the next section, you will examine the second task definitions that will be needed for our pipeline.

workshop/content/02serviceaccount.adoc

@@ -0,0 +1,52 @@
+The openshift-client task you will create is simpler as shown below:
+
+[source,yaml]
+----
+apiVersion: tekton.dev/v1alpha1
+kind: Task
+metadata:
+  name: openshift-client
+spec:
+  inputs:
+    params:
+      - name: ARGS
+        description: The OpenShift CLI arguments to run
+        default: help
+  steps:
+    - name: oc
+      image: quay.io/openshiftlabs/openshift-cli-tekton-workshop:2.0
+      command: ["/usr/local/bin/oc"]
+      args:
+        - "$(inputs.params.ARGS)"
+----
+
+_openshift-client_ doesn't have any inputs or outputs associated with it. It also only has one step named oc.
+
+This step uses an image with oc installed and runs the oc root command along with any args passed to the step under the args property. This task allows you to run any command with oc. You will use it to deploy the image created by the _s2i-nodejs_ task to OpenShift. You will see how this takes place in the next section.
+
+Create the _openshift-client_ task that will deploy the image created by _s2i-nodejs_ as a container on OpenShift:
+
+[source,bash,role=execute]
+----
+oc create -f tektontasks/openshift-client-task.yaml
+----
+
+*Note*: For convenience, the tasks have been copied from their original locations in the Tekton and OpenShift catalogue git repositories to the workshop.
+
+You can take a look at the list of tasks using the Tekton CLI (tkn):
+
+[source,bash,role=execute]
+----
+tkn task ls
+----
+
+You should see similar output to this:
+
+[source,bash]
+----
+NAME               AGE
+openshift-client   58 seconds ago
+s2i-nodejs         3 minutes ago
+----
+
+In the next section, you will create a pipeline that uses _s2i-nodejs_ and _openshift-client_ tasks.