Welcome to the eighth 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 7 we learned how to expose container-level environment variables up at the cloud level, and we also got our first taste of Templates and Deployments. Crafting a Template for our ZNC container image that defines those environment variables - and the rules for setting them - is a major step in improving the app’s reusability and basic security. But forget about ZNC because we’re really talking about That App You Love, and what it takes to make it rock the cloud!
Templates and Parameters: Process, Load, Win!
By the end of Part 7, we had added 3 environment variables to the Deployment object of our app. The values of those variables were hard-coded, and the password was very easy to guess. If we made a template that included those variables with those values, there’s a good chance that everyone who used that template would end up creating an app deployment with the same username and password. That’s bad.
Luckily, OpenShift templates support a set of rules, called Parameters, for describing how variables should be populated. Parameters are processed at the time when the objects in the template are created, meaning that every use of a template can result in different settings.
To see what I mean, try this out:
- If you are still running “oc cluster up” from Part 7, it is easiest to start with a clean slate, so run:
sudo <path_to>/oc cluster down; sudo <path_to>/oc cluster up oc login -u developer -p developer --server=<server_IP>:8443
(If you don’t have a docker environment and the “oc” binary yet, jump back to Part 5 and then come back when your cluster is running.)
- Let’s grab a new version of our app template, using wget or curl:
wget https://raw.githubusercontent.com/nhr/znc-cluster-app/master/znc-template-with-params.yaml
- Next, process and load the template with this combo-command:
oc process -v ZNC_USER=clouduser,ZNC_NAME=CloudUser -f znc-template-with-params.yaml | oc create -f -
- And finally, kick off the Deployment object that we just created:
oc deploy dc/znc-cluster-app --latest
Cool right? Ah - except what actually happened?
Rules of Engagement
Have a look at the environment variables inside the Deployment object with this command:
oc get dc/znc-cluster-app -o yaml | sed -n -e '/env:/,$p' | head -7
You should get output like:
- env: - name: ZNC_USER value: clouduser - name: ZNC_PASS value: F8fpyfBYFl2pBhGq - name: ZNC_NAME value: CloudUser
(Note that you can also see these by inspecting the Deployment object from your OpenShift console - navigate to Applications => Deployments => znc-cluster-app and click the Environment tab.)
The ‘clouduser’ and ‘CloudUser’ values are familiar because we passed them in, but where did that crazy password come from?
Let’s go back and have a look at that template file we are working with, using this command:
cat znc-template-with-params.yaml | tail -13
You should see the wiring behind the boards, which looks like this:
parameters:
- name: ZNC_NAME
description: The display name for the first ZNC user account
value: Administrator
required: true
- name: ZNC_USER
description: The username for the first ZNC user account
value: admin
required: true
- name: ZNC_PASS
description: The password for the first ZNC user account
generate: expression
from: "[a-zA-Z0-9]{16}"Recall that we processed and loaded this template with a combination of two commands (above, in step 3):
- oc process reads a template and dynamically replaces placeholders with values that can be provided, generated, or defaulted. In our case we replaced ZNC_NAME and ZNC_USER with our own values. “oc process” then transforms the contents of the template into JSON representations of actual objects.
- oc create reads a file and creates one or more objects in the cluster based on the contents of the file.
Net result: because we’ve mapped these parameters to the values of the environment variables defined in our Deployment, every time anyone processes our template, a different password is going to get generated. Now we can share this template and enable people to deploy That App You Love without creating a basic, widespread security problem.
Whack-a-Pod
For our last trick today, it is useful to understand that while the template now provides us basic security (which we can upon), the OpenShift cluster itself is also providing us with a fair measure of robustness. Check this out:
- Find the name of your running ZNC pod:
oc get pods
(It will be something like “znc-cluster-app-1-1yb3d”)
- Kill the pod with “oc delete”
oc delete pod <pod_name>
- Re-list the pods on the cluster:
oc get pods
If you run step #3 fast enough, you may catch the cluster with output like this:
NAME READY STATUS RESTARTS znc-cluster-app-1-1yb3d 1/1 Terminating 0 znc-cluster-app-1-vae7x 0/1 ContainerCreating 0
The pod you deleted is briefly in Terminating state, meanwhile a brand new copy of the pod is already spinning up.
Why did this happen? Another component of the application that was created when we first ran “oc new-app” is a ReplicationController, or ‘rc’. The rc’s job is to make sure that the cluster is always running our desired number of app copies (which is 1 in our case).
If you play around with the new copy of your pod, you’ll find that it starts with the same settings as the previous one, and any changes you may have made to the original Pod are lost. It’s time to tackle that last challenge of cloud deployments - in the next post we’ll learn how to use attached storage to bring statefulness to the stateless environment of That App You Love!
See you next time in Part 9: Storage and Statefulness!
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.