Best practice for Jenkins docker to deploy to other container
Where you say:


  Building the docker container from another docker container is also
  said to be bad practice and I also understand the reasoning for that,
  so that's a no-go, too.


Perhaps there are bad ways of doing that but it can be a solid pattern. By way of example if you use openshift Kubernetes it runs s2i as builder images on your cluster. s2i checks out your code from git, compiles it, and pushes it to a new layer in your docker repo. It has an incremental flag where it will tar up your library deps folders at the end of a build and store as a docker layer. Then the next time you build it does a clean checkout then untars the libraries from the last build. That speeds up the next build a lot as it has the local maven cache from the last build. It also means the s2i build container can be launched on a different host in the cluster at each execution and it just connects to git and the central container registry and does a fast repeatable build. 

s2i is a stand alone tool that can use your local docker demon. So it acts as a single commandline ”compile my stuff into an updated docker image”. There are community supported s2i images for php7, node.js, Java etc. I recall that the java s2i will run a maven build with the “openshift” profile and expects your to copy the built WAR to “./deployment”. When you run the image that s2i writes out to your container registry it launches wildfly that is in the base layers and it deploys whatever finds in the deployment folder (but double check its been a while since I looked at it). 

In your case If you are using Jenkins I suggest you take advantage that it supports building docker images. Append a docker pipeline step to create your image and push it to your chosen container registry. Enterprises that use Jenkins to build and Nexus for storing JARs and WARs are now using Nexus as their container registry. They can stick with Jenkins and Nexus and simply reconfiguration things to move into the world of containers. 

I should also point out that you can be more “microservice-like” by skipping installing tomcat. You can use maven jetty plugin or maven tomcat plugin to just run the code with “mvn jetty:run” or “mvn tomcat7:run”. You can set a full blown config file for the servlet container via the plugins. Maven let's your set whatever jvm options you want. (note: after Tomcat 7 there doesn't seem to be support for this modern approach see the next paragraph where the mainstream now uses Jetty for this). 

If you like spring you can use spring boot to build an excutable JAR that runs your webapp. The JAR will be large as it has everything to run the webapp including the servlet container packed into a single JAR. You can run it as “java -jar” and it runs your webapp in an embedded servlet container. Better yet configure it's maven plugin to make an executable jar you can simply run as “./my-app-1.0.0.jar” and it will lunch. That makes building a docker image trivial. You don’t have to install tomcat you only need a container with Java on it and copy in your spring boot executable JAR and run it as the CMD. Spring Boot is very mainstream for Java microservices and it runs Jetty under the bonnet.