That app you love, part 3: Every setting in its place

Welcome to the third 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 2 of this series, we looked at ZNC’s configuration options to decide which settings we wanted to expose to the user, and which settings we could hard-code straight into the container. But don’t forget that we’re not just talking about ZNC - we’re really talking about That App You Love, and how to bring it into the cloud.

As a recap, we know that we want to hard-code these ZNC settings:

• Port number: 6697
• SSL: yes
• IPv6: no
• Set up an IRC network: no

And we want to make these settings configurable:

• Username
• Password
• User display name

We actually didn’t talk about the user display name in the last post; it isn’t a required setting. But if we’re making the username configurable, why not expose the display name setting as well?

Many Apps, Many Configuration Paths

Now, here’s where ZNC and That App You Love will almost certainly have some differences. Some apps have CLI based installation helpers, like ZNC. Others might start with a default config file that you have to edit with the help of a user guide. Either way, your goal now is to produce a valid configuration, and place some environment variables where they will matter to your app deployment.

In the case of my ZNC app, I decided to drive the configuration through ZNC’s built-in wizard rather than by preparing a “pre-cooked” config file. As an aside - this approach works for me and ZNC, but a different approach may be better for you and That App You Love. In any case, take a gander at a snippet of this swanky script, which uses expect to act like a user and configure ZNC for me:

spawn /usr/bin/znc -d $env(ZNC_DATADIR) --makeconf
expect "Listen on port (1025 to 65534):"
send "6697\r"
expect "Listen using SSL (yes/no) \[no\]:"
send "yes\r"
expect "Listen using both IPv4 and IPv6 (yes/no) \[yes\]:"
send "no\r"
expect "Username (alphanumeric):"
send "$env(ZNC_USER)\r"
expect "Enter password:"
send "$env(ZNC_PASS)\r"

What’s happening here? This script runs the ZNC install wizard, listens for the configuration questions, and answers them. Sometimes it uses hard-coded answers (like the port number) and other times it pulls in the environment variables we conjured up in Part 2.

Develop First, Containerize Later

You may have noticed that we’re trying to containerize this app, but haven’t talked about putting this app in an actual container yet. That’s because anything that works inside of a container had better work outside of a container, first. In developing my configuration strategy, I spent a lot of time refining my expect script before I ever bothered building an image.

In fact, you can see the whole configuration process in action without using the image at all:

1. To set up this test, you’ll need to install ZNC and expect. Shortcut for Fedora users:

   sudo dnf install znc expect
   

2. Next, download a copy of the expect script:

   wget https://raw.githubusercontent.com/nhr/znc-cluster-app/master/znc_expect.exp
   

3. Create a temporary landing pad for the ZNC configuration:

   mkdir /tmp/znc-env
   

4. And then invoke the expect script. Feel free to play with different values for the environment variables:

   ZNC_USER=foo ZNC_PASS=bar ZNC_NAME=Foo ZNC_DATADIR=/tmp/znc-env expect znc_expect.exp
   

5. Finally, you can see the generated file with this command:

   cat /tmp/znc-env/configs/znc.conf

You should see that your values - along with the ones that I decided to hard-code - have been committed to the config file. Your password value in the config file is encrypted; ZNC does that for you, which is one of the reasons I decided not take the “pre-baked” approach to the config file!

Next Up: State In A Stateless Place

In this post, we’ve actually covered two important parts of our container design. You may have missed one of them - it was step #1 of our configuration demo, where we installed the software we want to configure. Installing That App You Love will be step #1 of your container image build, as well. The other important part, of course, was the configuration strategy that we used to set the hard-coded and customizable values our app will use. I did it with an expect script - you may use something else.

But how do we bring this all together into a container image that can install, configure, and run That App You Love? Stay tuned for Part 4: Designing a Config-and-Run Container!

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.