Stateful Apps and Containers: Squaring the Circle
“Stateful containers” may sound like an oxymoron. That’s because stateful apps—those that require persistent data storage—can seem like odd matches for a container environment. But that’s not necessarily the case.
To date, Docker containers have become popular primarily because they simplify the deployment of stateless apps. Stateless apps are ones that don’t require data storage.
For example, an NGINX web server is a stateless app. The only things the server does is send and receive data. The data itself lives elsewhere. Unless you update the code of NGINX, the app never changes state.
But when you have a stateful app—for instance, a database—that you want to containerize, you run into a problem. Because all of the data inside a Docker container is lost when the container shuts down, there is no out-of-the-box way for changes to an app’s state to persist.
Stateful Container Advantages
Despite these challenges, there are good reasons to want to run a stateful app inside a container. Consider the following advantages:
- More portability. If a stateful app, such as a database, runs in a Docker container, you can migrate that database easily to any other host or cluster that supports Docker. Migrating a database the old-fashioned way is not so simple.
- Environment consistency. Whether your app is stateful or stateless, having a consistent development and deployment environment will be an advantage. Docker containers provide environment consistency, because all Docker environments are (essentially) identical. The same is not true of traditional virtual machines or bare-metal servers.
- Easier deployment. Containers offer turnkey deployment of apps. That’s a big selling point for users, whether they’re dealing with a stateless or stateful app.
Making Stateful Containers a Reality
So, how can you run a stateful app inside a container?
One solution is to try to keep your container running permanently. But that would not work well, for two reasons: First, it would be hard to guarantee the availability of the container; Second (and more important), if you never shut down a container, you lose the flexibility of using containers in the first place.
A better solution is to take advantage of persistent storage solutions. Docker Data Volumes or a distributed file system allow you to map stateful storage inside a container to an external, permanent file system. That way, when the container shuts down, the state of your app can persist.
Making Stateful Containers More Elegant
Admittedly, persistent storage for containers is still a bit clunky. It requires provisioning on the container host. It also may require customization of your container image; you can’t just pull a public container image and go. These limitations undercut some of the advantages containers are supposed to provide.
But things could get better. Hopefully, they will. In an ideal world, an orchestration tool such as Compose or Kubernetes would be able to configure and manage persistent storage for stateful containers as seamlessly and automatically as they manage stateless containers.
That world is not here yet. But it will need to arrive if Docker containers are to deliver on their full promise of making the entire software stack modular. When you can containerize your database as easily as you can your web server, there will be no question as to whether you should run everything inside containers.
