Merge pull request #9 from RedHatGov/feature/service-mesh-v2

Update for Service Mesh v2 and RH SSO operator

.github/workflows/releasedcontainerimage.yaml

@@ -0,0 +1,25 @@
+# ./.github/workflows/releasedcontainerimage.yaml
+
+name: Released Container Image
+on:
+  release:
+    types: [published, released, edited]
+jobs:
+  build-and-push:
+    name: Build and push to quay.io
+    runs-on: ubuntu-latest 
+    steps:
+      - name: git checkout
+        uses: actions/checkout@v2
+      - name: Get the release version
+        id: get_version
+        run: echo ::set-output name=VERSION::${GITHUB_REF#refs/tags/}
+      - name: Build and push container images
+        uses: docker/build-push-action@v1
+        with:
+          username: ${{ secrets.DOCKER_USERNAME }}
+          password: ${{ secrets.DOCKER_PASSWORD }}
+          registry: quay.io
+          repository: redhatgov/service-mesh-workshop-dashboard
+          tags: ${{ steps.get_version.outputs.VERSION }}
+          add_git_labels: true

README.md

@@ -1,39 +1,45 @@
+![Released Container Image](https://github.com/RedHatGov/service-mesh-workshop-dashboard/workflows/Released%20Container%20Image/badge.svg)
+
 # OpenShift Service Mesh Workshop
 This content has been designed to work with an OpenShift Homeroom deployment. Considerations include:
 * Variable interpolation for user or cluster-specific variables in the lab guide content
 * Usage of cluster-internal URLs for accessing or testing services with `curl`
-* **Kiali** and **Jaeger** are built into the dashboard view for ease of use
-    * Because these windows are loaded in HTML iframes, they cannot support OAuth authentication flows. We workaround this by using token-auth in Kiali and no auth in Jaeger.  
 
-## Deploying this workshop
+The TL;DR of homeroom is that we build all these labs into a website, stuff that in a container, and deploy that container to the OpenShift cluster that the workshop attendees are using. This lets us show instructions side-by-side with the OpenShift webconsole and CLI terminal.
+
+## Deploying this workshop - if you have RHPDS
+We are working on getting this into a click-to-provision environment. It's not there yet, when it is this section will tell you how to order it.
+
+## Deploying this workshop - in your own cluster
 1. Complete [these steps](https://github.com/RedHatGov/service-mesh-workshop-code/tree/workshop-stable/deployment/workshop) **first**
-2. Adjust **Kiali** and **Jaeger** as indicated above, then restart **Kiali**
-```bash
-oc patch -n istio-system kiali kiali -p '{"spec":{"auth":{"strategy":"token"}}}' --type merge
-oc patch -n istio-system jaeger jaeger -p '{"spec":{"ingress":{"security":"none"}}}' --type merge
-oc rollout restart deployment kiali -n istio-system
-```
-3. Set a local `CLUSTER_SUBDOMAIN` environment variable
+
+2. Set a local `CLUSTER_SUBDOMAIN` environment variable
 ```bash
 CLUSTER_SUBDOMAIN=<apps.openshift.com>
 ```
-4. Create a project for the homeroom to live
+3. Create a project for the homeroom to live
 ```bash
 oc new-project homeroom --display-name="Homeroom Workshops"
 ```
-5. Grab the template to deploy a `workshop-spawner`. Note that the `CUSTOM_TAB_*` variables take the form `<tabLabel>=<url>` 
+5. Grab the template to deploy a `workshop-spawner`. Note the `WORKSHOP_IMAGE` tag should be changed with the corresponding release you want to deploy.
 ```
 oc process -f https://raw.githubusercontent.com/RedHatGov/workshop-spawner/develop/templates/hosted-workshop-production.json \
     -p SPAWNER_NAMESPACE=homeroom \
     -p CLUSTER_SUBDOMAIN=$CLUSTER_SUBDOMAIN \
     -p WORKSHOP_NAME=service-mesh-workshop \
     -p CONSOLE_IMAGE=quay.io/openshift/origin-console:4.5 \
-    -p WORKSHOP_IMAGE=quay.io/redhatgov/service-mesh-workshop-dashboard:latest \
-    -p CUSTOM_TAB_1=Kiali=https://kiali-istio-system.$CLUSTER_SUBDOMAIN \
-    -p CUSTOM_TAB_2=Jaeger=https://jaeger-istio-system.$CLUSTER_SUBDOMAIN \
+    -p WORKSHOP_IMAGE=quay.io/redhatgov/service-mesh-workshop-dashboard:x.x.x \
 | oc apply -n homeroom -f -
 ```
-6. Deploy a Username Distribution app for generating student IDs - this is especially handy for virtual workshops.
+
+### Access info for the workshop
+Your workshop attendees will need user accounts in the OpenShift cluster.
+
+Now give this URL (or preferably a shortened version) to your workshop attendees:
+>`echo https://service-mesh-workshop-homeroom.$CLUSTER_SUBDOMAIN`
+
+#### Optional
+Deploy a Username Distribution app for generating student IDs - this is especially handy for virtual workshops.
 ```bash
 NUM_USERS=<number of workshop users>
 
@@ -51,3 +57,7 @@ echo https://username-distribution-homeroom.$CLUSTER_SUBDOMAIN
 They'll need to enter a valid email address and the workshop password specified by the `LAB_USER_ACCESS_TOKEN` environment variable, for which the default is **redhatlabs**.
 
 You can perform administrative actions by visiting `/admin` in the `username-distribution` app. You'll need to enter `admin` as a username and the value of the `LAB_ADMIN_PASS` environment variable, for which the default is **pleasechangethis**, as a password.
+
+## Cleaning up after the workshop
+As long as no one else is running a homeroom workshop in the same cluster, you can clean up with the following:
+>`oc delete project homeroom`

workshop/content/lab1.1_welcome.md

@@ -19,5 +19,3 @@ The term service mesh describes the network of microservices that make up applic
 Based on the open source Istio project, Red Hat OpenShift Service Mesh adds a transparent layer on existing distributed applications without requiring any changes to the service code. You add Red Hat OpenShift Service Mesh support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices. You configure and manage the service mesh using the control plane features.
 
 Red Hat OpenShift Service Mesh provides an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provides more complex operational functionality, including A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.
-
-[1]: https://xxxx

workshop/content/lab1.2_installing.md

@@ -27,7 +27,7 @@ oc whoami
 ```
 *You can click the play button in the top right corner of the code block to automatically execute the command for you.*
 
-<br>
+You should see your username: %username%.
 
 The instructor will have preconfigured your projects for you.
 
@@ -39,7 +39,7 @@ The instructor will have preconfigured your projects for you.
 oc projects
 ```
 
-You should see two projects: your user project (e.g. '%username%') and 'istio-system'.  
+You should see two projects: your user project (e.g. '%username%') and '%username%-istio'.  
 
 <br>
 
@@ -66,25 +66,11 @@ oc get pods
 Output (sample):
 
 ```
-NAME                                       READY   STATUS    RESTARTS   AGE
-istio-demogateway-user1-xxxxxxxxxx-xxxxx   1/1     Running   0          2m41s
-keycloak-operator-xxxxxxxxx-xxxxx          1/1     Running   0          15h
+NAME                                    READY   STATUS    RESTARTS   AGE
+rhsso-operator-xxxxxxxxx-xxxxx          1/1     Running   0          15h
 ```
 
-The gateway is a load balancer dedicated to your project.  You will configure this load balancer in the next lab.  The keycloak operator will be used in the security labs.
-
-<br>
-
-Finally, set the project name variable.
-
-<blockquote>
-<i class="fa fa-terminal"></i>
-Run this command:
-</blockquote>
-
-```execute
-PROJECT_NAME=$(oc project -q)
-```
+The RH-SSO operator will be used later in the security labs.
 
 <br>
 
@@ -96,59 +82,45 @@ Next we need a local copy of our application code.
 </blockquote>
 
 ```execute
-git clone https://github.com/RedHatGov/openshift-microservices.git
+git clone https://github.com/RedHatGov/service-mesh-workshop-code.git
 ```
 
 <blockquote>
 <i class="fa fa-terminal"></i> Checkout the workshop-stable branch:
 </blockquote>
 
 ```execute
-cd openshift-microservices && git checkout workshop-stable
+cd service-mesh-workshop-code && git checkout workshop-stable
 ```
 
-<blockquote>
-<i class="fa fa-terminal"></i>
-Navigate to the workshop directory:
-</blockquote>
-
-```execute
-cd deployment/workshop
-```
-
-<br>
-
 ## Istio
-Istio should have been installed in the cluster by the instructor.  Let's make sure Istio is running in the cluster.  You will only have view access to the Istio project.
+Istio should have been installed in the cluster by the instructor.  Let's make sure it is running in the cluster.  
+
+The %username%-istio project is a service mesh dedicated to you.
 
 <blockquote>
-<i class="fa fa-terminal"></i>
-List all the Istio components:
+<i class="fa fa-terminal"></i> List the pods in the service mesh project:
 </blockquote>
 
 ```execute
-oc get pods -n istio-system
+oc get pods -n %username%-istio
 ```
 
 Output:
 
 ```
 NAME                                      READY   STATUS    RESTARTS   AGE
-grafana-xxxxxxxxx-xxxxx                  2/2     Running   0          17m
-istio-citadel-xxxxxxxxx-xxxxx            1/1     Running   0          20m
-istio-egressgateway-xxxxxxxx-xxxxx       1/1     Running   0          17m
-istio-galley-xxxxxxxx-xxxxx              1/1     Running   0          19m
-istio-ingressgateway-xxxxxxxxx-xxxxx     1/1     Running   0          17m
-istio-pilot-xxxxxxxxx-xxxxx              2/2     Running   0          18m
-istio-policy-xxxxxxxxx-xxxxx             2/2     Running   0          19m
-istio-sidecar-injector-xxxxxxxxx-xxxxx   1/1     Running   0          17m
-istio-telemetry-xxxxxxxxx-xxxxx          2/2     Running   0          19m
-jaeger-xxxxxxxxx-xxxxx                   2/2     Running   0          19m
-kiali-xxxxxxxxx-xxxxx                    1/1     Running   0          16m
-prometheus-xxxxxxxxx-xxxxx               2/2     Running   0          19m
+grafana-xxxxxxxxx-xxxxx                   2/2     Running   0          5h30m
+istio-egressgateway-xxxxxxxx-xxxxx        1/1     Running   0          5h30m
+istio-ingressgateway-xxxxxxxxx-xxxxx      1/1     Running   0          5h30m
+istio-telemetry-xxxxxxxxx-xxxxx           2/2     Running   0          5h25m
+istiod-workshop-install-xxxxxxxxx-xxxxx   1/1     Running   0          5m28s
+jaeger-xxxxxxxxxx-xxxxx                   2/2     Running   0          5h25m
+kiali-xxxxxxxxxx-xxxxx                    1/1     Running   0          5h25m
+prometheus-xxxxxxxxx-xxxxx                2/2     Running   0          5h30m
 ```
 
-The primary control plane components are [Pilot][1], [Mixer][2], and [Citadel][3].  Pilot handles traffic management.  Mixer handles policy and telemetry.  Citadel handles security.
+The primary control plane component is the Istio daemon `istiod`.  `istiod` handles [Traffic Management][1], [Telemetry][2], and [Security][3].  The `istio-ingressgateway` is a load balancer for your service mesh.  You will configure this with a microservices application in the next lab.
 
 [1]: https://istio.io/docs/concepts/traffic-management/
 [2]: https://istio.io/docs/concepts/observability/