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.

  • Installing rdiff on docker containers
  • Docker Swarm - Map ports and Scaling
  • Understanding code executed after run command in Docker
  • How to get docker container ID within Docker?
  • how to properly build maven/docker with Jenkins?
  • How to include dependencies in .NET Core app docker image?
  • Does anyone have experience with it?

  • How to pass System property to docker containers?
  • Deploy NWJS with docker
  • Mesosphere inter-service communication using Marathon
  • cannot connect: com.github.dockerjava.api.NotFoundException
  • What is the '.save_docker/' folder? Can I delete it?
  • How to run Redis on docker with a different configuration file?
  • 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.