Welcome to the seventh installment of That App You Love, a blog series in which I show you how to you can make almost any app into a first-class cloud citizen. If you want to start from the beginning, jump back and check out Part 1: Making a Connection. You’ll need the docker service and the oc utility to follow along in this post; for instructions check out Part 5: Upping Our (Cloud) Game.
In Part 6 of our adventure, we learned how to launch a containerized version of ZNC on the OpenShift Container Platform with a single command - “oc new-app”. But forget about ZNC - we’re really talking about That App You Love, and in this post we’re going to learn how to expose the configurable settings that you care about, along with a few other concepts that will make your app’s cloud experience better.
Let’s Fast-Forward to the Good Stuff
Because our mini-cluster (see Part 5 if you need to set this up) is stateless, any of the work we did in Part 6 disappeared the moment we stopped the cluster. But rather than starting from scratch, we can “fast-forward” to where we were by creating our app and adding a Route all in one go.
To do this, we’ll use a Template that includes everything that OpenShift Container Platform needs to know about our app to put everything back in place.
- If the docker service and OpenShift Container Platform cluster aren’t running, fire them up. Shortcut for Fedora users:
sudo systemctl start docker sudo <path_to>/oc cluster up oc login -u developer -p developer --server=<server_IP>:8443
- Grab a copy of this template file using wget or curl:
wget https://raw.githubusercontent.com/nhr/znc-cluster-app/master/znc-template-basic.yaml
- Run “oc process” to turn the template into a list of objects, and pipe the output to “oc create” to instantiate them:
oc process -f znc-template-basic.yaml | oc create -f -
- Finally, run “oc deploy” to tell OpenShift to get things rolling:
oc deploy dc/znc-cluster-app --latest
That’s it! You can check on the deployment progress with:
oc status
If you deployed the app along with us back in Part 6, this should go pretty quickly. If you’re just jumping in, it will take a few minutes to download our sample app and some other containers.
So what just happened there, and what is that “template” file? We’re going to talk about templates a lot in Part 8, because they make it easy to deploy a number of objects at the same time. But for now, let’s move on to:
Environment Variables in the Cloud
We know that our app container is running as a Pod in our cluster, and down in the container environment we know we’ve got some environment variables. For review, they are:
- ZNC_USER - sets the username of the initial user account
- ZNC_PASS - sets the password of the initial user account
- ZNC_NAME - sets the display name of the initial user account
How do we start to hook these up so that we can change these values when our container is deployed? For this, check out the “oc set env” command:
- First, run “oc set env” to create and set the variables:
oc set env dc/znc-cluster-app -e ZNC_USER=znc ZNC_PASS=znc ZNC_NAME=ZNC
- Next, tell OpenShift to re-deploy our application:
oc deploy dc/znc-cluster-app --latest
- Finally, navigate to the route (a “xip.io” address) for your app. You can find the route to use by running:
oc get routes
And then navigating to:
https://<xip.io address>/
(You can use the Service IP / Service Port address if the xip.io address doesn’t work)
You should see the same ZNC web console page that we remember, but now the “admin” / “admin” username / password combo won’t get you in - you’ve got to use “znc” / “znc” instead. This is a really powerful detail of Kubernetes and the OpenShift Container Platform. We just set some environment variables up at the cloud layer, and they’ve automatically found their way all the way back to ZNC’s config file within a running container.
The values we used when we created our environment variables were all hard-coded values. That’s okay for now. We’re going to learn how to turn those variables into configurable parameters later. Right now we need to give some love to the cloud object that knows everything about That App You Love, and that’s...
Deployments - Another Cloud Part
From Part 6 we know about Pods, Services and Routes. So what is a Deployment? A Deployment (a.k.a. DeploymentConfig, or just ‘dc’ to its friends) tells us:
- What Pod to run
- How many copies of it to run
- A bunch of metadata about the Pod including environment variables
- How to know when to trigger a redeployment
- 5 amazing Linux tricks - number 3 blew my mind!
In Part 6, when we ran “oc new-app” to deploy our container, OpenShift created a Deployment object that tells Kubernetes how to launch our app in a repeatable way. Following on that, in our examples above, you may notice that we didn’t run “oc set env” against our Pod. The “dc/znc-cluster-app” target for our command? That’s our app’s Deployment object.
Why did we just add our environment variable definitions to the Deployment, and not directly to the Pod? Environment variables added to a Pod are lost when the Pod disappears. By defining them in the Deployment instead, every deployed Pod will always include them.
Well that’s great, but how do we really open up those settings so that we can customize every deployment of That App You Love? Tune in for Part 8: A Blueprint for That App You Love!
This series will run every Tuesday and Thursday until we've accomplished our goals, so stay tuned in, subscribe, and thanks for reading!
About the Author
Hi there! My name is N. Harrison Ripps, and I am an engineer and people manager on the Containers team at Red Hat. Together with the greater open source community, our team has taken the combination of the docker container format and Google’s Kubernetes orchestration system, and then extended this framework with a number of administrator- and developer-friendly features that we call the OpenShift Container Platform.
Last updated: March 17, 2023