I have a 96G RAM server, I would like to run a few spring boot applications on it. They all need MySql DB.
I have a hard time to decide what is the best way to utilize the server to obtain the best isolation, and performance.
I am thinking of the following:
Now should I run the mysql/spring boot directly within the VM, or run them in docker? I can see no immediate benefit by doing this. But if later on if I need to create a cluster for my apps, then to have a docker images would be better?
Or, if you were me, what would you do?
Thanks
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!
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:8
VOLUME /tmp
ADD spring-boot-0.0.1-SNAPSHOT.jar springboot-appname.jar
RUN 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-imgYou 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:
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.