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.
1 | docker pull nuodb/nuodb–ce:3.0.0 |
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.
1 2 3 4 5 6 7 8 9 10 | docker run –d –e “DOMAIN_PASSWORD=bird” –e “NODE_TYPE=BROKER” –e “BROKER_PORT=48004” –e “NODE_REGION=local” –e “AGENT_PORT=48004” –p 48004:48004 –p 8888:8888 —name broker nuodb/nuodb–ce:3.0.0 |
Grab the IP address of the container by inspecting the container:
1 | Docker inspect broker |
Now start the SM and TE. Replace <broker_ip> with the docker network IP of your broker.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | docker run –d –e “DOMAIN_PASSWORD=bird” –e “BROKER_PORT=48004” –e “NODE_REGION=local” –e “PEER_ADDRESS=<broker_ip>” –e “AGENT_PORT=48004” –e “NODE_TYPE=SM” –e “NODE_PORT=48005” —name sm nuodb/nuodb–ce:3.0.0 docker run –d –e “DOMAIN_PASSWORD=bird” –e “BROKER_PORT=48004” –e “NODE_REGION=local” –e “PEER_ADDRESS=<broker_ip>” –e “NODE_TYPE=TE” –e “NODE_PORT=48005” –e “AGENT_PORT=48004” –p 48005:48005 —name TE nuodb/nuodb–ce:3.0.0 |
Arguments:
| 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:
1 | docker exec –it broker /bin/bash |
The following command will connect you to your instance of NuoDB.
1 | /opt/nuodb/bin/nuodbmgr —broker localhost —password bird |
For development and testing your application, you can start up all three NuoDB components within the same container. Here is the run command:
1 2 3 4 5 6 7 8 9 | docker run –d –e “DOMAIN_PASSWORD=bird” –e “AGENT_PORT=48004” –e “NODE_TYPE=ALL” –e “BROKER_PORT=48004” –e “NODE_REGION=aws” –p 48004:48004 –p 8888:8888 nuodb/nuodb–ce:3.0.0 |
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.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
