Just my 2 cents or ramblings on the topic of GSoC and deployment:
Most Django deployments we do are executed by running containers from
custom built Docker images from private repositories.
They are mostly run with either
- Docker Compose on small scale, or
- Heroku, Kubernetes or other container orchestrator on larger scale.
The Docker images and their packaging are starting to look quite similar
these days with their 12-factor setups and service oriented approaches.
The baseline package is usually just a Python template that runs Django
installation with all the checks, static file compilation, and whatnot at
the end of the image build.
Then there is, usually, a shell startup script, that is run as an
entrypoint, which runs migrate and other state related commands on
container startup and execs the Django application as configured.
The Docker images we build ideally support running multimode with the
- web server container running Gunicorn, uwsgi, or a similar HTTP
application server, and
- the background worker container running a task executor like Celery or
and the container orchestrator just supplying the command (one can think of
this as the "mode") to run in.
This is all and good, and Django supports a runner setup like this
beautifully without any gimmicks with Docker images and containers.
Well, you have to figure out the necessary build and startup commands and
so forth, but there are good online resources for figuring out those things
Progressing to the point I am trying to bring up, I think that
containerization instructions with some good examples including stuff like
- Docker image packaging for a basic Django web server using FOSS
- configuration and settings examples in a Docker build and deployment
setup for Django,
- multimode container examples for running in web server or web worker role,
- sane defaults for security hardening and checkups, and
- defining startup scripts for running tasks like migrations before
could be quite invaluable in the Django deployment documentation at e.g.
The deployments are starting to look so similar these days that supplying
good stock examples for packaging a basic web server and web worker image
and running it as a container could be a good idea that could save
tremendous amounts of time for people building their first or second
deployments. Best practices never hurt anybody either.
Of course e.g. many of the Cookiecutter templates available have examples
for Docker packaging, but none of the ones I have seen discuss the process
in an easily accessible format that ties in well with Django development
and documentation. They are usually more expert oriented and just supply
some opinionated configuration examples that might or might not work or be
secure or up-to-date.
I imagine at least including some Docker packaging and workload
containerization components in the GSoC proposition could be helpful.
Packaging could align with the GSoC motives as e.g. Kubernetes enablement
is well in line with modern IaaS hosting interests.
A DevOps guy
On Friday, 15 February 2019 13:22:22 UTC+2, Josh Smeaton wrote:
> If you really think you want to work on a deployment project, you should
> get the requirements together very quickly, so someone on this list can
> sanity check that it's something both feasible and useful.
> I have done a **lot** of different deployments, and other than deploying
> to heroku, they have never been the same. I'm rather skeptical that some
> tool can be built for deploying a Django application that didn't already
> mimic an existing tool like Ansible or Salt (or Heroku CLI).
> Examples: what application server (gunicorn, uwsgi, mod_wsgi)? What web
> server (nginx, apache, caddy)? What database server, and is it remote or
> local? How are environment variables securely provisioned and deployed?
> Where is static content served from, and do you need S3 keys? How are you
> managing TLS certificates?
> Start a new thread on this list when you have an outline for what you want
> to do. At that stage we should be able to tell you if you should proceed
> with a detailed project scope or not. I don't want you to work on a
> detailed project scope and then get knocked back for the idea being
> infeasible. Remember, the project would need to be very useful for Django
> I'd also just like to call out that projects like Django Channels would
> likely be in scope too, provided the current maintainers felt comfortable
> mentoring a student. A quick note about Channels specifically - the current
> maintainers have **just** taken up that mantle, so you should have a
> specific idea in mind if that's what you're interested in, not ask the team
> for ideas.
> On Friday, 15 February 2019 20:53:34 UTC+11, Shashank shet wrote:
>> That's a good