Docker - Multi Container App

In my last post I used Docker to build and run a simple Spring Boot application. This post will take things a little further by introducing a second container, showing you how distinct components can be deployed in separate containers and how those containers can communicate.

We'll build a simple Spring Boot app with a REST endpoint that takes an incoming message and adds it to an ActiveMQ message queue. A second endpoint will use a receiver component to consume the next message from the queue and return it to the client.  The application itself is simple but it'll provide a pretty realistic use case for how you might use multiple Docker containers during development.
Fig 1.0 - Boot & ActiveMQ - Multi Container App

Application Components

I'm not going to cover the application code in a huge amount of detail but I'll describe the fundamentals components and how they fit together. The MessageController below exposes 2 endpoints, one for posting a message and one for retrieving a message.  I've injected a MessageSender and MessageReceiver which are used to publish messages to and retrieve messages from an ActiveMQ message broker.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@RestController
public class MessageController {

    private final MessageSender messageSender;
    private final MessageReceiver messageReceiver;

    @Autowired
    public MessageController(MessageSender messageSender, MessageReceiver messageReceiver){
       this.messageSender = messageSender;
       this.messageReceiver = messageReceiver;
    }
 
    @RequestMapping(value = "/message/", method = RequestMethod.GET)
    public String retrieveMessage() {
 
       return messageReceiver.retrieveMessage();
    }
  
    @RequestMapping(value = { "/message" }, method = { RequestMethod.POST })
    public void publishMessage(@RequestBody String message) {

       SimpleMessage simpleMessage = new SimpleMessage(message, new Date());
       messageSender.publishMessage(simpleMessage);
    }

}

MessageSender uses a jmsTemplate to send a message to the queue. This method is called from the REST controller to publish the message received via the HTTP endpoint.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@Component
@Slf4j
public class MessageSender {

    private final JmsTemplate jmsTemplate;

    @Autowired
    public MessageSender(JmsTemplate jmsTemplate, MessageConverter messageConverter) {
       this.jmsTemplate = jmsTemplate;
       this.jmsTemplate.setMessageConverter(messageConverter);  
    }

    public void publishMessage(SimpleMessage simpleMessage){
  
       log.info("Sending message to queue: {}", simpleMessage.toString());
       jmsTemplate.convertAndSend("TestQueue", simpleMessage);
    }
 
}

MesssageReceiver uses a JmsTemplate to retrieve a message from the queue. The retrieveMessage method is invoked by the REST controller which will return the message to the client. 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@Component
@Slf4j
public class MessageReceiver {

    private final JmsTemplate jmsTemplate;

    @Autowired
    public MessageReceiver(JmsTemplate jmsTemplate, MessageConverter messageConverter) {
       this.jmsTemplate = jmsTemplate;
       this.jmsTemplate.setMessageConverter(messageConverter);
    }

    public String retrieveMessage() {

       String message = (String) jmsTemplate.receiveAndConvert("TestQueue");
       log.info("Retrieved message from queue: {}", message);
       return message;
    }
}

SimpleMessageConverter is used by the MessageSender and MessageReceiver components to do some simple transformation. MessageSender uses this class to convert a simple message POJO to a String before publishing to the queue. MessageReceiver uses this class to extract the message String from the Message returned from the queue.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
@Component
public class SimpleMessageConverter implements MessageConverter {

    @Override
    public Message toMessage(Object messageObject, Session session) throws JMSException, MessageConversionException {

       SimpleMessage simpleMessage = (SimpleMessage) messageObject;
       MapMessage message = session.createMapMessage();
       message.setString("message", simpleMessage.toString());
       return message;
    }

    @Override
    public Object fromMessage(Message message) throws JMSException, MessageConversionException {

       MapMessage mapMessage = (MapMessage) message;
       return mapMessage.getString("message");
    }

The application.properties below contains a single property that defines the message broker URL. We'll see later that the host name value (activemq) is significant when we come to linking Docker containers.

Running ActiveMQ

Now that we've defined the app lets look at setting up ActiveMQ. We need an ActiveMQ instance with a single queue definition called TestQueue. Remember that we reference TestQueue  as the destination in MessageSender and MessageReceiver. To save you time I've already created such a Docker image and pushed it to DockerHub.  Running the command below will pull the image from DockerHub and start a container.

1
docker run --name activemq -p 8161:8161 briansjavablog/activemq

The --name flag allows us to provide a name for the container we're starting. We'll use this name later when we are linking the app container to this ActiveMQ container.  The -p 8161:8161 tells Docker to expose port 8161 to the host machine on port 8161. This is required so that we can access the message broker admin console when it starts and check that the message queue is configured and ready to use. When the container starts up open a browser and go to http://localhost:8161/admin/queues.jsp. You should see a single queue defined as shown below.

Fig 1.1 - ActiveMQ Queue Definition

Building the Application Image

We'll start by defining a simple Dockerfile that takes a pre built JAR from the target directory and adds it to the image. The ENTRYPOINT tells Docker to run the executable JAR on container startup.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
FROM anapsix/docker-oracle-java8

# Creating working directory
WORKDIR /app

# Add src to working directory
ADD target/docker-boot-activemq-0.1.0.jar /app/docker-boot-activemq-0.1.0.jar

# Start app
ENTRYPOINT ["java","-jar","/app/docker-boot-activemq-0.1.0.jar"]

To create an image form the Dockerfile simply run docker build -t "docker-activemq" . as shown below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
brianh@brianh-VirtualBox:~/apps/docker-boot-activemq$ docker build -t "docker-activemq" .
Sending build context to Docker daemon 19.98 MB
Step 1 : FROM anapsix/docker-oracle-java8
 ---> a8a9dcb0ac64
Step 2 : WORKDIR /app
 ---> Using cache
 ---> 4a5482ed5d76
Step 3 : ADD target/docker-boot-activemq-0.1.0.jar /app/docker-boot-activemq-0.1.0.jar
 ---> 4dd383ddc5aa
Removing intermediate container b720dc09ee95
Step 4 : ENTRYPOINT java -jar /app/docker-boot-activemq-0.1.0.jar
 ---> Running in 398ca91a7205
 ---> 74e632bb7020
Removing intermediate container 398ca91a7205
Successfully built 74e632bb7020

Linking Containers

If you've followed the steps so far, you should have an ActiveMQ container up and running and an application image built and ready to run. We're now going to start a second container to run our application and link it to the ActiveMQ container we started earlier. 

1
docker run -p 8080:8080 --link activemq:activemq docker-activemq
  • -p 8080:8080 exposes port 8080 on the container to port 8080 on the host machine. This is required as the Boot app will start on container port 8080 as soon as the image is started.
  • --link activemq:activemq defines the container we want to link to and an alias that we can use to reference it. In this case we are linking to the activemq container we started earlier.
  • docker-activemq is the name of the application Docker image we built earlier.,
When we defined the message broker URL earlier in application.properties, we set the URL as follows.

1
spring.activemq.brokerurl=tcp://activemq:61616

So how does the app container know how to resolve the above URL to a service exposed in another container? To see how, we're going to open a shell in the app container and have a look. After the app container has started run the following from another terminal window. Note that the value inside quotes is the ID of the application container. To get the container ID run docker ps.

1
docker exec -it "1a4db2b586c3" bash

You should now have shell access to the app image and your current working directory should be /app. Remember /app is the working directory we created earlier to add the JAR to. Now lets take a look at the hosts file. Simply run vi /etc/hosts as shown below.

1
2
3
root@1a4db2b586c3:/app# ls
docker-boot-activemq-0.1.0.jar
root@1a4db2b586c3:/app# vi /etc/hosts

On container startup when we specified the --link command we supplied the container we wanted to link to and an alias that we'd use to reference it. Docker used that alias to create a hosts entry (line 7) to map the container alias activemq to the IP of the activemq container.

1
2
3
4
5
6
7
8
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2      activemq fa0b6f943d62
172.17.0.3      1a4db2b586c3

When the application in one container attempts to connect to ActivceMQ in the other container, the broker URL tcp://activemq:61616 will resolve to tcp://172.17.0.2:61616. To check that this IP address is indeed the IP address of the ActiveMQ container run the following command.

1
2
brianh@brianh-VirtualBox:~$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' fa0b6f943d62
172.17.0.2

Testing the Application

Now that we've started and established a link between the application and ActiveMQ containers, its time to test it. Post a message to the MessageController endpoint using CURL as follows.

1
curl -i -H "Content-Type: application/json" -X POST -d "Test Message 1" localhost:8080/message/

In the app logs you should see a message saying that the message was added to the queue.

1
2016-08-10 17:44:52.789  INFO 1 --- [nio-8080-exec-1] com.blog.sample.app.mq.MessageSender     : Sending message to queue: SimpleMessage(message=Test Message 1, creationTime=Wed Aug 10 17:44:52 UTC 2016)

You can confirm that the message is indeed on the queue by opening the ActiveMQ admin console.
To retrieve the message from the queue, run curl -i localhost:8080/message/.

1
2
3
4
5
6
7
brianh@brianh-VirtualBox:~$ curl -i localhost:8080/message/
HTTP/1.1 200 
Content-Type: text/plain;charset=UTF-8
Content-Length: 80
Date: Thu, 11 Aug 2016 06:44:51 GMT

SimpleMessage(message=Test Message 1, creationTime=Wed Aug 10 17:44:52 UTC 2016)brianh@brianh-VirtualBox:~$


Source Code

The full source code for this post can be found on Github and the ActiveMQ image is available on DockerHub. As always, if you have any questions, comments or suggestions please leave a note below.

Comments

Post a Comment

Popular posts from this blog

Spring Web Services Tutorial

Image
Update
I've recently written a more up to date version of this post which describes how to build a contract first web service using Apache CXF. Check it out here.

Introduction
Modern enterprise applications are rarely stand alone and often rely on data and services provided by external systems. In order for different types of systems to communicate there must be a  communication protocol of some sort, a standard way of sending and receiving messages in a format that is recognised and supported by all major platforms. SOAP (Simple Object Application Protocol) is such a protocol, and allows applications to communicate by exchanging messages in a standard XML format.
SOAP Web Services provide a platform agnostic integration mechanism that allows disparate systems to exchange data regardless of the platform they are running on. For example, SOAP web services are commonly used to integrate .NET applications with applications running on the Java platform. Almost all modern platforms and …
Read more

REST Endpoint Testing With MockMvc

In this post I'm going to show you how to test a Spring MVC Rest endpoint without deploying your application to a server. In the past, full integration tests were the only meaningful way to test a Spring REST endpoint. This involved spinning up a test server like Tomcat or Jetty, deploying the application, calling the test endpoint, running some assertions and then terminating the server. While this is an effective way to test an endpoint, it isn't particularly fast. We're forced to wait while the entire application is stood up, just to test a single endpoint.
An alternative approach is to unit test by manually instantiating the Controller and mocking out any required dependencies.  While such a test will run much faster than a full integration test, its of limited value. The problem is that by manually instantiating the Controller we're bypassing Springs Dispatcher Servlet, and as a result missing out on core features like
request URL mapping request deserialization re…
Read more

An Introduction to Wiremock

This post provides a brief introduction to Wiremock, showing how it can be used to to quickly and easily mock remote API calls. We'll use Wiremock to write some integration tests for a simple Dropwizard app and show you how it can be put to use in a real world scenario.

Why would I need to mock external API calls? There are a number of scenarios where it makes sense to mock an external API rather than call a live service.
The external API may still be in development and not yet available for integration. In this instance as long as a data contract has been defined (e.g. Swagger spec, WSDL), the remote API can be stubbed based on the data contract. Stubbed endpoints allows a team to continue development even when external APIs isn't fully implemented.You may have little or no control over the external API uptime in development or test.  As a result you cannot guarantee it will be available to call when running integration tests. In this instance it makes sense to use mocked respo…
Read more

Spring Batch Tutorial

Image
Introduction Spring batch is a lightweight framework that provides a solid foundation on which to build robust and scalable batch applications. It provides developers with a set of tried and tested patterns that solve common batch problems and allows developers to focus more on the business requirement and less on complex batch infrastructure. Spring batch contains a variety of out of the box configurable components that can be used to satisfy many of the most common batch use cases. Extensive XML configuration and an extensible programming model mean that these components can be customised and used as building blocks to quickly deliver common batch functionality.
This tutorial will show you how to build a very simple batch application to read fixed length data from a flat file and write it to a database table. This is a common batch use case and should be sufficient to demonstrate some of the fundamental concepts of Spring batch and provide you with a foundation on which to build mor…
Read more

Externalising Spring Configuration

Enterprise applications typically contain a number of  properties and  runtime resources that must be configured before the application is deployed. Property and resource values can either be baked into the artefact at build time using something like Maven Profiles or derived at runtime using Spring Profiles. My preferred approach is to externalise all configuration so that the artefact taken from the build server is environment agnostic and can be deployed onto any environment . For example, we could take a WAR file from our build server and  deploy it to our development, UAT or production environments without changing any configuration in the WAR file itself.

Spring Property Configuration Spring applications use the PropertyPlaceholderConfigurer to load application properties. Property files are typically loaded from the class path but the example below uses a slightly different approach, loading the properties file from a directory outside of the application itself. This allows the…
Read more

Docker & Spring Boot

Docker allows you to package an application with its dependencies, into a light weight, portable container that can run on almost any environment.  You can think of a Docker container as a run time, a mini virtual machine that encapsulates your application and its dependencies.
In order to run a container you need a Docker image. An image is like a template that defines everything that will exist within the container. You can almost think of an container as a run time instance of the image it was created from. In this post we'll define and build 3 slightly different Docker images that run a simple Java app.

Installing Docker If you haven't already done so you'll need to install Docker. The official documentation is pretty good so following it step by step should see you up and running in about 15 minutes.
I've installed Docker on Windows and Ubuntu but to be honest I prefer running it on Ubuntu and have found it a bit more reliable than with Docker Toolbox on Windows.��…
Read more

jQuery Tables

Introduction
This post will show you how to create rich data grids using the DataTables plugin for jQuery. DataTables is a flexible framework that allows you to create grids using a variety of data sources. This tutorial will show you how DataTables can be used with DOM and JavaScript data sources.

DOM Data Source
The simplest way to use DataTables is with a DOM data source. This approach simply 'decorates' an existing HTML table and is ideal for enhancing plain HTML tables created using template languages like JSP or Velocity.

MakeModelBody ShapeEngine Size (Cubic Capacity)Horse PowerBMW320dSaloon2000181BMW330dCoupe3000231BMW335dEstate3000286BMW335iSaloon3000306BMWM3Coupe4000415BMW520dSaloon2000181BMW530dSaloon3000231BMW535dEstate3000286BMW535iSaloon4000306BMWM5Saloon5000508
To turn this rather dull looking HTML table into a rich data grid we simply decorate the table on document load.
1: <script type="text/javascript"> 2: $(document).ready(func…
Read more

Health Checks, Metrics & More with Spring Boot Actuator

Image
I've been working with Spring Boot for a few years now and I'm a big fan. There are lots of things to like about Spring Boot, but one thing that really stands out for me is the emphasis on production readiness.
Production Readiness Production readiness is about looking beyond functional requirements and ensuring your application can be properly managed and monitored in production. Some key things to consider when thinking about production readiness are...
Health checksViewing application configuration - application properties, Environment variables etc. Viewing and altering log configurationViewing application metrics - JVM, classloader, threading and garbage collection. Audibility of key application events Spring provides all of this functionality out of the box via Spring Boot Actuator, a sub project of Spring Boot. A range of RESTful management and monitoring endpoints are provided so you don't have to implement these features each time you build an application. To enable…
Read more

Axis2 Web Service Client Tutorial

Image
Introduction
Axis2 is a Java framework that provides comprehensive support for exposing and consuming web services. This short post will look at its SOAP client support and how it can be used to get a simple web service client up and running.
For convenience I'm going to be calling a web service that I recently built as part of another blog post.  If you don't already have a web service to call you can grab the full source code for my sample service from github. Simply run a Maven build and deploy the WAR to your Servlet container.

What is a Web Service Client
This post doesn't attempt to explain the detailed inner workings of a web service client, but its still pretty useful to have an idea of what's going on under the hood. Most web service clients provide the following
A client side proxy for the remote service we want to call, that allows our application to invoke a SOAP service using a simple method call. The proxy insulates our application from the intricacies of s…
Read more