Docker Community Forums

Share and learn in the Docker community.

Does a microservice need its own docker container

docker

(Drewjocham) #1

I am going to get so many different opinions, so I will be clear as possible.

Let’s take for example we have a check out cart, in that cart I have several services, each microservice will communicate (stateless) a consumer polling approach.

My question is does each microservice need its own docker container? In the end it is a cart, but now I am confused because in order talk to other containers we have to set ports, this can be conflicting and we have to send messages, and each microservice might use a different technology like solar, and maybe one uses a relational DB and another mongoDB all in the same cart and sending messages to AI purposes or machine learning. Then we have a gateway to the client and all they see is a cart.

If each container is its own docker container, it is likely one will be used more than another, how will that scale?

Yes google is my friend but I can’t seem to wrap my head around it clearly. JHipster is a good read and technology but I wanted some clear answers.


(Sam) #2

forget about docker for a moment.

how would you design this with real systems?

how much would be together and separate.
think about maintenance, and reliability.

suppose you have it running, and tomorrow I said, ok, we are moving to the cloud.
what would you have to do… how much re-invention and reinstall and retest.

now… assuming you have 2 systems… the ‘api’ front end with business logic, and the DB back end,
running as two systems… you could make those as docker containers, and then transport them (unchanged) to a supporting cloud provider. no new install, configure, test…

and how would u scale this, add another ‘api’ host? with a real machine?

you could use docker swarm for the front end (or amazon Elastic container service, ECS), and NOT have to change anything, again…

careful system design and packaging, thats where docker really provides value…
don’t make every service a container, UNLESS there is a GOOD technical or business reason to do it.


(Witsec) #3

Running more than one process per container goes against the principal, doesn’t it? Also, if you’re using healthchecks inside your container, what process will you be monitoring?

Running more than one process inside a container would be fine if you’re modernizing your traditional apps (MTA), where you “drag and drop” apps “as they are” in an image, but I’d say the goal should be to give each service its own container.


(Sam) #4

you can do microservice on the same url with a path. so only one process…

but, yes, that is something to consider… and healthchecks too…


(Detromper) #5

The idea of running several microservices on one container in funny as hell - you need fault tolerance so if one of the container is down, your service continues to work. As for scalabilty - adding another node to a docker swarm is cheaper than anything, especially if you work in a company of 3+ people and can afford a single dedicated devops.
As for the service discovery this problem was more or less solved long ago.
Regarding microservices on the same url it’s achieved by putting containers behind balancer - HAProxy or nginx - not by putting everything on a single linux server.
You can read more here https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container

TL;DR; containers are extra cheap - the whole point of docker is to have an environment dedicated for a specific task