Docker: Dockerize Tomcat application – Best practise

I have a java application which currently runs inside of a tomcat instance. This application has like 3-6 (depending on the use) webapps. I would like to pack this application into a docker container to setup a new test system infrastructure.

What would be the best strategy to do that? Pack every webapp into a tomcat based container and bind it with docker-compose (I would prefer that but I’m not sure if that is even possible?) or have one tomcat based container with all webapps in it.

  • Docker-compose container using host DNS server
  • How to add private registry certs to Docker Machine
  • Why ansible keeps recreating docker containers with state “started”
  • docker build with a template Dockerfile
  • How to write data to host file system from Docker container
  • How can I create a stream for DockerDotNet BuildImageFromDockerfile method?
  • Does anyone have experience with it?

  • Kubernetes on CoreOS: Proxy service max out CPU
  • Docker automated build not showing Dockerfile after completion
  • How to dockerize a node.js talking to a local mongodb
  • ARG or ENV, which one to use in this case?
  • “blkio.throttle.io_serviced” pseudo-files return zero values for one container
  • Dockerfile, how to create images ubuntu 14.04
  • One Solution collect form web for “Docker: Dockerize Tomcat application – Best practise”

    It depends on what you want – there’s no simple answer for what you’re looking for.

    The options I see are:

    • Everything in one container: You copy all of the WAR files/directories into the container when you build your image and then start that. That means that you only have to worry about a single command to start/stop/restart things, but it also means that all applications share the same lifecycle and the same resources (CPU, JVM heap, thread pools, etc.).
    • The alternative is to run something like Docker Compose, where you have a separate image per application, and start a separate container. Using Docker Compose, you can link them together, so they can see each other, and you can start/stop/restart/delete/recreate them as needed. You could even go further and start multiple instances of the same app if required – this will not work with the other approach.

    As you can see, each approach has advantages and disadvantages, it really depends on what you want. The second approach with a single image/container per app is more flexible, but requires more configuration, and has a bit more overhead in that you would be running 6 Tomcat instances instead of just one.

    For what it’s worth, I use the second approach for my use case. I have a base Tomcat image that is shared across all apps, it’s based on the official Docker Tomcat image, and adds a couple of common things. Then each app has its own image with additional configuration, and then I use Docker Compose to pull it all together.

    If you don’t care about the added flexibility and all of your apps will always have the same lifecycle, then the first approach might also work – it all depends and what you’re trying to do.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.