Welcome to the tenth and final 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.
Wow, we’ve come a long way! Back in Part 1, we were struck with this crazy idea - let’s take an app we love, containerize it, and then kick it up to the cloud in a way that is secure, robust, and stateful. Along the way, we explored:
- The idea of a Config-and-Run container image
- A mini-cloud that we can run on a single machine, with a single command
- A cast of objects that turned our app into a fully-fledged cloud citizen
And in this final installment, we’ll hit on a few last items that will really put that minty fresh scent on That App You Love.
Taking a Pulse
Kubernetes and OpenShift Container Platform can do basic pod health tracking by checking if the container within it is still running. However, we can improve the granularity of this health checking by adding a Readiness probe to check if the pod is ready for business, and a Liveness probe to check if the pod is still able to serve requests.
- If you are just tuning in, or don’t have your mini-cluster running, jump back and replay Part 9, and leave your cluster running when you are done. If you don’t want to go through all of that, make sure you’ve got the basic cloud setup from Part 5 and then here’s a three-command shortcut. Just be aware that this shortcut does not correctly mount persistent storage:
wget https://raw.githubusercontent.com/nhr/znc-cluster-app/master/znc-template-with-pvc.yaml oc process -f znc-template-with-pvc.yaml | oc create -f - oc deploy dc/znc-cluster-app --latest
- We’ll use a super-simple set of Readiness and Liveness checks for znc-cluster-app; in fact, we’ll use the same test for both:
oc set probe dc/znc-cluster-app --readiness --liveness -- pgrep znc
The magic “test command” here is “pgrep znc”. This program gets run inside the container to this basic effect: “if you find a process with this name in the executable, we’ve got a pulse”. Because we’re using a Config-and-Deploy inside of our container, this is pretty helpful in determining if the process we really care about is running, because the initial process in the container will be our config-and-run script rather than our actual app executable.
Also note that as with our environment variables and PVC’s, we’re applying these probe rules to our Deployment object (dc/znc-cluster-app), so that they get set up in every Pod that gets spun up on our behalf.
A Few More Comments on Security
The sample app that I chose for this series is not a highly sensitive piece of software, but we made two basic improvements to it. In Part 4 we made a container that does not run as root, and in Part 8 we made a template that randomly generates a different starting password for each deployment. If we wanted to get more sophisticated, we could make two bigger improvements:
Secrets
A Secret is an object in OpenShift that references a sensitive piece of data, like a password. To populate the object, the system can look at a filesystem, or pull an image, or clone a repository to read the sensitive data. Then, to apply the secret, the Secret object is bound to a Pod at runtime (similar to a Persistent Volume Claim) and then the running pod has access to the sensitive information. If you are interested, you can read more about secrets in the docs.
A Trusted SSL Certificate Chain
Our sample app generates a self-signed .pem file. Conveniently, this .pem file is stored in the configuration directories that we learned how to expose using persistent storage in Part 9. This gives us a few avenues to choose from for providing our own, trusted certificate chain. As with the password, we could use a Secret object to inject a known-good .pem file into our app pods; alternately we could just replace the generated .pem file in our persistent storage with the trusted one.
A Final Accounting
If you you’d like to continue to experiment with the templates and container image that I’ve created, all of the source code for these items lives on GitHub. You will also find a “complete” template there, along with information on how to deploy that complete template onto a running OpenShift Container Platform starting from scratch.
As I said in the beginning, of course, this series wasn’t just about ZNC - many applications can be prepared for the cloud following similar patterns, very likely including That App You Love. And to take it one step further, if it works for That App You Love, the same strategies will also set you in the right direction for That App You Wrote.
...But that’s another series of articles entirely!
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