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.

  • running java applications in docker with jboss or tomcat server
  • Docker force container to specific physical interface
  • Docker-compose failing to run a jar file but works with Dockerfile
  • How to set up Cassandra Docker cluster in Marathon with BRIDGE network?
  • Make multiple boot2docker virtual machines
  • docker-machine + openstack: proxy
  • Does anyone have experience with it?

  • Docker container command not found or does not exist
  • ERROR: In file './docker-compose.yml', service 'volumes' must be a mapping not an array
  • “Service cron status” command does not give back the status of cron in the ubuntu docker container
  • Why https is forced?
  • How to forward upstream from nginx to upstream server
  • Checpoint/restore feature not working in Docker
  • 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.