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.

  • Creating a cassandra docker image with initialized KEYSPACE and schema
  • Docker, Cannot connect to the Docker daemon. Is the docker daemon running on this host?
  • How to mount Docker container volumes to different path?
  • run docker exec on possibly stopped container, so that it would execute without error
  • Updating Docker, Docker Machine, Docker Compose
  • EC2 User Data runs script but does not boot up application
  • Does anyone have experience with it?

  • No such file or directory in docker build
  • Install vim in node Docker image
  • How to find dependencies before installing a PHP extension with Docker
  • Docker: Error creating aufs mounts: Invalid argument (Booting from live usb)
  • supervisor won't give meaningful output
  • AWS Server setup with JIRA, 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.