which is better to have the database in the same container as the application or outside the application?

[hafisrabbani]

May I know the reasons or advantages and disadvantages?

[ardikabs]

@hafisrabbani The best practice approach to containerization is to treat each container as equivalent to a process. For instance, you can treat your service combined with Nginx as one process and the database as another. Therefore, they should be separated into distinct containers.

However, regarding the service and Nginx, if Nginx is handling additional functionalities beyond its usual role, such as but not limited to rate limiting or caching, it's advisable to separate those into different containers.

The goals focus on separating concerns regarding resource allocation, network isolation, and simplicity. In terms of simplicity, consider it as only needing to consider dependencies for a single process, leading to an expected container size. However, when everything is combined in one container, managing arbitrary number of dependencies may arise due to other processes' needs that aren't directly related to the main application. And yet we still haven't touched more details aspect.

Though, putting everything in single container might helpful for development purpose. But still, better to not have it in the first place, you can use docker-compose as a helper to maintain it during development.

[hafisrabbani]

First of all, thank you for your answer mas @ardikabs but I still have other questions regarding your answer for example, separating application containers and database containers if at any time an error occurs or dies in the database container Will all services that use the database not be disrupted too? Is there a way to prevent something like this?

[ardikabs]

the dependency disruption (e.g., database) must be handled gracefully by their client, in this case all services that use the database. To prevent that, you need to handle it from the application stand point.