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
- What is a Container?
- Creating, Observing, and Deleting Containers
- Build Image from Dockerfile
- Using an Image Registry
- Volumes and Persistent Storage
- Container Networking and Opening Container Ports
- Running a Containerized App←You are here
- 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:
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:
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
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.