That app you love, part 4: Designing a config-and-run container

Welcome to the fourth 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.

In Part 3, we looked at how to customize the configuration of ZNC using an expect script and environment variables. But forget ZNC, because we’re really talking about That App You Love, and the way you configure it is up to you - as long as you use environment variables to expose the flexibility that you need. And now it’s time to containerize it by combining three distinct jobs into a single container image:

• Install the app
• Configure the app
• Run the app

Build-Time vs. Run-Time

When we think about creating a container image, we have two opportunities to effect change: a) when the container image is first built and b) when the container is actually running. In general, we want to reduce the start time on our containers, and ideally this means we do as much at build-time as possible. But I’m here to advocate for sacrificing a very small amount of run-time startup for the opportunity to customize each deployment of That App You Love. And after all - isn’t that kind of love worth a few microseconds?

Here’s all ten lines of the Dockerfile for znc-zluster-app:

FROM fedora:24
MAINTAINER N. Harrison Ripps

RUN dnf install -y procps-ng expect znc && mkdir /opt/znc-env && mkdir /opt/znc-run
COPY znc_* /opt/znc-run/
RUN chown -R 1001:0 /opt/znc-env /opt/znc-run && chmod -R ug+rwx /opt/znc-env /opt/znc-run
USER 1001

EXPOSE 6697
ENTRYPOINT ["/opt/znc-run/znc_runner.sh"]

In line #3, I tackle the first job - installing my app. In line #10, I tackle the final job - running my app. But wait a minute - what about the configuration job we spent all of the last blog post talking about? And - bonus question - why are we changing user IDs midway through this build?

Let’s answer the bonus question first. If you are reading this post on a Linux device, are you currently logged in as the root user? Probably not, because you enjoy not accidentally nuking your system with a single errant command. So why on earth would we want to run That App You Love as root? Good ol’ user 1001 doesn’t have root privileges and it can run our app just fine. High five, user 1001.

Now, about the other question - when do we actually configure our app? If you recall from our last post, the command to run ZNC is “znc”, not “znc_runner.sh” - so to answer your question, let’s take a closer look at that znc_runner.sh file.

The Config-and-Run Script

Here’s a pared down look at the contents of znc_runner.sh. This script brings together app configuration and app running under a single executable process:

# Handle environment variables
...

# Check if the ZNC config exists
if [ ! -d ${ZNC_DATADIR}/configs ]; then
  ${ZNC_EXECDIR}/znc_expect.exp
fi

# Run ZNC
/usr/bin/znc -d $ZNC_DATADIR --foreground

The logic here is pretty simple:

1. Check the container filesystem for an indication that the app is configured
2. Configure it if necessary (I do this by invoking my expect script)
3. Run the app as a foreground process

Because app image containers are inherently stateless, the configuration is going to run every single time we invoke this container - unless somehow the configuration that was written by one container is available to subsequent containers. Then, the config check for those later generations will skip configuration and go straight to running the app. We’re going to leverage that later on in this blog series.

I Love It When A Plan Comes Together

To see how the Dockerfile, the config-and-run-script, and environment variables come together for That App You Love, let’s run znc-cluster-app one more time:

1. If you haven’t already, install and start docker. Shortcut for Fedora users:

   sudo dnf install -y docker && sudo systemctl start docker
   

2. Next, copy my app image if you don’t have it:

   sudo docker pull nhripps/znc-cluster-app:latest

3. Run the image, replacing 9999 with a free port on your system if you need to, and with a few sample env variables set:

   sudo docker run -p 9999:6697 -d -e ZNC_USER=ronaldinho -e ZNC_PASS=futbol --name=znc2 nhripps/znc-cluster-app
   

4. Take a look at the container logs:

   sudo docker logs znc2

The log output will look a lot like the output of my expect script from Part 3. And now we know what is happening: a) the container starts, b) there is no existing config, c) a configuration is created based on the environment variables that we passed in, d) the app is now running.

If my laptop were always on and always connected to the internet, I could wrap up this series by showing you how to mount a directory from my laptop into my running container. That would add statefulness, yes, but not robustness. And let’s not sell ourselves short - That App You Love belongs in the cloud!

We’ll turn our eyes to the skies when we start looking at cloud deployments in Part 5: Upping Our (Cloud) Game.

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.