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
for the latest version of the workshop and also make sure to note if a version
7
16
released has been deprecated.
8
17
18
+
|||
19
+
--- | ---
20
+
| Audience Experience Level | Intermediate |
21
+
| Supported Number of Users | One per cluster [1]|
22
+
| Average Time to Complete | 30 minutes |
23
+
9
24
The workshop uses the HomeRoom workshop environment in the learning portal configuration.
10
25
You will need to be a cluster admin in order to deploy it.
11
26
12
27
When the URL for the workshop environment is accessed, a workshop session will be created on demand.
13
28
14
-
Deploying the Workshop
15
-
----------------------
29
+
## Deploying the Workshop
16
30
17
-
To deploy the workshop, first clone this Git repository to your own machine.
31
+
### Deploying to OpenShift
18
32
19
-
When you clone the repository, ensure you use the `--recurse-submodules` option with the `git clone` command. Alternatively, after having cloned the repository, within the repository directory, run:
33
+
To deploy the workshop, first clone this Git repository to your own machine. Use the command:
The option to `git clone`, or the `git submodule update` command, ensure that a copy of a Git submodule which contains scripts to help you deploy the workshop will also be cloned.
39
+
The ``--recurse-submodules`` option ensures that Git submodules are checked out. If you forget to use this option, after having clone the repository, run:
40
+
41
+
```
42
+
git submodule update --recursive --remote
43
+
```
26
44
27
45
Next create a project in OpenShift into which the workshop is to be deployed.
28
46
@@ -36,79 +54,104 @@ From within the top level of the Git repository, now run the command below.
36
54
.workshop/scripts/deploy-spawner.sh
37
55
```
38
56
39
-
**NOTE:** The default max number of sessions (i.e. users who can access the workshop at the same time) defaults to 50. The number for the max number
40
-
of sessions can be overridden when running the `deploy-spawner.sh` script by supplying the `--override SERVER_LIMIT=50` option. If 50 is not enough sessions, or too many, the amount can be increased or decreased by changing the value from 50 to the expected number of users. Your cluster should have enough resources to support the number of users in your workshop. Each user is given a quota of 8Gi of memory. If you don't set this up front and need to change it later, you can edit the `SERVER_LIMIT` environment variable on the spawner deployment config. Changing it will cause all currently running sessions to be stopped, so avoid changing it during a workshop.
57
+
The name of the pod used to start the workshop will be ``lab-tekton-pipelines-spawner``.
58
+
59
+
### Deploying on Red Hat Product Demo System
60
+
61
+
The workshop is found in the catalog under the *Workshops* folder and is named *OCP4 Pipelines Workshop*.
41
62
42
-
When deployed the name of the deployment will be `lab-tekton-pipelines`.
63
+
Once the cluster is deployed, follow the directions in the next section to begin the workshop itself.
64
+
65
+
## Running the Workshop
43
66
44
67
You can determine the hostname for the URL to access the workshop by running:
45
68
46
69
```
47
70
oc get route lab-tekton-pipelines
48
71
```
49
72
50
-
When the URL is accessed, you will be prompted to login. For the user name, use your email address or other name which would uniquely identify you. This is just used as an identifier for your session if you need to login again to the same session again. What you use for the user name isn't recorded in any way. For the password, use "openshift".
73
+
When first accessing the workshop URL, the user may be presented with a warning about a potential security risk. This is due to the workshop using a self-signed certificate and users should be instructed to elect to continue to the site.
51
74
52
-
Editing the Workshop
53
-
--------------------
75
+
That URL leads to a login for the workshop itself.
54
76
55
-
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`.
77
+
56
78
57
-
To make changes to the workshop content and test them, edit the files in the Git repository and then run:
79
+
Users will enter the following information:
58
80
59
-
```
60
-
.workshop/scripts/build-workshop.sh
61
-
```
81
+
| Key | Value |
82
+
| --- | ----- |
83
+
| Username | The user's e-mail address. This address is not saved anywhere outside of the workshop itself; it will not be used to follow up with the user. It simply acts as a unique identifier for the workshop instance. Logging into the site with a new username will cause a new instance of the workshop to be created (on the same cluster, however, so previously run cluster-wide operations will still be in effect. |
84
+
| Password |``openshift``|
62
85
63
-
This will replace the existing image used by the active deployment.
86
+
After logging in, the workshop takes a few seconds to start:
87
+
88
+
89
+
90
+
Once the workshop begins, users are presented with a two panel interface:
64
91
65
-
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.
92
+
66
93
67
-
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`.
94
+
On the left are the instructions users will follow for the workshop. The workshop itself explains how to use the interface, but generally speaking users will follow the directions on the left, with navigation buttons appearing at the end of each section. Text that is highlighted with a yellow background may be clicked to have the operation automatically executed in the cluster on the right.
68
95
69
-
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:
96
+
By default, users are presented with the terminal, which contains (among other things) an authenticated ``oc`` client. The ``Console`` tab on the right can be clicked to open the OpenShift web console. Again, the user will already be authenticated; if a workshop requires users to change their logged in OpenShift user, the workshop instructions will specifically mention that.
97
+
98
+
99
+
100
+
101
+
## Deleting the Workshop
102
+
103
+
To delete the spawner and any active sessions, including projects, run:
70
104
71
105
```
72
-
.workshop/scripts/deploy-spawner.sh
106
+
./.workshop/scripts/delete-spawner.sh
73
107
```
74
108
75
-
and it will update the active definitions.
109
+
To delete the build configuration for the workshop image, run:
76
110
77
-
Note that if you do this, you will need to re-run:
111
+
```
112
+
./.workshop/scripts/delete-workshop.sh
113
+
```
114
+
115
+
To delete any global resources which may have been created, run:
78
116
79
117
```
80
-
.workshop/scripts/build-workshop.sh
118
+
./.workshop/scripts/delete-resources.sh
81
119
```
82
120
83
-
to have any local content changes be used once again as it will revert back to using the image on ``quay.io``.
121
+
## Development
84
122
85
-
If you need to ever update the deployment scripts pulled in via a git submodule to the latest version, run:
123
+
The deployment created above will use an image from ``quay.io`` for this workshop based on the ``master`` branch of the repository.
124
+
125
+
To make changes to the workshop content and test them, edit the files in the Git repository and then run:
86
126
87
127
```
88
-
git submodule update --recursive --remote
128
+
./.workshop/scripts/build-workshop.sh
89
129
```
90
130
91
-
The update will be staged immediately, so don't forget to commit it.
92
-
93
-
Deleting the Workshop
94
-
---------------------
131
+
This will replace the existing image used by the active deployment.
95
132
96
-
To delete the spawner and any active sessions, including projects, run:
133
+
If you are running an existing instance of the workshop, if you want to start over with a fresh project, first delete the project used for the session.
97
134
98
135
```
99
-
.workshop/scripts/delete-spawner.sh
136
+
oc delete project $PROJECT_NAMESPACE
100
137
```
101
138
102
-
To delete the build configuration for the workshop image, run:
139
+
Then select "Restart Workshop" from the menu top right of the workshop environment dashboard.
140
+
141
+
When you are happy with your changes, push them back to the remote Git repository.
142
+
143
+
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:
103
144
104
145
```
105
-
.workshop/scripts/delete-workshop.sh
146
+
./.workshop/scripts/deploy-spawner.sh
106
147
```
107
148
108
-
To delete special resources for CRDs and cluster roles for the Tekton operator, run:
149
+
and it will update the active definitions.
150
+
151
+
Note that if you do this, you will need to re-run:
109
152
110
153
```
111
-
.workshop/scripts/delete-resources.sh
154
+
./.workshop/scripts/build-workshop.sh
112
155
```
113
156
114
-
Only delete these last set of resources if the Tekton 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.
157
+
to have any local content changes be used once again as it will revert back to using the image on ``quay.io``.
0 commit comments