This repository contains the content for a Homeroom-based workshop that provides several exercises exploring Red Hat OpenShift Service Mesh (RHOSSM).
More information about Homeroom can be found here.
Contributions are most welcome. Please feel free to file issues.
When submitting pull requests, make sure to submit them against the develop
branch. Once merged, those changes will automatically be built into a new
image that lands on Quay.io: https://quay.io/repository/thoraxe/lab-ossm
This repository is cloned as part of a provisioning process associated with the Red Hat Product Demo System (RHPDS). As such, specific tags of this repository will always be fetched such that RHPDS can lock to a point-in-time of the repository. A normal versioning scheme that roughly aligns with the Service Mesh version should be used.
The container image on Quay.io will be built continually for both the
master
and develop
branches, resulting in image tags of latest
,
master
, and develop
.
A manual tag for production
should be created when an update to what RHPDS
deploys is desired. The tag for production
should point at the image built
from whatever code repository tag is being deployed by RHPDS.
Example workflow:
develop
develop
and latest
develop
to master
master
and latest
master
code repository with a version eg: 1.0.3master
image in Quay.io with production
and 1.0.3
1.0.3
Deploying this experience to your own cluster is not particularly difficult. You will need to understand the difference between the way the lab guide is written and the names you give your own resources in your own cluster.
We are using the prefix my-
for Project names. The lab guide will be using
your OpenShift username as the prefix. If you know your username is john
,
then you should use the prefix john-
when creating Projects. That being
said, you need cluster administrator access to install the operators.
However, you cannot use the lab guide as kubeadmin
. The kubeadmin
user is an alias for kube:admin
, and the colon causes the lab guide to
attempt to use a serviceaccount with a colon, which is invalid, and breaks
the lab guide.
If you don't already have real users in your cluster, you can use an htpasswd identity provider to create users easily and quickly.
There are three main steps to getting the lab going in your cluster.
my-smcp
where the Service Mesh control plane will be installed.my-smcp
project (not istio-system
).my-tutorial
.my-tutorial
) and to do so inside the my-smcp
project.Wait for the above steps to complete before continuing. You can track the progress of the Service Mesh control plane installation by looking at the control plane details (assuming defaults):
Installed Operators -> my-smcp
-> Red Hat OpenShift Service Mesh -> Istio Service Mesh Control Plane -> basic install
In the Conditions area, you will see that Installed, Reconciled, and Ready are all True once the installation is successful.
It will be easiest to do this from the command line. Note that the following
scriptlet assumes you have created a project called my-tutorial
:
oc create -n my-tutorial -f https://gist.githubusercontent.com/thoraxe/a189ade0d2dd19c8c275179b48577117/raw/02c4ea130cb6b1ebd83c7fd7a4cb2824fac179b7/curl.yaml
oc create -n my-tutorial -f https://gist.githubusercontent.com/thoraxe/a189ade0d2dd19c8c275179b48577117/raw/02c4ea130cb6b1ebd83c7fd7a4cb2824fac179b7/customer.yaml
oc create -n my-tutorial -f https://gist.githubusercontent.com/thoraxe/a189ade0d2dd19c8c275179b48577117/raw/02c4ea130cb6b1ebd83c7fd7a4cb2824fac179b7/gateway.yaml
oc create -n my-tutorial -f https://gist.githubusercontent.com/thoraxe/a189ade0d2dd19c8c275179b48577117/raw/02c4ea130cb6b1ebd83c7fd7a4cb2824fac179b7/preference.yaml
oc create -n my-tutorial -f https://gist.githubusercontent.com/thoraxe/a189ade0d2dd19c8c275179b48577117/raw/0f55e6623bdd0a32b31be92f5b0869a0d7abf648/recommendation.yaml
Create a Project to hold the lab guide -- lab-ossm
You will need the cluster's default route subdomain to use with new-app
. The following will put it into a bash
variable:
export SUBDOMAIN=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
Then, use the new-app
subcommand of the oc
CLI to deploy the lab guide:
oc new-app -n lab-ossm https://raw.githubusercontent.com/openshift-homeroom/workshop-spawner/7.1.0/templates/hosted-workshop-production.json \
--param CLUSTER_SUBDOMAIN="$SUBDOMAIN" \
--param SPAWNER_NAMESPACE="lab-ossm" \
--param WORKSHOP_NAME="lab-ossm" \
--param WORKSHOP_IMAGE="quay.io/thoraxe/lab-ossm:production" \
--param OC_VERSION="4.3"
Take special note of the route that is created. It will be something like lab-ossm-lab-ossm.xxxxxx
.
Access the lab guide and then make sure to login using the username and password you use to access the OpenShift environment. Since you needed cluster administrative access to install the Service Mesh operators, you're probably fine.
None of the variables are appropriately set in this environment. You will
need to pay careful attention to all commands to make sure they look like
they will evaluate correctly. The various bash scripts use an environment
variable JUPYTERHUB_USER
as a prefix to Project names (see the note above).
Make sure it is set correctly in the terminals.