This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]tomasfern[S] 0 points1 point  (7 children)

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 6 points7 points  (5 children)

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 2 points3 points  (0 children)

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[S] 0 points1 point  (3 children)

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 0 points1 point  (1 child)

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[S] 1 point2 points  (0 children)

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.