You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+38-84Lines changed: 38 additions & 84 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,129 +3,83 @@ Developing with Odo
3
3
4
4
In this self paced workshop you will learn how to use OpenShift Do (`odo`) to build and deploy applications on the OpenShift Container Platform.
5
5
6
-
Deploying the workshop
6
+
Deploying the Workshop
7
7
----------------------
8
8
9
-
To deploy the workshop for use at an event, such as a booth at a conference, where users will come and go and the number of users is unknown, you will need to deploy this to an OpenShift cluster using an account with cluster admin access.
9
+
To deploy the workshop, first clone this Git repository to your own machine.
10
10
11
-
First create a project under which the deployment for the workshop is to run. The project name `workshop` is recommended if available.
11
+
Next create a project in OpenShift into which the workshop is to be deployed.
The value of the `PROJECT_NAME` template parameter must match the name of the project you created. You also need to supply the `--namespace` option with the same project name if the project isn't your current context.
17
+
From within the top level of the Git repository, now run:
28
18
29
-
The value of the `APPLICATION_NAME` template parameter should be a name to identify the specific workshop.
19
+
```
20
+
./.workshop/scripts/deploy-spawner.sh
21
+
```
30
22
31
-
The value of the `TERMINAL_IMAGE` is the name of the image on `quay.io` built from this repository, for this workshop.
23
+
The name of the deployment will be ``developing-with-odo``.
32
24
33
-
Once deployed, run:
25
+
You can determine the hostname for the URL to access the workshop by running:
34
26
35
-
```bash
36
-
oc get route/odo --namespace workshop
27
+
```
28
+
oc get route developing-with-odo
37
29
```
38
30
39
-
to determine the name of the public route to access the workshop. Each user visiting the URL will get their own instance of the application delivering the workshop content and, embedded terminals and console.
40
-
41
-
Working on the content
42
-
----------------------
43
-
44
-
To make changes to the content, there are a few methods you can
45
-
use.
31
+
Editing the Workshop
32
+
--------------------
46
33
47
-
The first way is to use a local docker service running on your own machine. The local container instance will be used to host the content while you work on it. You will still need a separate OpenShift cluster to test the deployments in if you want to execute any commands given in the steps.
34
+
The deployment created above will use a version of the workshop which has been pre-built into an image and which is hosted on ``quay.io``.
48
35
49
-
To use this method, first pull down the `workshop-dashboard` container image. You can switch to using the `latest` image, or other tagged version as necessary. You should use the same version as is used in the `Dockerfile`.
36
+
To make changes to the workshop content and test them, edit the files in the Git repository and then run:
Run this image with `docker run`, exposing port `10080` so you can access it from your web browser. At the same time, mount the directory for the repository into the container at the directory `/opt/app-root/src`.
56
-
57
-
```bash
58
-
docker run --rm -p 10080:10080 -v `pwd`:/opt/app-root/src \
59
-
quay.io/openshiftlabs/workshop-dashboard:1.3.3
39
+
./.workshop/scripts/build-workshop.sh
60
40
```
61
41
62
-
Open a browser window against `http://localhost:10080`. Use the docker host IP if not running on `localhost`.
63
-
64
-
This will allow you to check whether your content is displayed properly and navigate back and forth through the steps.
42
+
This will replace the existing image used by the active deployment.
65
43
66
-
Because you are not running in an OpenShift cluster, if you want to test running of commands against a cluster, you will need to first run `oc login` against the cluster you want to use, and provide any credentials for logging into that cluster. Alternatively, use `oc login --token` with an access token for the cluster. If the content assumes that you already have a project created for you, create a new project as necessary.
44
+
If you are running an existing instance of the workshop, from your web browser select "Restart Workshop" from the menu top right of the workshop environment dashboard.
67
45
68
-
Note that because you are only using the base image `workshop-dashboard` when running the container, if there are any build steps defined in the `Dockerfile`, they will not be run. You would therefore need to manually run any build steps to further setup the environment. Be aware that because you are mounting your local repository directory, those steps could add or remove files from it. Do not therefore run steps which would be destructive to the repository directory.
46
+
When you are happy with your changes, push them back to the remote Git repository. This will automatically trigger a new build of the image hosted on ``quay.io``.
69
47
70
-
Unless these additional steps are simple and non destructive, you are best off only using this method to test the display of content and any navigation.
48
+
If you need to change the RBAC definitions, or what resources are created when a project is created, change the definitions in the ``templates`` directory. You can then re-run:
71
49
72
-
If you desire, you can with this method keep the container running and edit the content markdown files from your local machine. When you want to check it, you need only reload the browser window, or content frame, to see the changes. You do not need to restart the container. A restart of the container would only be required if modifying the `workshop/config.js` file.
50
+
```
51
+
./.workshop/scripts/deploy-spawner.sh
52
+
```
73
53
74
-
Testing the content
75
-
-------------------
54
+
and it will update the active definitions.
76
55
77
-
To build an image and test it in a local container run time, run:
56
+
Note that if you do this, you will need to re-run:
78
57
79
-
```bash
80
-
docker build -t lab-developing-with-odo .
81
58
```
82
-
83
-
Then run it as:
84
-
85
-
```bash
86
-
docker run --rm -p 10080:10080 lab-developing-with-odo:latest
59
+
./.workshop/scripts/build-workshop.sh
87
60
```
88
61
89
-
Open a browser window against `http://localhost:10080`. Use the docker host IP if not running on `localhost`.
62
+
to have any local content changes be used once again as it will revert back to using the image on ``quay.io``.
90
63
91
-
As before you will need to login to any OpenShift cluster from the command line using `oc login`. In this case though, the build steps have been run, so no manual steps are required to set up the environment.
64
+
Deleting the Workshop
65
+
---------------------
92
66
93
-
To build an image and test it in conjunction with the learning portal deployment before pushing and making it public, first deploy an instance of the learning portal with an empty workshop image. Presuming the same `workshop` project is used, run:
67
+
To delete the spawner and any active sessions, including projects, run:
Once the image has been built, update the learning portal image stream configuration to use your latest build.
79
+
To delete special resources for CRDs and cluster roles for the Kafa operator, run:
124
80
125
-
```bash
126
-
oc tag lab-deploying-to-odo:latest odo-test-app:latest
81
+
```
82
+
./.workshop/scripts/delete-resources.sh
127
83
```
128
84
129
-
This must be done each time to ensure that `latest` tag of `odo-test-app` is mapped to the image hash for the latest build.
130
-
131
-
You can then click on the "Restart" button top right of the dashboard view to force any user session to be shutdown and a new started with the new version of the image to test.
85
+
Only delete these last set of resources if the Kafa operator is not being used elsewhere in the cluster. Ideally this workshop environment should only be deployed in an expendable cluster, and not one which is shared for other work.
0 commit comments