QuickStart

At this point go to http://localhost:8091 from the host machine to see the Admin Console web UI. More details and screenshots are given below in the Single host, single container section.

Background Information

Networking

Couchbase Server communicates on a number of different ports (see the Couchbase Server documentation). It also is not generally supported for nodes in a cluster to be behind any kind of NAT. For these reasons, Docker's default networking configuration is not ideally suited to Couchbase Server deployments.

There are several deployment scenarios which this Docker image can easily support. These will be detailed below, along with recommended network arrangements for each.

Volumes

A Couchbase Server Docker container will write all persistent and node-specific data under the directory /opt/couchbase/var. We recommend mapping this directory to a directory on the host filesystem (using the -v option to docker run) for the following reasons:

Persistence Storing /opt/couchbase/var outside the container allows you to delete the container and re-create it later. You can even update to a container running a later point release of Couchbase Server without losing your data.

Performance In a standard Docker environment using a union filesystem, leaving /opt/couchbase/var "inside" the container will result in some amount of performance degradation.

All of the example commands below will assume you are using volumes mapped to host directories.

SELinux workaround

If you have SELinux enabled, mounting host volumes in a container requires an extra step. Assuming you are mounting the ~/couchbase directory on the host filesystem, you will need to run the following command once before running your first container on that host:

Since unlimited is not supported as a value, it sets the core and memlock values to 100 GB. If your system has more than 100 GB RAM, you will want to increase this value to match the available RAM on the system.

This is a quick way to try out Couchbase Server on your own machine with no installation overhead - just download and run. In this case, any networking configuration will work; the only real requirement is that port 8091 be exposed so that you can access the Couchbase Admin Console.

Useful for testing out a multi-node cluster on your local workstation.

Not recommended for production use. (the norm for a production cluster is that each node runs on dedicated hardware)

Allows you to experiment with cluster rebalancing and failover.

The networking is effectively the same as described the Software-Defined Network section: each container is given an internal IP address by Docker, and each of these IPs is visible to all other containers running on the same host

Internal IPs should be used in the Admin Console when adding new nodes to the cluster

For external access to the admin console, you should expose port 8091 of exactly one of the containers when you start it.

You can choose to mount /opt/couchbase/var from the host, however you must give each container a separate host directory.

This is a typical Couchbase Server cluster, where each node runs on a dedicated host, presumably in the same datacenter with high speed network links between them. We assume that the datacenter LAN configuration allows each host in the cluster to see each other host via known IPs.

Currently, the only supported approach for Couchbase Server on this deployment architecture is to use the --net=host flag.

Using the --net=host flag will have the following effects:

The container will use the host's own networking stack, and bind directly to ports on the host.

Removes networking complications with Couchbase Server being behind a NAT.

From a networking perspective, it is effectively the same as running Couchbase Server directly on the host.

There is no need to use -p to "expose" any ports. Each container will use the IP address(es) of its host.

Increased efficiency, as there will be no Docker-imposed networking overhead.