Cloud Native 5 Minutes at a Time: Running a Containerized App

One of the biggest challenges for implementing cloud native technologies is learning the fundamentals—especially when you need to fit your learning into a busy schedule.

In this series, we’ll break down core cloud native concepts, challenges, and best practices into short, manageable exercises and explainers, so you can learn five minutes at a time. These lessons assume a basic familiarity with the Linux command line and a Unix-like operating system—beyond that, you don’t need any special preparation to get started.

In our last lesson, we defined some core concepts in container networking and learned how to publish container ports, opening a container’s services to traffic from the outside world. This time, we’re going to bring together most of what we’ve learned so far to run a containerized web app with persistent volumes and published ports: in this case, a knowledge-sharing wiki platform.

Table of Contents

1. What is a Container?
2. Creating, Observing, and Deleting Containers
3. Build Image from Dockerfile
4. Using an Image Registry
5. Volumes and Persistent Storage
6. Container Networking and Opening Container Ports
7. Running a Containerized App←You are here
8. Multi-Container Apps on User-Defined Networks

Bringing the pieces together

Wikipedia is built on an open source platform called Mediawiki, and an official Docker image for the application is maintained on Docker Hub. That means it should be easy to get our own wiki running quickly—in less than five minutes, even!

The default architecture for this deployment is very straightforward: a single container for the application, which can either write data to a volume all on its own—the default configuration—or work in tandem with a second container running a production-grade database—the option you would want to use if you were taking this wiki to production, pushing it live for real-world use.

In this lesson, we’re going to start with a single-container configuration—but we won’t stop there. Next time, we’ll also explore how to link containers for a more production-ready configuration.

But we’re getting ahead of ourselves. For now, let’s focus on getting our wiki up and running!

Exercise: A Wiki as a Containerized App

Let’s start by creating a new volume that will store the persistent data for our wiki:

docker volume create wiki-data

Now we’re going to run a Docker container based on the official Mediawiki image. We’ll call our new container solo-wiki since it’s going to run in a single-container configuration. We’ll also publish a port so we can access the application on our host machine, and add our volume for persistent storage.

docker run --name solo-wiki -v wiki-data:/wiki-data -p 8000:80 -d mediawiki

Now when we visit localhost:8000 in our web browser, we should see a starting page for our wiki. But the app still needs to be set up. On the starting page, click “Complete the installation.”

Choose your language and Continue.

The installation should pass its environmental checks. Click Continue.

On the database configuration screen, choose SQLite and specify the directory linked to our volume for the data directory—in this case: wiki-data/

Then click Continue.

Now you’ll need to name the wiki and create a username and password for the administrator account. From here, you can go ahead and complete the installation.

You should get a congratulations screen which will automatically download a file called LocalSettings.php to your machine. If it doesn’t do this automatically, click the link.

This file takes many of the settings you’ve chosen—the database type, server, and credentials, for example—and associates them with variables used by the larger app.

Now we need to put the LocalSettings.php file we’ve just downloaded onto our host machine and into the base directory for our wiki installation. There are a number of different ways we could do this—for now, let’s hop into the running container, peek under the hood, and add the file manually. We’ll open a shell session with:

docker exec -it solo-wiki bash

Note where we’ve landed and have a look around:

root@e9537d7c33e3:/var/www/html# ls -1a
.
..
CODE_OF_CONDUCT.md
COPYING
CREDITS
FAQ
HISTORY
INSTALL
README.md
RELEASE-NOTES-1.37
SECURITY
UPGRADE
api.php
autoload.php
cache
composer.json
composer.local.json-sample
docs
extensions
images
img_auth.php
includes
index.php
jsduck.json
languages
load.php
maintenance
mw-config
opensearch_desc.php
resources
rest.php
skins
tests
thumb.php
thumb_handler.php
vendor
wiki-data

This is where we want to put our LocalSettings.php file. One way we can do this is to open the file in a text editor on our host machine, copy the contents, then create a new file in the container:

touch LocalSettings.php

Download nano:

apt update
apt install nano

And paste in the contents. Once we’ve saved the file with CTRL-O and exited to the shell with CTRL-X, we can delete nano with apt remove nano. (This is being very assiduous about optimizing the footprint of our image, but it’s a good habit, and even small differences add up at scale.)

Now we’ve made some changes to the container filesystem itself—changes outside the persistent volume–so in a new terminal tab, we should commit the changes to a new image:

docker commit solo-wiki solo-wiki

Here we’re committing the state of the container named solo-wiki to a new image, also called solo-wiki. With the image saved locally, we can stop and delete the container we’ve been working with:

docker container stop solo-wiki
docker container rm solo-wiki

Now let’s create a new container from the image we just saved, using a command very similar to the first wiki container we ran:

docker run --name solo-wiki -v wiki-data:/wiki-data -p 8000:80 -d solo-wiki

The only thing that will be different this time is that we’re creating our new container from the solo-wiki base image we just committed, with a LocalSettings.php file included–and our volume already has configuration data inside.

When we navigate to localhost:8000 now, we should have a fully configured wiki:

I recommend logging in with your administrator account and making changes to the main page. If you stop and restart the container…

docker container stop solo-wiki
docker container start solo-wiki

…you should find that your changes have persisted.

Now we have a functional containerized app running from a single container. Next time, we’ll continue our survey of container fundamentals by exploring a multi-container configuration for the app.