Chapter 2. Deploying an application workshop

Procedure

1. Confirm you are logged in to the ROSA CLI by running the following command:

   rosa whoami

   If you are logged in to the command-line interface, skip to "Creating a new project". If you are not logged in to the command-line interface, continue this procedure.

2. Access your cluster with the web console.

3. Click the dropdown arrow next to your login name in the upper right corner, and select Copy Login Command.

   

   A new tab opens.

4. Select your authentication method.
5. Click Display Token.
6. Copy the command under Log in with this token.

7. From your terminal, paste and run the copied command. If the login is successful, you will see the following confirmation message:

   $ oc login --token=<your_token> --server=https://api.osd4-demo.abc1.p1.openshiftapps.com:6443
   Logged into "https://api.myrosacluster.abcd.p1.openshiftapps.com:6443" as "rosa-user" using the token provided.
   
   You don't have any projects. You can try to create a new project, by running
   
   oc new-project <project name>

Procedure

1. From the web console, click Home Projects.

2. On the Projects page, click create Create Project.

   
3. In the Create Project box, enter a project name in the Name field.
4. Click Create.

Procedure

1. Copy the ostoy-route-ostoy.apps.<your-rosa-cluster>.abcd.p1.openshiftapps.com URL output from the previous step.

2. Paste the copied URL into your web browser and press enter. You should see the homepage of your application. If the page does not load, make sure you used http and not https.

   

Procedure

1. From the OSToy application web console, click Home in the left menu, and enter a message in the Crash Pod box, for example, This is goodbye!.

2. Click Crash Pod.

   

   The pod crashes and Kubernetes restarts the pod.

   

Verification

1. From the web console, click Pods > ostoy-frontend-xxxxxxx-xxxx to change to the pods screen.

   

2. Click the Events subtab, and verify that the container crashed and restarted.

   

Procedure

1. In the OSToy application web console, click Networking in the left menu.

2. Review the networking configuration. The tile "Hostname Lookup" illustrates how the service name created for a pod translates into an internal ClusterIP address.

   

3. Enter the name of the microservice created in the "Hostname Lookup" tile following the format: <service_name>.<namespace>.svc.cluster.local. You can find the microservice name in the service definition of ostoy-microservice.yaml by running the following command:

   $ oc get service <name_of_service> -o yaml

   For example:

   apiVersion: v1
   kind: Service
   metadata:
     name: ostoy-microservice-svc
     labels:
       app: ostoy-microservice
   spec:
     type: ClusterIP
     ports:
       - port: 8080
         targetPort: 8080
         protocol: TCP
     selector:
       app: ostoy-microservice

   In this example, the full hostname is ostoy-microservice-svc.ostoy.svc.cluster.local.

4. An IP address is returned. In this example it is 172.30.165.246. This is the intra-cluster IP address, which is only accessible from within the cluster.

   

Procedure

1. In the OSToy app, click the Networking tab in the navigational menu.

2. In the "Intra-cluster Communication" section, locate the box that randomly changes colors. Inside the box, you see the microservice’s pod name. There is only one box in this example because there is only one microservice pod.

   

3. Confirm that there is only one pod running for the microservice by running the following command:

   $ oc get pods

   For example:

   NAME                                  READY     STATUS    RESTARTS   AGE
   ostoy-frontend-679cb85695-5cn7x       1/1       Running   0          1h
   ostoy-microservice-86b4c6f559-p594d   1/1       Running   0          1h

4. Download the ostoy-microservice-deployment.yaml and save it to your local machine.

5. Change the deployment definition to three pods instead of one by using the following example:

   spec:
       selector:
         matchLabels:
           app: ostoy-microservice
       replicas: 3

6. Apply the replica changes by running the following command:

   $ oc apply -f ostoy-microservice-deployment.yaml

   Note

   You can also edit the ostoy-microservice-deployment.yaml file in the OpenShift Web Console by going to the Workloads > Deployments > ostoy-microservice > YAML tab.

7. Confirm that there are now 3 pods by running the following command:

   $ oc get pods

   The output shows that there are now 3 pods for the microservice instead of only one.

   For example:

   NAME                                  READY   STATUS    RESTARTS   AGE
   ostoy-frontend-5fbcc7d9-rzlgz         1/1     Running   0          26m
   ostoy-microservice-6666dcf455-2lcv4   1/1     Running   0          81s
   ostoy-microservice-6666dcf455-5z56w   1/1     Running   0          81s
   ostoy-microservice-6666dcf455-tqzmn   1/1     Running   0          26m

8. Scale the application by using the command-line interface (CLI) or by using the web user interface (UI):

   • In the CLI, decrease the number of pods from 3 to 2 by running the following command:

     $ oc scale deployment ostoy-microservice --replicas=2

   • From the navigational menu of the OpenShift web console UI, click Workloads > Deployments > ostoy-microservice.
   • Locate the blue circle with a "3 Pod" label in the middle.

   • Selecting the arrows next to the circle scales the number of pods. Select the down arrow to 2.

     

1. From the ROSA CLI, confirm that you are using two pods for the microservice by running the following command:

   $ oc get pods

   For example:

   NAME                                  READY   STATUS    RESTARTS   AGE
   ostoy-frontend-5fbcc7d9-rzlgz         1/1     Running   0          75m
   ostoy-microservice-6666dcf455-2lcv4   1/1     Running   0          50m
   ostoy-microservice-6666dcf455-tqzmn   1/1     Running   0          75m

2. In the web UI, select Workloads > Deployments > ostoy-microservice.

   

3. You can also confirm that there are two pods by selecting Networking in the navigation menu of the OSToy application. There should be two colored boxes for the two pods.

   

Procedure

1. From the navigational menu of the web UI, select Pod Auto Scaling.

   

2. Create the HPA by running the following command:

   $ oc autoscale deployment/ostoy-microservice --cpu-percent=80 --min=1 --max=10

   This command creates an HPA that maintains between 1 and 10 replicas of the pods controlled by the ostoy-microservice deployment. During deployment, HPA increases and decreases the number of replicas to keep the average CPU use across all pods at 80% and 40 millicores.

3. On the Pod Auto Scaling > Horizontal Pod Autoscaling page, select Increase the load.

   Important

   Because increasing the load generates CPU intensive calculations, the page can become unresponsive. This is an expected response. Only click Increase the Load once. For more information about the process, see the microservice’s GitHub repository.

   After a few minutes, the new pods display on the page represented by colored boxes.

   Note

   The page can experience lag.

Procedure

1. Create a new project called autoscale-ex by running the following command:

   $ oc new-project autoscale-ex

2. Create the job by running the following command:

   $ oc create -f https://raw.githubusercontent.com/openshift-cs/rosaworkshop/master/rosa-workshop/ostoy/yaml/job-work-queue.yaml

3. After a few minutes, run the following command to see the pods:

   $ oc get pods

   For example:

   NAME                     READY   STATUS    RESTARTS   AGE
   work-queue-5x2nq-24xxn   0/1     Pending   0          10s
   work-queue-5x2nq-57zpt   0/1     Pending   0          10s
   work-queue-5x2nq-58bvs   0/1     Pending   0          10s
   work-queue-5x2nq-6c5tl   1/1     Running   0          10s
   work-queue-5x2nq-7b84p   0/1     Pending   0          10s
   work-queue-5x2nq-7hktm   0/1     Pending   0          10s
   work-queue-5x2nq-7md52   0/1     Pending   0          10s
   work-queue-5x2nq-7qgmp   0/1     Pending   0          10s
   work-queue-5x2nq-8279r   0/1     Pending   0          10s
   work-queue-5x2nq-8rkj2   0/1     Pending   0          10s
   work-queue-5x2nq-96cdl   0/1     Pending   0          10s
   work-queue-5x2nq-96tfr   0/1     Pending   0          10s

4. Because there are many pods in a Pending state, this status triggers the autoscaler to create more nodes in your machine pool. Allow time to create these worker nodes.

5. After a few minutes, use the following command to see how many worker nodes you now have:

   $ oc get nodes

   For example:

   NAME                                         STATUS   ROLES          AGE     VERSION
   ip-10-0-138-106.us-west-2.compute.internal   Ready    infra,worker   22h     v1.23.5+3afdacb
   ip-10-0-153-68.us-west-2.compute.internal    Ready    worker         2m12s   v1.23.5+3afdacb
   ip-10-0-165-183.us-west-2.compute.internal   Ready    worker         2m8s    v1.23.5+3afdacb
   ip-10-0-176-123.us-west-2.compute.internal   Ready    infra,worker   22h     v1.23.5+3afdacb
   ip-10-0-195-210.us-west-2.compute.internal   Ready    master         23h     v1.23.5+3afdacb
   ip-10-0-196-84.us-west-2.compute.internal    Ready    master         23h     v1.23.5+3afdacb
   ip-10-0-203-104.us-west-2.compute.internal   Ready    worker         2m6s    v1.23.5+3afdacb
   ip-10-0-217-202.us-west-2.compute.internal   Ready    master         23h     v1.23.5+3afdacb
   ip-10-0-225-141.us-west-2.compute.internal   Ready    worker         23h     v1.23.5+3afdacb
   ip-10-0-231-245.us-west-2.compute.internal   Ready    worker         2m11s   v1.23.5+3afdacb
   ip-10-0-245-27.us-west-2.compute.internal    Ready    worker         2m8s    v1.23.5+3afdacb
   ip-10-0-245-7.us-west-2.compute.internal     Ready    worker         23h     v1.23.5+3afdacb

   You can see the worker nodes were automatically created to handle the workload.

6. Return to the OSToy application by entering the following command:

   $ oc project ostoy

Procedure

1. Confirm you are logged in to the ROSA CLI by running the following command:

   rosa whoami

   If you are logged in to the command-line interface, skip to "Creating a new project". If you are not logged in to the command-line interface, continue this procedure.

2. If you are not logged in to the ROSA CLI, in OpenShift Cluster Manager, click the dropdown arrow next to your name in the upper-right and select Copy login command.

   
3. A new tab opens. Enter your username and password, and select the authentication method.
4. Click Display Token
5. Copy the command under "Log in with this token".

6. Log in to the CLI by running the copied command in your terminal.

   For example:

   $ oc login --token=RYhFlXXXXXXXXXXXX --server=https://api.osd4-demo.abc1.p1.openshiftapps.com:6443

   Example output:

   Logged into "https://api.myrosacluster.abcd.p1.openshiftapps.com:6443" as "rosa-user" using the token provided.
   
   You don't have any projects. You can try to create a new project, by running
   
   oc new-project <project name>

Procedure

1. Add a secret to OpenShift.

   This example emulates a .env file. Files are easily moved directly into an OpenShift environment and can even be renamed in the secret.

   • Run the following command, replacing <UserName> with your GitHub username:

     $ oc create -f https://raw.githubusercontent.com/<UserName>/ostoy/master/deployment/yaml/secret.yaml

2. Add a ConfigMap to OpenShift.

   This example emulates an HAProxy config file, which is typically used for overriding default configurations in an OpenShift application. Files can be renamed in the ConfigMap.

   • Run the following command, replacing <UserName> with your GitHub username:

     $ oc create -f https://raw.githubusercontent.com/<UserName>/ostoy/master/deployment/yaml/configmap.yaml

3. Deploy the microservice.

   You must deploy the microservice to ensure that the service environment variables are available from the UI application.

   --context-dir builds the application defined in the microservice directory in the Git repository. The app label ensures the user interface (UI) application and microservice are both grouped in the OpenShift UI.

   • Run the following command to create the microservice, replacing <UserName> with your GitHub username:

     $ oc new-app https://github.com/<UserName>/ostoy \
         --context-dir=microservice \
         --name=ostoy-microservice \
         --labels=app=ostoy

     Example output:

     --> Creating resources with label app=ostoy ...
         imagestream.image.openshift.io "ostoy-microservice" created
         buildconfig.build.openshift.io "ostoy-microservice" created
         deployment.apps "ostoy-microservice" created
         service "ostoy-microservice" created
     --> Success
         Build scheduled, use 'oc logs -f buildconfig/ostoy-microservice' to track its progress.
         Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
          'oc expose service/ostoy-microservice'
         Run 'oc status' to view your app.

4. Check the status of the microservice.

   • Check that the microservice was created and is running correctly by running the following command:

     $ oc status

     For example:

     In project ostoy-s2i on server https://api.myrosacluster.g14t.p1.openshiftapps.com:6443
     
     svc/ostoy-microservice - 172.30.47.74:8080
       dc/ostoy-microservice deploys istag/ostoy-microservice:latest <-
         bc/ostoy-microservice source builds https://github.com/UserName/ostoy on openshift/nodejs:14-ubi8
         deployment #1 deployed 34 seconds ago - 1 pod

     Wait until you see that the microservice was successfully deployed. You can also check this through the web UI.

5. Deploy the front end UI.

   The application relies on several environment variables to define external settings.

   • Attach the secret and ConfigMap and create a PersistentVolume by running the following command:

     $ oc new-app https://github.com/<UserName>/ostoy \
         --env=MICROSERVICE_NAME=OSTOY_MICROSERVICE

     For example:

     --> Creating resources ...
         imagestream.image.openshift.io "ostoy" created
         buildconfig.build.openshift.io "ostoy" created
         deployment.apps "ostoy" created
         service "ostoy" created
     --> Success
         Build scheduled, use 'oc logs -f buildconfig/ostoy' to track its progress.
         Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
          'oc expose service/ostoy'
         Run 'oc status' to view your app.

6. Update the deployment by running the following command:

   $ oc patch deployment ostoy --type=json -p \
       '[{"op": "replace", "path": "/spec/strategy/type", "value": "Recreate"}, {"op": "remove", "path": "/spec/strategy/rollingUpdate"}]'

7. Set a liveness probe.

   Create a liveness probe to ensure the pod restarts if something is wrong in the application.

   • Run the following command:

     $ oc set probe deployment ostoy --liveness --get-url=http://:8080/health

8. Attach the secret, ConfigMap, and persistent volume to the deployment.

   1. Run the following command to attach your secret:

      $ oc set volume deployment ostoy --add \
          --secret-name=ostoy-secret \
          --mount-path=/var/secret

   2. Run the following command to attach your ConfigMap:

      $ oc set volume deployment ostoy --add \
          --configmap-name=ostoy-config \
          -m /var/config

   3. Run the following command to create and attach your persistent volume:

      $ oc set volume deployment ostoy --add \
          --type=pvc \
          --claim-size=1G \
          -m /var/demo_files

9. Expose the UI application as an OpenShift Route.

   • Run the following command to deploy the application as an HTTPS application that uses the included TLS wildcard certificates:

     $ oc create route edge --service=ostoy --insecure-policy=Redirect

10. Browse to your application with the following methods:

    • Run the following command to open a web browser with your OSToy application:

      $ python -m webbrowser "$(oc get route ostoy -o template --template='https://{{.spec.host}}')"

    • Run the following command to get the route for the application and copy and paste the route into your browser:

      $ oc get route

Procedure

1. Obtain the GitHub webhook trigger secret by running the following command:

   $ oc get bc/ostoy-microservice -o=jsonpath='{.spec.triggers..github.secret}'

   For example:

   `o_3x9M1qoI2Wj_cz1WiK`

   Important

   You need to use this secret in a later step in this process.

2. Obtain the GitHub webhook trigger URL from the OSToy’s buildconfig by running the following command:

   $ oc describe bc/ostoy-microservice

   For example:

   [...]
   Webhook GitHub:
   	URL:	https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy/webhooks/<secret>/github
   [...]

3. In the GitHub webhook URL, replace the <secret> text with the secret you retrieved. Your URL will resemble the following example output:

   For example:

   https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy-microservice/webhooks/o_3x9M1qoI2Wj_czR1WiK/github

4. Set up the webhook URL in GitHub repository.

   1. In your repository, click Settings > Webhooks > Add webhook.

      
   2. Paste the GitHub webhook URL with the Secret included in the "Payload URL" field.
   3. Change the "Content type" to application/json.

   4. Click the Add webhook button.

      

      You should see a message from GitHub stating that your webhook was successfully configured. Now, whenever you push a change to your GitHub repository, a new build automatically starts, and upon a successful build, a new deployment starts.

5. Make a change in the source code. Any changes automatically trigger a build and deployment. In this example, the colors that denote the status of your OSToy app are randomly selected. To test the configuration, change the box to display grayscale.

   1. Go to the source code in your repository https://github.com/<username>/ostoy/blob/master/microservice/app.js.
   2. Edit the file.
   3. Comment out line 8 (containing let randomColor = getRandomColor();).

   4. Uncomment line 9 (containing let randomColor = getRandomGrayScaleColor();).

      7   app.get('/', function(request, response) {
      8   //let randomColor = getRandomColor(); // <-- comment this
      9   let randomColor = getRandomGrayScaleColor(); // <-- uncomment this
      10
      11  response.writeHead(200, {'Content-Type': 'application/json'});

   5. Enter a message for the update, such as "changed box to grayscale colors".
   6. Click Commit at the bottom to commit the changes to the main branch.

6. In your cluster’s web UI, click Builds > Builds to determine the status of the build. After this build is completed, the deployment begins. You can also check the status by running oc status in your terminal.

   

7. After the deployment has finished, return to the OSToy application in your browser. Access the Networking menu item on the left. The box color is now limited to grayscale colors only.