Docker Base Image with Tomcat+Spring-Boot and config share mechanism - spring-boot

Question

I am a docker newbie seeking ideas.
For a usecase where i need to use tomcat as app server and on top of it add custom spring-boot code and make it a container. Should i be doing that using multi-stage docker build mechanism?
Is it ok to have a base tomcat image and then spring boot image on top of it. OR just put spring boot code into tomcat image and use it in container?
Also i have usecase where spring-boot code will have to connect to external DB (outside image) and want to know best way to have connection pool strategy as i want connections be managed centrally.
Two schools of thoughts -
First is to use docker volumes as i do not want team to use config parameters/environment variables set every time?
Second - have connection pool per docker container so total number of connections are divided by container running (this is risky as autoscaling will take place using Kubernetes)

Answer 1

You have a bunch of questions here - I will start with the most central one.
Deploying Spring Boot Applications in a docker container
If you are deploying Spring Boot applications in docker containers, then there really is no need to use the tomcat image. You just need a java runtime environment in your image, since with Spring Boot you can embed a web server in your fat .jar.
You should be using the spring-boot-starter-web in your project, this will embed the webserver:
Maven example with spring-boot-starter-web - 2.1.3.RELEASE
Add this dependency in your pom.xml (Let spring manage the dependencies by the way, this is just the latest one I am linking here):
<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
With this, your Dockerfile will become a lot simpler:
Dockerfile
FROM openjdk:8-jdk-alpine
COPY build/libs/myfatjar.jar /app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
Check this guide from spring.io, it goes into the process in detail and outlines your options.
Multistage docker build for Spring Boot application?
I would say that there is little to no need to do this. I will sketch out a few common scenarios here:
Build the fat jar on your dev machine, and then build the image there aswell. Push the image to a registry and deploy from there.
Use a docker image to build your application locally, then build the application image locally, push to a registry and deploy.
If you are using Jenkins, GitLab or some other mechanism to build your image, they will be responsible for building both the application and the final docker image in the same pipeline. There is no need for a multistage build.
Unless you have something specific that requires you to base your application image off of another image - there is no need that I can identify.
Connecting to multiple databases from a Spring Boot application
This is basically no problem. Even though it is considered doubtful practice to simply link external content in an answer - I will do it here. Check this article from Baeldung on multiple databases.
I am not sure what you mean by, that you want the connections managed centrally? Do you have a requirement to have database connections managed outside the Spring Boot application context? That is an antiquated school of thought in my oppinion, at least when dealing with Spring Boot.
But if you are dealing with multiple Spring Boot applications that connect to the same database - then you should consider a distributed cache setup. Like Hazelcast, Infinispan or Memcached.
Binding docker volumes in Spring Boot application container, for configuration
Well, I think I understand what you are talking about here. Generally the preferred mode of injecting configuration into a docker container, and into a Spring Boot application - is to use environment variables. Or Spring Cloud config. Environment variables are particular nice here, because the container can be parameterized with them, and they can be used directly in the properties files that are loaded by your Spring Boot application. And find their way directly into your #Value annotated fields.
However, for a microservice setup with new service instances spawning every now and again, and need to find their configuration - I would advice you to look into Spring Cloud config.
With Spring Cloud cofig, you are essentially introducing a new service into your setup, that is responsible for hosting the configuration of your services. This service is a docker container and a Spring Boot application on its own. And, your other Spring Boot applications will have an easy time utilizing it.
So, basically I would advice against starting to mess around with injecting configuration by mounting it into containers in a docker volume.
I hope I have addressed all of your questions? Otherwise let me know in a comment.