Refine generated project Docker / Docker Compose infrastructure

[webyneter]

Description

I've restructured our Docker / Docker Compose project template infrastructure.

Features

N.B. . denotes a generated project root directory.

• ./compose has been replaced with ./docker:

   tree ./docker 
  /docker
  ── caddy
     ├── Caddyfile
     └── Dockerfile
  ── django
     ├── Dockerfile
     └── scripts
         ├── celerybeat
         ├── celeryworker
         ├── django
         ├── django.local
         ├── entrypoint
         └── flower
  ── mailhog
     └── Dockerfile
  ── postgres
     ├── Dockerfile
     └── scripts
         ├── backup
         ├── backups
         ├── restore
         └── _sourced
             ├── constants.sh
             ├── countdown.sh
             ├── messages.sh
             └── yes_no.sh
  ── redis
     └── Dockerfile
  
   directories, 19 files
  

  There is now a single Dockerfile for every service we've got, where build instructions vary depending on an ARG environment (its de-facto values are local and production for now), for instance, this is how we're gonna be installing django requirements from now on:

  UN [ "${environment}" = 'production' ] && pip --no-cache-dir install -r "./requirements/${environment}.txt" || pip install -r "./requirements/${environment}.txt"
  

  Also, I've extracted mailhog and redis service images to respective Dockerfile allowing for image version parity between local and production Docker Compose environments.

• As for ./envs/*,

   tree -a  ./.envs
  /.envs
  ── .caddy
  ── .django
  ── .django.local
  ── .postgres
  ── .postgres.local
  
   directories, 5 files
  

  Those previously residing in ./.envs/local/ were moved upwards and renamed to *.local to match ./docker/**/scripts/*.local CMD scripts; ./.envs/production/* env files were moved upwards as well.

• local.yml and production.yml services' build sections were extended with build args. Self-contained services -- those requiring no extra build artifacts but the ones from the corresponding Dockerfile parent directory -- are now built in the context of the containing directory only.

Trade-offs to be Tackled

• [ ] I had to run local.yml::services:celerybeat and production.yml::services:celerybeat with user: root overriding the django USER set in the base ./docker/django/Dockerfile, otherwise celerybeat.pid, celerybeat-schedule and any other files created by celery beat binary cannot be modified by a beat process; this is a known problem, and a number of solutions exist but none of them seem portable enough to me. Any suggestions are welcome. UPD filesystem access is now restricted to all users other than root, effectively rendering this workaround regressive -- the only way to fix that is removing USER django and chown ... django:django from django Dockerfile...

Rationale

Until now, generated project environments have been lacking parity, and therefore code execution consistency guarantees could not had been provided. Hope this PR will address that concern once and for all.

Use case(s) / visualization(s)

docker-compose -f local.yml build docker-compose -f local.yml up

docker-compose -f production.yml build docker-compose -f production.yml up

@pydanny, @jayfk, @luzfcb, @browniebroke, @sfdye thoughts?

[webyneter]

@browniebroke since I last pushed here my go-to production Dockerfiles changed a bit: more optimizations and no more if/elses -- you'll like it ones I myself find time to update this PR :)