In this lab we will explore some of the common activities undertaken by developers working in Kubernetes. You will become familiar with how to use environment variables, secrets, build configurations, and more. Let’s look at some of the basic things a developer might care about for a deployed app.
From the previous lab you should have the DC Metro Maps web app running in Kubernetes.
Only if you don’t already have it running, add it with the following steps.
Goto the terminal and type these commands:
$ oc new-app --name=dc-metro-map https://github.com/RedHatGov/openshift-workshops.git --context-dir=dc-metro-map
$ oc expose service dc-metro-map
There is no more ambiguity or confusion about where the app came from. OpenShift provides traceability for your running deployment back to the docker image and the registry it came from, as well as (for images built by Kubernetes) back to the exact source code branch and commit. Let’s take a look at that.
$ oc status
This is going to show the status of your current project. In this case it will show the dc-metro-map service (svc) with a nested deployment config (dc) along with some more info that you can ignore for now.
The dc provides us details we care about to see where our application image comes from, so let’s check it out in more detail.
$ oc describe dc/dc-metro-map
Notice under the template section it lists the containers it wants to deploy along with the path to the container image.
Because we built this app using S2I, we get to see the details about the build - including the container image that was used for building the source code. So let’s find out where the image came from. Here are the steps to get more information about the build configuration (bc) and the builds themselves.
$ oc describe bc/dc-metro-map
Notice the information about the configuration of how this app gets built. In particular look at the github URL, the webhooks you can use to automatically trigger a new build, the docker image where the build runs inside of, and the builds that have been completed. New let’s look at one of those builds.
This shows us even more about the deployed container’s build and source code including exact commit GUID for this build. We can also can see the commit’s author, and the commit message. You can inspect the code by opening a web browser and pointing it to: https://github.com/RedHatGov/openshift-workshops/commit/[COMMIT_GUID]
Within the deployment for the dc-metro-map is a container summary that shows both the GUID for the image and the GUID for the git branch.
Because we built this app using S2I, we get to see the details about the build - including the container image that was used for building the source code. Note that you can kick-off a rebuild here if something went wrong with the initial build and you’d like to attempt it again.
Notice in the Source line you can see the comment from the last commit when the build was started. And you can see the that commit’s author. You can click that commit GUID to be taken to the exact version of the source code that is in this deployed application.
In the S2I lab we looked at a build log to inspect the process of turning source code into an image. Now let’s inspect the log for a running pod - in particular let’s see the web application’s logs.
$ oc get pods
This is going to show basic details for all pods in this project (including the builders). Let’s look at the log for the pod running our application. Look for the POD NAME that that is “Running” you will use it below.
$ oc logs [POD NAME]
You will see in the output details of your app starting up and any status messages it has reported since it started.
This is going to show basic details for all pods in this project (including the builders). Next let’s look at the log for the pod running our application.
Whether it’s a database name or a configuration variable, most applications make use of environment variables. It’s best not to bake these into your containers because they do change and you don’t want to rebuild an image just to change an environment variable. Good news! You don’t have to. Kubernetes let’s you specify environment variables in your deployment configuration and they get passed along through the pod to the container. Let’s try doing that.
Let’s have a little fun. The app has some easter eggs that get triggered when certain env vars are set to ‘true’.
$ oc set env dc/dc-metro-map -e BEERME=true
$ oc get pods -w
Due to the deployment config strategy being set to “Rolling” and the “ConfigChange” trigger being set, Kubernetes auto deployed a new pod as soon as you updated with the env variable. If you were quick enough you saw this happening with the get pods command
With the new environment variables set the app should look like this in your web browser (with beers instead of busses):
Environment variables are great, but sometimes we don’t want sensitive data exposed in the environment. We will get into using secrets later when you do the lab: Keep it Secret, Keep it Safe
There are situations when you might want to jump into a running pod, and Kubernetes lets you do that pretty easily. We set some environment variables and secrets in this lab, let’s jump onto our pod to inspect them.
$ oc get pods
Find the pod name for your Running pod
$ oc exec -it [POD NAME] /bin/bash
You are now interactively attached to the container in your pod. Let’s look for the environment variables we set:
$ env | grep BEER
That should return the BEERME=true matching the value that we set in the deployment config.
$ exit
Let’s look for the environment variables we set:
Let’s clean up all this to get ready for the next lab:
$ oc delete all -l app=dc-metro-map
In this lab you’ve seen how to trace running software back to its roots, how to see details on the pods running your software, how to update deployment configurations, how to inspect logs files, how to set environment variables consistently across your environment, and how to interactively attach to running containers. All these things should come in handy for any developer working in an Kubernetes platform.
To dig deeper in to details behind the steps you performed in this lab, check out the OpenShift developer’s guide.