Running Spring boot application in a container? or a VM? or a container inside a VM? [closed] Running Spring boot application in a container? or a VM? or a container inside a VM? [closed] kubernetes kubernetes

Running Spring boot application in a container? or a VM? or a container inside a VM? [closed]


What you are looking for is called Docker Swarm. It allows you to deploy dockers (efficient virtual containers) and scale them with any effort.

To "dockerize" your spring boot applications, you only have to build an image with a Dockerfile, like this:

FROM java:8VOLUME /tmpADD spring-boot-0.0.1-SNAPSHOT.jar springboot-appname.jarRUN bash -c 'touch /springboot-appname.jar'ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/springboot-appname.jar"]

To build this image, execute:

docker build -t name-application-img .

To deploy the image as a service inside the Docker Swarm, use:

docker service create -p {exposed-port}:{private-port} --name {service-name} --replicas 1  name-application-img


You want best isolation and performance?

Trust the isolation provided by your Docker container. It's a primary design objective.
Don't add unnecessary layers (i.e. a VM inside which to host your Docker container) — adding a VM layer would incur performance impact, and it sounds like you don't have to.

Containerising MySQL requires thought, since it's inherently stateful.
If you wanted to do this: I'd at least store the state (data and maybe config) outside of the container.

You could get away with not containerising MySQL. I don't feel that databases are a good fit for the containerisation use-case, because:

  • they're stateful
  • scaling is not as trivial as "spin up another instance" (because you have to establish slaving, and synchronise and store a lot of state)
  • they don't undergo updates often
  • updates are not as trivial as "swap to the newer version of the container"
  • there's less requirement to "use the same version in all environments" (i.e. devs using MariaDB 5.7 locally, despite production's using MySQL 5.6… this is moreorless fine)

You should also consider using a managed database such as Amazon RDS. I recognise that you've a high-performance computer that you want to make use of, but it's worth weighing that up against the operational costs of maintaining and scaling the infrastructure yourself.

And yes: I'd make a container per Spring Boot application, and run those containers directly. As I said: trust Docker's isolation — or at least look up whether it's been breached, and whether that's an acceptable risk according to your threat model (and whether a VM would've saved you in any reported cases of vulnerability).

As for where to deploy those Docker containers (i.e. locally on your Fast Computer, versus deploying to the cloud): depends whether you want to optimize for operational costs (i.e. it's easier to manage everything on the cloud and not have to interact with any physical machinery) or try to make the most of your Fast Computer (and deploy everything directly to that computer).

Presumably there's some way to remotely manage the orchestration of the Docker containers on your Fast Computer. That could give you a lot of the benefits of deploying to cloud.


You can create Docker images of Spring Boot applications, they are so easy to build and scale up and down. Why not even move MySQL too as a Docker image and map the volume to your disk. If you have all applications inside docker they will be easy to manage ( through a docker-compose).

However, the downside is that if you have more than one container of MySQL-DB then you have to worry about data replication and maintaining the same state of DB across multiple DB containers

If I was you I would just dockerize the Spring Boot apps!