By putting them in the same container, things could be a good bit simpler. And I don't see any downside here.
By putting them in the same container, things could be a good bit simpler. And I don't see any downside here.
To make it more realistic, let’s assume that you use an exotic pg extension. Some morning you read about a huge security issue in django. You see the patch comes with library upgrades that are incompatible with your exotic extension. So what do you do? With two separate containers, you can patch one and leave the other one untouched. Saying that the extension shouldn’t be so brittle is true but doesn’t solve the issue because without it you wouldn’t have the job.
(For a real scenario look at the python 2 deprecated thread and arcgis)
Plus in case with separate containers the layers cache is reused better.
If you make database your main process, then docker will be blind for your application death.
A dedicated server also does not restart if my DB or my application dies.
You can use the official optimised containers ( especially for complex things like Postgres that's great)
> By putting them in the same container, things could be a good bit simpler. And I don't see any downside here
The downsides are that you get fat containers that are impossible to scale independently ( one day you might want two Django containers, or to set up a replica PgSQL for load balancing, HA, etc.)
If you update you database version, you do not ship the database data to production either.
Why would you need to touch postgres when updating your application?
If you put both processes in the same container, then you cannot simply upload a new image and restart the container. This is where it gets very complicated, error prone, and not in line with what I understand to be current best practices with docker.