3 ms·
Is there a benefit of running Postgres and Django in different containers? By putting them in the same container, things could be a good bit simpler. And I don
by TekMol 6y ago
Is there a benefit of running Postgres and Django in different containers?
By putting them in the same container, things could be a good bit simpler. And I don't see any downside here.
- pbar 6y agoSingle responsibility - that same container is gonna get shipped to prod/etc. I would hope the database isn’t in the container there!
- TekMol 6y agoI would think the database data does not live in the database container but is mounted into it? If you update you database version, you do not ship the database data to production either.
- sofixa 6y ago> s there a benefit of running Postgres and Django in different containers 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.)
- TekMol 6y agoThe premise of TFA is that "scale is not an issue".
- avaika 6y agoDocker monitors only main process. If side process fails docker will do nothing about it. Means if you want to put multiple apps inside single container you have to add some manager guy to keep an eye on all the processes (e.g. supervisord). Plus in case with separate containers the layers cache is reused better.
- TekMol 6y agoWhy do you need Docker to monitor it? I would think it will only recognize a problem if the process dies. But you need to monitor your db and application for other types of failures anyhow, right? I cannot remember the last time I had a problem with the DB process dying.
- avaika 6y agoThat's default behavior. Docker tracks the main process. If it dies, and your database is not the main process, then the entire container will be restarted (depends on configuration). Means your database will be forcefully killed. At some point you might run into data corruption incident. If you make database your main process, then docker will be blind for your application death.
- TekMol 6y agoI would make neither the main process. A dedicated server also does not restart if my DB or my application dies.
- avaika 6y agoThat's why I mentioned that if you want to put multiple applications inside a single container, you have to put it under supervisord or alternative. So neither would be the main process.
- lixtra 6y agoDecoupling the images. 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)
- TekMol 6y agoMy solution is to not use 3rd party extensions at all. Only what is in the Debian repos and gets fixed by Debian.
- simplecto 6y agoPutting them in the same container means I have to manage the processes myself with something like supervisord. A docker-compose file makes this trivial because it is just a matter of a few lines of YAML that link the services together. It also means I can ship updates to my application and restart it without touching the rock-solid Postgres image.
- TekMol 6y agoWhat do you mean by "manage the processes"? Why would you need to touch postgres when updating your application?
- simplecto 6y agoTypically the process to update an application is to push up a new image and then tell docker to stop the old one, and load the new one in its place (yes, I know there are 0-downtime ways, but lets keep it simple). 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.
- TekMol 6y agoI would not use Docker this way. I would treat the docker container like a server. I would update the application inside the running container.