use USER env and create svc with yaml instead of expose + other changes

config/_default/config.toml

@@ -93,6 +93,18 @@ busybox = "docker.io/busybox:1.28"
 # Enable Lunr.js offline search
 offlineSearch = true
 
+[[params.replaceContent.placeholders]]
+placeholder = "<namespace>"
+queryParam = "n"
+defaultValue = "$USER"
+
+[[params.replaceContent.placeholders]]
+placeholder = "<appdomain>"
+queryParam = "a"
+defaultValue = "<appdomain>"
+
+
+
 [params.ui]
 # Enable to show the side bar menu in its compact state.
 sidebar_menu_compact = false

config/mobi/config.toml

@@ -48,7 +48,7 @@ defaultValue = "<proxy>:<port>"
 
 [[params.replaceContent.placeholders]]
 placeholder = "<noproxy-list>"
-queryParam = "n"
+queryParam = "np"
 defaultValue = "<noproxy-list>"
 
 [[params.replaceContent.placeholders]]

content/en/docs/additional-concepts/init-containers/_index.md

@@ -22,13 +22,7 @@ Check out the [Init Containers documentation](https://docs.openshift.com/contain
 
 In {{<link "attaching-a-database">}} you created the `example-web-app` application. In this task, you are going to add an init container which checks if the MariaDB database is ready to be used before actually starting your example application.
 
-Edit your existing `example-web-app` Deployment with:
-
-```bash
-{{% param cliToolName %}} edit deployment example-web-app --namespace <namespace>
-```
-
-Add the init container into the existing Deployment under `.spec.template.spec`:
+Edit your existing `example-web-app` Deployment by changing your local `deployment_example-web-app.yaml`. Add the init container into the existing Deployment (same indentation level as containers):
 
 ```yaml
 ...
@@ -45,6 +39,12 @@ Add the init container into the existing Deployment under `.spec.template.spec`:
 ...
 ```
 
+And then apply again with:
+
+```bash
+{{% param cliToolName %}} apply -f deployment_example-web-app.yaml --namespace <namespace>
+```
+
 {{% alert title="Note" color="info" %}}
 This obviously only checks if there is a DNS Record for your MariaDB Service and not if the database is ready. But you get the idea, right?
 {{% /alert %}}

content/en/docs/additional-concepts/resourcequotas-and-limitranges/_index.md

@@ -23,13 +23,13 @@ Defining ResourceQuotas makes sense when the cluster administrators want to have
 In order to check for defined quotas in your Namespace, simply see if there are any of type ResourceQuota:
 
 ```bash
-{{% param cliToolName %}} get resourcequota --namespace <namespace>
+{{% param cliToolName %}} get resourcequota --namespace <namespace>-quota
 ```
 
 To show in detail what kinds of limits the quota imposes:
 
 ```bash
-{{% param cliToolName %}} describe resourcequota <quota-name> --namespace <namespace>
+{{% param cliToolName %}} describe resourcequota <quota-name> --namespace <namespace>-quota
 ```
 
 {{% onlyWhenNot openshift %}}
@@ -132,7 +132,7 @@ Remember to use the namespace `<username>-quota`, otherwise this lab will not wo
 Analyse the LimitRange in your Namespace (there has to be one, if not you are using the wrong Namespace):
 
 ```bash
-{{% param cliToolName %}} describe limitrange --namespace <namespace>
+{{% param cliToolName %}} describe limitrange --namespace <namespace>-quota
 ```
 
 The command above should output this (name and Namespace will vary):
@@ -149,7 +149,7 @@ Container   cpu       -    -    10m              100m           -
 Check for the ResourceQuota in your Namespace (there has to be one, if not you are using the wrong Namespace):
 
 ```bash
-{{% param cliToolName %}} describe quota --namespace <namespace>
+{{% param cliToolName %}} describe quota --namespace <namespace>-quota
 ```
 
 The command above will produce an output similar to the following (name and namespace may vary)
@@ -191,7 +191,7 @@ spec:
 Apply this resource with:
 
 ```bash
-{{% param cliToolName %}} apply -f pod_stress2much.yaml --namespace <namespace>
+{{% param cliToolName %}} apply -f pod_stress2much.yaml --namespace <namespace>-quota
 ```
 
 {{% alert title="Note" color="info" %}}
@@ -201,7 +201,7 @@ You have to actively terminate the following command pressing `CTRL+c` on your k
 Watch the Pod's creation with:
 
 ```bash
-{{% param cliToolName %}} get pods --watch --namespace <namespace>
+{{% param cliToolName %}} get pods --watch --namespace <namespace>-quota
 ```
 
 You should see something like the following:
@@ -219,7 +219,7 @@ stress2much   0/1     CrashLoopBackOff    1          20s
 The `stress2much` Pod was OOM (out of memory) killed. We can see this in the `STATUS` field. Another way to find out why a Pod was killed is by checking its status. Output the Pod's YAML definition:
 
 ```bash
-{{% param cliToolName %}} get pod stress2much --output yaml --namespace <namespace>
+{{% param cliToolName %}} get pod stress2much --output yaml --namespace <namespace>-quota
 ```
 
 Near the end of the output you can find the relevant status part:
@@ -238,7 +238,7 @@ Near the end of the output you can find the relevant status part:
 So let's look at the numbers to verify the container really had too little memory. We started the `stress` command using the parameter `--vm-bytes 85M` which means the process wants to allocate 85 megabytes of memory. Again looking at the Pod's YAML definition with:
 
 ```bash
-{{% param cliToolName %}} get pod stress2much --output yaml --namespace <namespace>
+{{% param cliToolName %}} get pod stress2much --output yaml --namespace <namespace>-quota
 ```
 
 reveals the following values:
@@ -262,7 +262,7 @@ Let's fix this by recreating the Pod and explicitly setting the memory request t
 First, delete the `stress2much` pod with:
 
 ```bash
-{{% param cliToolName %}} delete pod stress2much --namespace <namespace>
+{{% param cliToolName %}} delete pod stress2much --namespace <namespace>-quota
 ```
 
 Then create a new Pod where the requests and limits are set:
@@ -297,7 +297,7 @@ spec:
 And apply this again with:
 
 ```bash
-{{% param cliToolName %}} apply -f pod_stress.yaml --namespace <namespace>
+{{% param cliToolName %}} apply -f pod_stress.yaml --namespace <namespace>-quota
 ```
 
 {{% alert title="Note" color="info" %}}
@@ -339,7 +339,7 @@ spec:
 ```
 
 ```bash
-{{% param cliToolName %}} apply -f pod_overbooked.yaml --namespace <namespace>
+{{% param cliToolName %}} apply -f pod_overbooked.yaml --namespace <namespace>-quota
 ```
 
 We are immediately confronted with an error message:
@@ -353,7 +353,7 @@ The default request value of 16 MiB of memory that was automatically set on the
 Let's have a closer look at the quota with:
 
 ```bash
-{{% param cliToolName %}} get quota --output yaml --namespace <namespace>
+{{% param cliToolName %}} get quota --output yaml --namespace <namespace>-quota
 ```
 
 which should output the following YAML definition:
@@ -404,7 +404,7 @@ spec:
 And apply with:
 
 ```bash
-{{% param cliToolName %}} apply -f pod_overbooked.yaml --namespace <namespace>
+{{% param cliToolName %}} apply -f pod_overbooked.yaml --namespace <namespace>-quota
 ```
 
 Even though the limits of both Pods combined overstretch the quota, the requests do not and so the Pods are allowed to run.

content/en/docs/additional-concepts/sidecar-containers/_index.md

@@ -25,30 +25,15 @@ In a sidecar pattern, the functionality of the main container is extended or enh
 In {{<link "persistent-storage">}} you created a MariaDB deployment. In this task you are going to add the [Prometheus MySQL exporter](https://github.com/prometheus/mysqld_exporter) to it.
 
 {{% onlyWhenNot openshift %}}
-Change the existing `mariadb` Deployment using:
+Change the existing `mariadb` Deployment by first editing your local `mariadb.yaml` file. Add a new (sidecar) container into your Deployment:
 
-```bash
-kubectl edit deployment mariadb --namespace <namespace>
-```
-
-And add a new (sidecar) container into your Deployment:
 {{% /onlyWhenNot %}}
 {{% onlyWhen openshift %}}
 {{% onlyWhenNot baloise %}}
-Change the existing `mariadb` DeploymentConfig using:
-
-```bash
-oc edit dc mariadb --namespace <namespace>
-```
-
+Change the existing `mariadb` DeploymentConfig by first editing your local `mariadb.yaml` file. Add a new (sidecar) container into your Deployment.
 {{% /onlyWhenNot %}}
 {{% onlyWhen baloise %}}
-Change the existing `mariadb` Deployment using:
-
-```bash
-oc edit deploy mariadb --namespace <namespace>
-```
-
+Change the existing `mariadb` Deployment using by first editing your local `mariadb.yaml` file. Add a new (sidecar) container into your Deployment:
 {{% /onlyWhen %}}
 And add a new (sidecar) container to it:
 {{% /onlyWhen %}}
@@ -63,6 +48,12 @@ And add a new (sidecar) container to it:
 {{< readfile file="/content/en/docs/additional-concepts/sidecar-containers/deploy_mariadb-sidecar_mobi.yaml" code="true" lang="yaml" >}}
 {{% /onlyWhen %}}
 
+and then apply the change with:
+
+```bash
+{{% param cliToolName %}} apply -f mariadb.yaml --namespace <namespace>
+```
+
 Your Pod now has two running containers. Verify this with:
 
 ```bash
@@ -99,10 +90,14 @@ time="2020-05-10T11:31:02Z" level=info msg=" --collect.info_schema.innodb_cmpmem
 time="2020-05-10T11:31:02Z" level=info msg="Listening on :9104" source="mysqld_exporter.go:283"
 ```
 
-By using the `port-forward` subcommand, you can even have a look at the Prometheus metrics using your browser:
+By using the `port-forward` subcommand, you can even have a look at the Prometheus metrics:
 
 ```bash
 {{% param cliToolName %}} port-forward <pod> 9104 --namespace <namespace>
 ```
 
-Now open <http://localhost:9104/metrics> in your browser.
+And then use `curl` to check the mysqld_exporter metrics with:
+
+```bash
+curl http://localhost:9104/metrics
+```

content/en/docs/attaching-a-database/_index.md

@@ -284,18 +284,17 @@ Depending on the shell you use, the following `set env` command works but insert
 
 ```bash
 {{% param cliToolName %}} set env --from=secret/mariadb --prefix=MYSQL_ deploy/example-web-app --namespace <namespace>
-{{% param cliToolName %}} set env deploy/example-web-app MYSQL_URI='mysql://$(MYSQL_DATABASE_USER):$(MYSQL_DATABASE_PASSWORD)@mariadb/$(MYSQL_DATABASE_NAME)' --namespace <namespace>
 ```
 
-The first command inserts the values from the Secret, the second finally uses these values to put them in the environment variable `MYSQL_URI` which the application considers.
-
-You could also do the changes by directly editing the Deployment:
+and
 
 ```bash
-{{% param cliToolName %}} edit deployment example-web-app --namespace <namespace>
+{{% param cliToolName %}} set env deploy/example-web-app MYSQL_URI='mysql://$(MYSQL_DATABASE_USER):$(MYSQL_DATABASE_PASSWORD)@mariadb/$(MYSQL_DATABASE_NAME)' --namespace <namespace>
 ```
 
-In the file, find the section which defines the containers. You should find it under:
+The first command inserts the values from the Secret, the second finally uses these values to put them in the environment variable `MYSQL_URI` which the application considers.
+
+You can also do the changes by directly editing your local `deployment_example-web-app.yaml` file. Find the section which defines the containers. You should find it under:
 
 ```
 ...
@@ -371,6 +370,15 @@ Your file should now look like this:
           value: mysql://$(MYSQL_DATABASE_USER):$(MYSQL_DATABASE_PASSWORD)@mariadb/$(MYSQL_DATABASE_NAME)
 ```
 
+Then use:
+
+```bash
+{{% param cliToolName %}} apply -f deployment_example-web-app.yaml --namespace <namespace>
+```
+
+to apply the changes.
+
+
 {{% /onlyWhenNot %}}
 {{% onlyWhen sbb %}}
 Add the environment variables by directly editing the Deployment:
@@ -597,7 +605,7 @@ Check your app to see the imported "Hellos".
 You can find your app URL by looking at your route:
 
 ```bash
-oc get route --namespace <namespace>
+{{% param cliToolName %}} get {{% onlyWhenNot openshift %}}ingress{{% /onlyWhen %}}{{% onlyWhen openshift %}}route{{% /onlyWhen %}} --namespace <namespace>
 ```
 {{% /alert %}}
 {{% /onlyWhen %}}

content/en/docs/exposing-a-service/_index.md

@@ -26,9 +26,20 @@ You can also use Ingress to expose your Service. Ingress is not a Service type,
 Traffic routing is controlled by rules defined on the {{% onlyWhenNot openshift %}}Ingress{{% /onlyWhenNot %}}{{% onlyWhen openshift %}}Route{{% /onlyWhen %}} resource. {{% onlyWhenNot openshift %}}An Ingress{{% /onlyWhenNot %}}{{% onlyWhen openshift %}}A Route{{% /onlyWhen %}} may be configured to give Services externally reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the route, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
 
 In order to create {{% onlyWhenNot openshift %}}an Ingress{{% /onlyWhenNot %}}{{% onlyWhen openshift %}}a Route{{% /onlyWhen %}}, we first need to create a Service of type [ClusterIP](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types).
-We're going to do this with the command `{{% param cliToolName %}} expose`:
+
+To create the Service add a new file `svc-web-go.yaml` with the following content:
+
+{{< readfile file="/content/en/docs/exposing-a-service/svc-web-go.yaml" code="true" lang="yaml" >}}
+
+And then apply the file with:
 
 ```bash
+{{% param cliToolName %}} apply -f svc-web-go.yaml --namespace <namespace>
+```
+
+There is also am imperative command to create a service and expose your application which can be used instead of the yaml file with the `{{% param cliToolName %}} apply ...` command
+
+```
 {{% param cliToolName %}} expose deployment example-web-go --type=ClusterIP --name=example-web-go --port=5000 --target-port=5000 --namespace <namespace>
 ```
 
@@ -40,6 +51,7 @@ As a consequence, the `oc expose` command above doesn't add anything new but it
 {{% /onlyWhenNot %}}
 {{% /onlyWhen %}}
 
+
 Let's have a more detailed look at our Service:
 
 ```bash
@@ -170,11 +182,11 @@ As you see in the resource definition at `spec.rules[0].http.paths[0].backend.se
 Let's create the Ingress resource with:
 
 ```bash
-kubectl apply -f <path to ingress.yaml> --namespace <namespace>
+kubectl apply -f ingress.yaml --namespace <namespace>
 ```
 
 {{% onlyWhenNot mobi %}}
-Afterwards, we are able to access our freshly created Ingress at `http://example-web-go-<namespace>.<domain>`
+Afterwards, we are able to access our freshly created Ingress at `http://example-web-go-<namespace>.<appdomain>`
 {{% /onlyWhenNot %}}
 {{% onlyWhen mobi %}}
 Afterwards, we are able to access our app via our freshly created Ingress at `https://example-web-go-<namespace>.<appdomain>`. Although we have not configured the Ingress to use TLS, it is available with a `https` address. This is because of the setup at Mobiliar and not default behavior.
@@ -235,24 +247,42 @@ The `<appdomain>` is the default domain under which your applications will be ac
 
 ## {{% task %}} Expose as NodePort
 
+{{% alert title="Note" color="info" %}}
+This is an advanced lab, so feel free to skip this. NodePorts are usually not used for http-based applications as we use the layer 7-based Ingress resource. Only for non-http based applications, a NodePort might be a suitable alternative.
+{{% /alert %}}
+
 There's a second option to make a Service accessible from outside: Use a [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport).
 
-In order to switch the Service type, we are going to delete the `ClusterIP` Service that we've created before:
+In order to switch the Service type, change the existing `ClusterIP` Service by updating our Service definition in file `svc-web-go.yaml`to:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: example-web-go
+  name: example-web-go
+spec:
+  ports:
+  - port: 5000
+    protocol: TCP
+    targetPort: 5000
+  selector:
+    app: example-web-go
+  type: NodePort
 
-```bash
-kubectl delete service example-web-go --namespace=<namespace>
 ```
 
-With the following command we create a Service:
+And then apply again with:
 
 ```bash
-kubectl expose deployment example-web-go --type=NodePort --name=example-web-go --port=5000 --target-port=5000 --namespace <namespace>
+{{% param cliToolName %}} apply -f svc-web-go.yaml --namespace <namespace>
 ```
 
-Let's have a more detailed look at our Service:
+Let's have a more detailed look at our new `NodePort` Service:
 
 ```bash
-kubectl get services --namespace <namespace>
+{{% param cliToolName %}} get services --namespace <namespace>
 ```
 
 Which gives you an output similar to this:
@@ -264,12 +294,6 @@ example-web-go   NodePort   10.43.91.62   <none>        5000:30692/TCP
 
 The `NodePort` number is assigned by Kubernetes and stays the same as long as the Service is not deleted. A NodePort Service is more suitable for infrastructure tools than for public URLs.
 
-{{% alert title="Note" color="info" %}}
-If `NodePort` is not supported in your environment then you can use `--type=ClusterIP` (or omit this parameter completely as it is the default) and use port forwarding to the Service instead.
-
-Head over to task 6.3 in [lab 6](../06/) to learn how to use port forwarding.
-{{% /alert %}}
-
 Open `http://<node-ip>:<node-port>` in your browser.
 You can use any node IP as the Service is exposed on all nodes using the same `NodePort`. Use `kubectl get nodes -o wide` to display the IPs (`INTERNAL-IP`) of the available nodes.
 

content/en/docs/exposing-a-service/ingress.template.yaml

@@ -5,7 +5,7 @@ metadata:
   name: example-web-go
 spec:
   rules:
-    - host: example-web-go-<namespace>.<domain>
+    - host: example-web-go-<namespace>.<appdomain>
       http:
         paths:
           - path: /