Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Best Practices for Virtualized Platforms provides best practices for running Couchbase on a virtualized platform like Amazon Web Services and Azure. In addition, it also provides some recommendations for running it as Docker container.

One of the recommendations is to map Couchbase node specific data to a local folder. Let’s understand that in more detail.

A new directory is created for a new run of the container. This directory is still around when the container is stopped and removed but no longer easily accessible. Thus no data is preserved across container restarts.

The volume can be explicitly removed, along with container, using the command:

docker rm -v db

If the container terminates then the entire state of the application is lost.

Explicit Host Directory Mapping

This container is very similar to the container started earlier. The main difference is that a directory from host
~/couchbase is mapped to a directory in the container
/opt/couchbase/var.

Couchbase container persists any data in /opt/couchbase/var directory in the container filesystem. Now that directory is mapped to a directory on the host filesystem. This allows to persist state of the container outside on the host filesystem. The bypasses the union filesystem used by Docker and exposes the host filesystem to the container. This allows the state to persist across container restarts. The new container only needs to start with the exact same volume mapping.

More details about the container can be seen as:

docker inspect --format '{{json .Mounts }}' db | jq

jq is a JSON processor that needs to be installed separately. And the output is shown as:

Data Buckets tab will show the same two buckets in the Couchbase Web Console.

In this case, if the container is started on a different host then the state would not be available. Or if the host dies then the state is lost.

An alternative and a more robust and foolproof way to manage persistence in containers is using a shared network filesystem such as Ceph, GlusterFS, or Network Filesystem. Some other common approaches are to use Docker Volume Plugins like Flocker from ClusterHQ or Software Defined Storage such as PortWorx. All of these storage techniques simplify how the state of a container can be saved in a multi-container multi-host environment. A future blog will cover these techniques in detail.