Docker 1.12 was announced earlier this week at Dockercon. Built-in orchestration was one of the particularly interesting new features. This blog post describes how to deploy one of the Eventuate example applications using Docker orchestration.

Install Docker 1.12 on AWS

The first step was to launch three EC2 instances (a master and two worker nodes) and install Docker 1.12.0. We used an Ubuntu  15.10 AMI and ran this script to install Docker 1.12-rc2 on each instance.

You must also had to configure the security group to allow the nodes to communicate as described in the orchestration tutorial:

• TCP port 2377 for cluster management communications
• TCP and UDP port 7946 for communication among nodes
• TCP and UDP port 4789 for overlay network traffic

You must also allow TCP traffic on port 8080 from your local machine in order to be able to access the running application.

Setting up the Swarm

The next step is to set up the Docker swarm, which is a cluster of Docker engines. To do that run docker swarm init on your master node (pick one). Then, run docker swarm join <masterIp>:2377 on each worker node (the other ones). You can verify that the swarm is set up by running the command docker node ls on the master. This command lists the nodes that comprise the swarm.

Build the application

Once the docker swarm is setup you need to build the Kanban sample application on the master node:

# Install Java: 

apt-get install -y openjdk-8-jdk

# Clone the example:  

git clone https://github.com/eventuate-examples/es-kanban-board.git

# Build it: 

cd es-kanban-board/java-server
./gradlew assemble

# Build the docker images:

./docker/build-images.sh

Note: in order to run this application you need to get for credentials for Eventuate event store.

Create the MongoDB service

This application uses MongoDB and so lets create a MongoDB service.

First, we will create a Docker overlay network that the microservices will use to communicate with MongoDB.

docker network create -d overlay kanbannet

Next, we will create the MongoDB service:

docker service create \
  --name mongo  \
  --network kanbannet \
  --replicas 1 \
  -p 27017:27017/tcp \
  mongo:3.0.4

The service runs the mongo 3.0.4 image. Docker orchestration ensures that one instance of Mongo will be running at all times on a node in the swarm.  The -p parameter says that the service is accessible on port 27017.  

A MongoDB client running on an EC2 instance – one of the swarm nodes or elsewhere – can connect to port 27017 on any of the nodes, i.e. masterOrWorkerNodeIpAddress:27017. The Docker routing mesh  routes traffic to the MongoDB container. A swarm service  uses the service name as the DNS name to access MongoDB, i.e. mongo:27017.

Deploy the service

The next step is to deploy the microservices. Rather than deploy the individual services lets first deploy the monolithic version of the application in order to learn how one service (the Java application) connects to another service (MongoDB).

Here is the command to create that service:

docker service create \
  --name standalone \
  --network kanbannet \
  -e EVENTUATE_API_KEY_ID \
  -e EVENTUATE_API_KEY_SECRET \
  -e SPRING_DATA_MONGODB_URI=mongodb://mongo:27017/kanban \
  -p 8080:8080/tcp \
  eventuate_kanban_standalone_service

This service runs the eventuate_kanban_standalone_service image that was built earlier. The -e options specify the eventuate credentials that you received when you signed up and the connection URL for mongodb. Note that the URL uses the mongo hostname, which is the name of the MongoDB service, and is resolved using Docker built-in DNS server.

The service is accessible via port 8080 on every node. Provided that the security group is configured to allow port 8080 traffic  you should be able to access the application from your desktop/laptop using the URL http://<ec2-instance-hostname&gt;:8080.

You can examine the materialized MongoDB views using the MongoDB CLI. You can run that using the following command:

docker run --rm -i -t --net=host mongo:3.0.4 /usr/bin/mongo \
   --host <masterOrWorkerNodeIpAddress>

Note the user of the –net=host option. I discovered that was required in order for the MongoDB client to connect to the server.

What is next

In a later blog post we’ll describe how we deployed the individual microservices