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.