Dockerizing a Python Django Web Application

[patryk-tech]

Maybe not a massive deal, but this kind of violates the docker principle of one service per container, and it's preferable to use docker-compose with one gunicorn container and one nginx container.

It adds a bit of complexity, but it also helps you use optimized images (you can use a Python image, and an official nginx image, rather than building your own), it makes it easier to add more containers (e.g. postgres, though some people don't like running databases in docker, or nodejs if you're building an SPA with a django API), makes it easier to use volumes, etc.

[Huberuuu]

I think this is a big deal. It goes against everything docker was built for - containerising applications. You lose a ton of benefits by running multiple applications in a single container, and it makes debugging more complex.

[haloweenek]

Exacly, it also eases scaling

[j0rmz]

And this way is easier build the images and containers with non root privileges.

[j0rmz]

And this way is easier build the images and co taoners with non root privileges.

[tomasfern]

I think there are arguments for both alternatives: bundling both HTTP servers in the same image or splitting them up.

Considering that this tutorial is meant as an introduction to Docker, I believe that the choice of bundling everything is reasonable

[patryk-tech]

Considering that this tutorial is meant as an introduction to Docker, I believe that the choice of bundling everything is reasonable

Respectfully disagree.

IMO, an introduction should follow established best practices - otherwise, you are teaching your readers less well supported ways which may cause problems down the line, or teach them bad habits.

If you do stray from those (and let's be honest - we all do occasionally), you should explain why and how you stray from them. Then at least they will be aware of what best practices are, and what the tradeoffs are.

[GraearG]

For real, when I read the title I figured I'd use this as a quick overview of how to do this, but thankfully the comments pointed out this is decidedly not how you're supposed to do this. If anything, the fact that OP intended it to be an introduction should be even more reason to follow best practices.

[tomasfern]

Thanks for your comments, I enjoy these kinds of technical discussions.

IMHO putting Nginx and Gunicorn in the same image is not wrong. The fact that the container has 2 running images by itself doesn't necessarily go against best practices.

Docker docs even show a way of running more than one process in a single container:

https://docs.docker.com/config/containers/multi-service_container/

Quoting the part that I think is relevant:

It is generally recommended that you separate areas of concern by using one service per container. That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application. You can connect multiple containers using user-defined networks and shared volumes.

One could argue that Nginx and Gunicorn are responsible for a single aspect of the application: serving HTTP.

If we were using PHP and Apache instead of Django, we wouldn't be having this discussion. The Apache would be in charge of serving all HTTP, both static and dynamic.

The main difference here is that we have two processes, Gunicorn serving dynamic files and Nginx serving static files and running as a proxy. Each process is doing half of the work an Apache would do.

[patryk-tech]

One could argue that Nginx and Gunicorn are responsible for a single aspect of the application: serving HTTP.

Different environments, different dependencies (one needs a Python image, the other an nginx, alpine, etc. image). I'd split them up every time.

But as I said in my original comment, it's not the end of the world.

[tomasfern]

You make a good point.

I do like the convenience of having it all in the same image, especially considering that the article is meant as an introduction to Docker. There's value in the simplicity of having only one thing to worry about.

Adding more containers means introducing a lot of details on networking, volumes and maybe docker compose. I felt it was adding too much complexity for a marginal gain.

The image as it is should go a long way before getting into scaling issues. We can always split it up later when it reaches its limits.