Let me start of my saying that I really, really like docker. Its a wonderful technology that is absolutely production ready. Once you've created proper images, you're able to scale to a silly degree, with automatic load balancing, failover and so much more... but honestly? you are probably better off not using it.

Docker containers are meant to be small, each application getting its own container. You're still able to run them simultaneously using provisioning tools, whatever they might be.

But if you're not going all in, you'll quickly get into a world of pain. Logrotate? Networking? Storage? Monitoring?

This and more are all things that need to work if this service is meant to be used in production. And its definitely not trivial to setup.

And we've not even started with development yet. if something doesnt work, you need to debug so many layers of abstractions that it will quickly feel horrible.

Docker is great if you want to go into CI/CD though. Just create a container from SCM and deploy it into the kubernetes cluster, fully configured to pipe all logs to a logserver. Its simply great at scale.

Also, docker containers are NOT virtual machines! if you use them like that, you'll quickly get massive images that take ages to start and force you to actually enter the container to debug. Once you're there, you'll quickly get why https://www.youtube.com/watch?v=PivpCKEiQOQ got created

Keep it to one service per container - just let Nginx talk to Django over tcp. You can ensure you have dns-resolvable endpoints using compose (likely best in dev), Swarm (probably easiest in production) or Kubernetes (likely to completely overshadow Swarm, IMO unfortunately).

Keeping multiple services per container moves you away from “containers” towards old-school jails/chroots. Nothing wrong in that, but imo those require more legwork to both set them up and maintain.

I love using docker, I’ll bite :)

With docker (ignore compose for now), you can set up an environment on your local machine that exactly replicates your production one. Same OS, same dependencies, everything. I think of it like virtual environments but massively extended. Not only are your pip installed dependencies isolated, so are your OS dependencies, OS versions, etc. Etc. It’s lovely.

Once the docker image runs on your local machine it’ll run in production. But also, it’ll run on other developers machines too. Getting other people up to speed is so much easier thanks to docker. This includes beginner programmers, and front end devs, people that don’t know enough about the command line (yet).

I don’t use compose. I find that writing a few bash scripts that initialise the project for me is easier. Then I use something like dokku to host everything (so compose isn’t really needs there).

Side benefit of dokku, a deployment is not only a git push away. No more ssh then pull then run deploy script.

Happy to provide more details if you want?

This is a good introduction to Django development with compose and docker. Some things I’ll recommend that are a little more advanced.

1. Your dockerfile adds all of the code, then installs requirements. To minimise build time you can reuse “layers” by adding the requirements file, installing requirements, then adding code directory later. So you don’t need to install requirements each time you edit a code file. 1.b: in development, mount the code directory as a volume rather than adding in the dockerfile, so the image doesn’t need to rebuild at all.

2. Reuse your app dockerfile for your migrations container, and have the entry point accept either “app” or “dbinit” so you don’t need to build two separate images.

3. Rather than adding a “wait for db” in your dbinit container, you can use health checks in your compose file so the db container only reports as being up when it’s ready to accept connections. Depending on the db service will then wait til compose signals that the db is ready.