Remarks on docker-compose

[sandroden]

I was asked to bring here some of the remarks on this docker-compose file (of djankiserv) and I'm pleased to do it in this issue. In a separate issue, I'll discuss whether we want a repo for the dockerfile/docker-compose or if it's better to keep it together with the source repo. Here I'll start reporting what I already stated in gitter, it's clear that I already proposed a working docker-compose.yml that in my opinion already has all the possible needs in a single pretty readable file (maybe too many options: proxy via ngrok, via mitmproxy, deploy via nginx or traefik).
My goal was similar: produce a no-brainer configuration.
Here I will report some of the remarks I would raise to the current solution in this repo:

0. One single repo for 2 different servers? do we need this? isn't the name of the repo misleading for the djankiserv docker-compose file? I honestly didn't understand there was a branch with a docker-compose until after I published my version.

1. Use of scripts to generate configuration rather than leaning on the .env file? As you can see in my repo, a very simple .env file can show all variables needed, that's not only the official way but is also very readable. This split up the configuration in many different places and I got lost.

2. I don't like to have a completely new settings file, I'd prefer to see differences in a local_settings.py that overwrites the other one but only where it is different so that it's much easier to spot where the two diverge. Anton has made an app -djankiserv- and a project. The project is functional just to show the app is working and we should let the developer in the position to use it. IMO if you really want to shove in a lot of customization, you're better off using the app and integrating it into your project.

3. I suggest to refrain from using spaces in folder/file names, it's so uneasy from the cli... (Docker Compose)
   (ok, you already agreed)

4. I don't really understand where you initialize the postgresql db (creation of 2 different db). Be carefull! Django does not create databases, migrations will create tables, and so on but inside the connection declared in the settings. It's correct that Django does not (technically you could it the user is a superuser and if you have such a migration, but please: don't).
   My solution is to let it be done by the configuration of the initialization scripts of the PostgreSQL container, as described by PostgreSQL team.

5. I'm not sure I want to create migration as CMD in Dockerfile, which prevents from starting the container if the db is not there and would all the times try to migrate.

Where would you place the initial (and further) migration command? I've placed it there because that way it works automatically.

Migrations are done separately. That's a possible important modification of your data, it's the user that decides to do it:

    docker-compose up -d
    docker-compose exec django manage.py migrate

I've also set the container configuration to restart: always to keep polling the database while it becomes available.
we have the directive depends_on for that, no need to poll

6. manage.py runserver is mono thread and anyhow not suitable for production. Gunicorn and uwsgi are much more robust.

   (you already agreed)

7. 1 or 2 containers? when deploying containers I always put a load balancer in front that handles the traefik for a bunch of dockers so I believe that we can count on that. I personally use traefik as it handles letsencrypt certificate and is born to work with containers (I have used nginx for over 15 years in traditional deployments, apache for the previous 10 years). Traefik is able to detect when a docker is run and route traefik only in that situation. In these cases, you don't need an Nginx for that and we can just have one single container if we use uwsgi that has the possibility to serve static files in a pretty efficient way. So you would not need 2 dockers on hub.docker.com. [I really cannot understand why my container is not showing up in the search result]

8. As I believe this is mainly addressed to developers that want to play with these servers I wanted to add mitmproxy and ngrok that can greatly help to understand what is going to happen under the hood. This is probably a bit daunting as the readme bloated significantly as the possible setup increase... I'm interested in understanding if you find it difficult to read. I also considered to have a "user" and a "developer" configuration but probably if you already setup docker-compose. you're not a "normal" user...