Month: June 2016

Deploying Spring Boot microservices using Docker 1.12 orchestration – part 1

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

# Build it: 

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

# Build the docker images:


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 \

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 SPRING_DATA_MONGODB_URI=mongodb://mongo:27017/kanban \
  -p 8080:8080/tcp \

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

Learn more about Eventuate

To find out more about Eventuate:







Successful software development = organization + process + architecture #gluecon

Successful software development requires the right organizational structure, development processes, and software architecture.


Fred Brooks in his book the Mythical Man Month describes how the communication overhead for a team of size n is n(n – 1)/2. Consequently, a software development organization should either be a small team, or  a collection of small, autonomous teams. Amazon, for example,  famously organize around two pizza teams. Pizzas are an ambiguous unit of measurement but probably each team should be 6-10 people.

Despite rumors of the death of agile,  it almost always makes sense to use an agile development process.  Teams should do continuous delivery or, ideally, continuous deployment. Small, agile and autonomous teams can move fast (without breaking things) and keep up with the needs of the business. But what about the software architecture?

For small, simple applications the monolithic architecture often the best choice.  Development is simple, testing is easier and the application is easier to deploy and manage. However, successful application have a habit of growing and your monolithic application will become  large and complex. It will become extremely difficult to develop and deploy in an agile fashion. Teams are no longer autonomous. Delivering software will require lengthy merges and excessive amounts of communication and coordination. You will likely end up in monolithic hell.

Once your application becomes large you will need to adopt the microservices architecture. You functionally decompose what would otherwise be a monolith into a set of small applications or services. Each team owns one or more services. Each service has its own private data in order to ensure loose coupling. This architecture enables the teams to be agile and autonomous.

To learn more about microservices

Take a look at our founder, Chris Richardson’s recent talk at Gluecon on a microservices pattern language.

Learn more about Eventuate

To find out more about Eventuate: