Great article ! Do you always make the same observation and conclusion today ? For your blog, the docker-compose file doesn't exist. Why ? Have you get the same problem between 2018 and 2020 ?
So, your django project is running in docker container, while postgresql and elastic search are running on host machine.
I have a stack (php, apache, postgresql) with the same problem about database performance. About my problem, database volume is small but contains sql views which use much cpu&memory&...
I tried with shm_size in docker-compose.yml. It's the same problem. it's frustating not having the possibility to a stack 100% containerized, but i must be pragmatic.
I don't use docker unless I absolutely have to. It's horrible in many ways, for development, but has many advantages too sometimes. (by the way, I think foreman/honcho is almost always better than docker-compose)
The golden solution is to be able to be flexible. And I think that's what this blog post is about. You give people the ability to do development simply by running `git clone` and `docker-compose up` but as soon as you need to do things that suck in Docker, it should be possible.
So I think your README should say: "Use this docker-compose to get started. But if you want to test benchmarking (or something that pushes the limits of Docker), follow the following instructions to leverage your host..."
The other incredibly important tip/recommendation is to make your software to NOT be dependent on specific versions. If you don't do weird things with your SQL database or whatever it is, it makes it much easier to leverage your host. For example, write your software so it works with Postgres 10, 11, 13, etc.
Comment
Great article !
Do you always make the same observation and conclusion today ?
For your blog, the docker-compose file doesn't exist. Why ? Have you get the same problem between 2018 and 2020 ?
So, your django project is running in docker container, while postgresql and elastic search are running on host machine.
I have a stack (php, apache, postgresql) with the same problem about database performance.
About my problem, database volume is small but contains sql views which use much cpu&memory&...
I tried with shm_size in docker-compose.yml. It's the same problem.
it's frustating not having the possibility to a stack 100% containerized, but i must be pragmatic.
Thanks in advance.
Replies
I don't use docker unless I absolutely have to. It's horrible in many ways, for development, but has many advantages too sometimes. (by the way, I think foreman/honcho is almost always better than docker-compose)
The golden solution is to be able to be flexible. And I think that's what this blog post is about. You give people the ability to do development simply by running `git clone` and `docker-compose up` but as soon as you need to do things that suck in Docker, it should be possible.
So I think your README should say: "Use this docker-compose to get started. But if you want to test benchmarking (or something that pushes the limits of Docker), follow the following instructions to leverage your host..."
The other incredibly important tip/recommendation is to make your software to NOT be dependent on specific versions. If you don't do weird things with your SQL database or whatever it is, it makes it much easier to leverage your host. For example, write your software so it works with Postgres 10, 11, 13, etc.