How to Compose Docker Containers for Spring, Angular, and Django Microservices Backed by PostgreSQL

Like most of these kind of questions regarding deployment "it depends" but let me try to answer.Lest first see the differences:

Docker compose vs (Docker swarm or Kubernetes)

The most important difference which you need to acknowledge is that docker compose can run your multi container application on a Single Host only. It can not run your application on cluster of computers. If you have to run your application on a cluster you can remove the option to use docker compose for that. For this you will need to use either Docker swarm or Kubernetes.You can read more about it here and here.

Docker swarm vs Kubernetes

In short they are both container orchestration solutions. This means that you would use them to orchestrate your containers in a cluster. Both of them tend to be solving the same problem but in a different way. Both of them are used for:

• container orchestration across the cluster
• scaling containers
• load balancing containers
• communication between containers
• and many more. In This answer you can see the summary of the comparison of them.

One of the benefits if you decide to use docker swarm is that the CLI tooling used for docker swarm will very similar to the standard Docker cli with some additional options. So setting it up and using can be much easier if you are familiar with docker command line.Also you can use your docker compose yaml file to run on swarm directly. You can read about it here and here.

Kubernetes on the other hand is very powerful and is supported by all major cloud providers like: AWS, Azure and Google Cloud. It is:

• open source
• backed by the Cloud Native Computing Foundation (CNCF)
• has a big community supporting it
• can be used with other container solutions(not only docker)

If you would use use Kubernetes keep in mind that you will need to learn a separate tools for managing it including kubectl CLI.

There are pros and cons for using both but my suggestion would be to use Kubernetes if you are deploying your solution on the cloud and aim to be cloud agnostic as much as possible.

What is the best approach for production-based deployments of such platform?

Knowing only the infos that you gave us here I would say it depends also where you plan to deploy it:

• On some cloud provider like AWS, Azure, Google Cloud or some other?
• On non cloud provider but still multiple servers or on some cluster of servers?
• On one dedicated server for all of your components?

On some cloud provider like AWS, Azure, Google Cloud or some other?

If you are using some cloud provider and you plan to deploy it there then I would suggest using Kubernetes as the major cloud providers have a very good support for it and you can port it to another cloud provider if needed.I would also suggest taking a look at some specific solutions for Container orchestration for the specific cloud provider you are using. I was using AWS ECS for deployment and I had very good experience with it. Keep in mind that this way you will be bound more to that specific cloud provider compared to if you are using Kubernetes or Docker swarm.

On non cloud provider but still multiple servers or on some cluster of servers?

Here again your need to use Kubernetes or Docker swarm in order to deploy your solution to multiple servers.

On one dedicated server for all of your components?

By deploying on one server technically you could also use docker-compose. The same one that you use for your development setup with some different configurations. This will of course limit you if you at some point decide to deploy on a cluster as you will need to migrate to docker swarm or Kubernetes later.

I could deploy it using docker-compose quite easy but what is the real advantage of using sophisticated solutions as Kubernetes or Docker Swarm in the scenario like this?

I think that in the above section I explained what would be the benefits and drawbacks of using docker compose for production deployment. Usually how I personaly do it is that I have 3 environments:

1. Development environment setup with docker-compose
2. Production environment setup with Kubernetes and deployed to a cluster on AWS
3. Staging environment(Copy of Production) setup with Kubernetes and deployed to a cluster on AWS but using less servers(resources)

So for the Staging I use the same Kubernetes configuration but with less servers(It is expensive :)). This way you ensure that your setup is working as you use the same configuration but with less resources as your staging will not need so much resources as Production which is used by your customers.

How many containers of PostgreSQL database should I create? One PostgreSQL container per microservice or shared one for all microservices using PostgreSQL?

I would not recommend to use containers for databases on production.Why?There are many reasons why not. Simply there are too many risks and a a few people have made a mistake by doing it. Sure it can work for very small application but still I would advise not to use docker for Postgres on production.You can read more about it here. Here is one quote from the post:

Here’s a pretty bad anti-pattern, which can cause you a lot of trouble, even if you’re just working on a small project. You should not run stateful applications in orchestration tools which are built for stateless apps.

If you are using a cloud provider I would suggest to use the build in Services for databases like Database as a Service or on AWS for example RDS. Here you can read about it. For Azure this would be Aurora and other cloud providers have similar solutions.On the other hand for your development setup it is fine to use your databases inside your docker containers.

Conclusion

Depending on your preference and needs use Kubernetes or Docker swarm for all your services except of the databases. Since you are developing a solution using micro-services using kubernetes will allow you to be cloud agnostic. This means that you will be able to have your infrastructure setup portable so you can move it easily to another cloud provider. Of course if that is important to you? You can even deploy it on standard hosting providers which is not a cloud provider on one or multiple servers.