Deploy the NuoDB Database in Docker Containers
Deploy the NuoDB Database in Docker Containers
NuoDB has made available a NuoDB Docker container running on CentOS 7. Learn how to run it using Brokers, Storage Managers, and Transaction Engines.
Join the DZone community and get the full member experience.Join For Free
Compliant Database DevOps and the role of DevSecOps DevOps is becoming the new normal in application development, and DevSecOps is now entering the picture. By balancing the desire to release code faster with the need for the same code to be secure, it addresses increasing demands for data privacy. But what about the database? How can databases be included in both DevOps and DevSecOps? What additional measures should be considered to achieve truly compliant database DevOps? This whitepaper provides a valuable insight. Get the whitepaper
At NuoDB, we’ve not only been working hard to improve upon on our elastic SQL database engine but also to make it easier for the developer to consume it. NuoDB is a SQL database for cloud-based and container-based environments, 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.
docker pull nuodb/nuodb-ce:3.0.0
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 Autoscaling 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.
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:
Docker inspect broker
Now start the SM and TE. Replace with the docker network IP of your broker.
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
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:
docker exec -it broker /bin/bash
The following command will connect you to your instance of NuoDB:
/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
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
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.
Published at DZone with permission of Ben Higgins , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.