Containers / Data / Contributed

Deploy the NuoDB Database in Docker Containers

16 Oct 2017 8:40am, by

Ben Higgins, DevOps Engineer, NuoDB
As a DevOps Engineer for NuoDB's Product Insights team, Ben Higgins is responsible for developing the tools, automation, and best practices for deploying NuoDB in cloud- and container-based environments, with a particular focus on microservices architectures. Ben has more than 17 years working on cloud technologies, including as a cloud specialist at Rackspace, Attenda, and Pega.

At NuoDB, we’ve not only been working hard to improve upon on our elastic SQL database engine but also on making easier for the developer to consume it. NuoDB is a SQL database for cloud- and container-based environments, one designed to be scalable and fault-tolerant with the ability to do load-balancing across a distributed architecture.

We have made available a NuoDB Docker container running on CentOS 7. The container is available through Docker Hub, and we’ll be continually making updates to improve ease of deployment into every cloud environment. To get a copy of NuoDB, perform a docker pull from the following repo.

Startup commands

If you’re not familiar with NuoDB’s architecture, take a read through our architectural white paper (gated). You can also check out our eBook on how NuoDB and Docker fit (not gated) for a high-level architectural discussion.

The TL;DR version of the architecture is that NuoDB is broken into three components. This allows you to utilize services like AWS’ Auto Scaling Groups or Kubernetes’ autoscaling Pods to increase throughput and high availability of NuoDB’s Transaction Engines (TEs) and Storage Managers (SMs). Because of this, we’ve configured NuoDB to start each component process as its own container.

They don’t have to be located on the same host but will need to be on the same overlay network in order for them to communicate with each other. Alternatively, you can map host ports to the container to connect over the larger network. We also recommend that you place the TE container on the same host as your application. This will allow your application to communicate locally with your cached database with no network hops in between.

Here are the three components of NuoDB:

  • Brokers — for managing the domain state and load balancing for NuoDB.
  • Storage Managers (SMs) — for data archives. SMs are responsible for ensuring data durability and on-disk replication.
  • Transaction Engines (TEs) — as an endpoint and cache of data tables. TEs are in-memory based and manage transaction processing.

Let’s get NuoDB fired up by starting the Broker first. The Broker is the single fixed point for NuoDB and its domain state syncing. The SM and TE need to know where to find the broker at all times so once the Broker container has started, we’ll grab the broker’s Docker network address.

From a command line, run the following. The argument definitions are after the docker run commands.

Grab the IP address of the container by inspecting the container:

Now start the SM and TE. Replace <broker_ip> with the docker network IP of your broker.


 NuoDB’s domain password (superuser).
Port the Broker will listen on. Each container will run a broker and keep a record of the domain state locally.
Node region is used by the Broker to logically load balance based on TE locations. This is useful for multi-region deployments.
Address of the first Broker deployed.
Determines which NuoDB component is being enabled within the container.
Port for TE to listen on.


Connecting to NuoDB

If you have not downloaded and installed the NuoDB binaries locally, you will need to access nuodbmgr within the docker container. First, log into to the docker container using the following command:

The following command will connect you to your instance of NuoDB.

For development and testing your application, you can start up all three NuoDB components within the same container. Here is the run command:

What next?

Now you’ve got a running NuoDB instance running in Docker. From here, there’s a lot more you can do. One note — everything I’ve outlined above is based on transient containers with transient filesystems. For a discussion on persistence in containers, you’ll want to check out this blog, and scroll down to the section titled, “The ‘D’ in Docker does not stand for Durability.”

Our Community Edition (which is what we put on Docker Hub) is licensed for up to three Transaction Engines if you want to scale out your processing. Click here for additional step-by-step information about getting started with NuoDB.

A newsletter digest of the week’s most important stories & analyses.