Multi stage Python build for Django

[arnav13081994]

Description

I am proposing to use multi-stage builds for building the python part of Django.

This can be done by installing all required OS and python dependencies and then to just copy over those files to the run stage. This reduces the size of a Django image from 509MB to 306MB (without gulp) and 561MB to 360MB (with gulp). A nearly 35% reduction in size!

One more improvement that can be made is to also copy over system dependencies from the python build stage, but that would make the configuration brittle due to apt installing files and symlinks in different locations depending on the package being installed. And that is why they are again installed in the run stage.

Rationale

Smaller images are highly desirable because they would greatly reduce the time of re-deployment and deployment of containers and would also save a lot of time and money especially bandwidth costs.

Use case(s) / visualization(s)

NA

[Andrew-Chen-Wang]

@arnav13081994 I'm not sure if you need to add yourself to contributors again ref: 1676d1a

[arnav13081994]

I'm not sure why that's happening because I didn't add myself again. Let me update my local repo again and then commit again. Perhaps that would fix this.

[arnav13081994]

My editor automatically adds a new blank line to the end of CONTRIBUTORS.md and that is why that file also got committed. @Andrew-Chen-Wang

[foarsitter]

Thanks for sharing @arnav13081994! Manged to trim my alpine image from 196.76 MB to 106.51 MB. That is really cool.

[Andrew-Chen-Wang]

@arnav13081994 Gotcha. I thought the GitHub action was running prematurely or something. Glad to see this!

[browniebroke]

The extra commits likely appear because PR #2794 was made from the master branch in your fork, but this is discouraged and is known for causing various issues in subsequent pull requests, as we can see here.

This wouldn't be an issue normally, but I've squashed the commits when I merged #2794 so the commmits from that PR are not in the master branch of this repo, they are all squashed in a single commit, hence they are listed as new commits.

To solve this, you should recreate the master branch in your fork to match the content of pydanny/cookiecutter-django. The easiest option would be to delete your fork and recreate it again, but that means you'd have to close and then recreate your open pull requests. Note that you can get a diff/patch by appending .diff or .patch at the end of the PR URL:

• https://patch-diff.githubusercontent.com/raw/pydanny/cookiecutter-django/pull/2803.diff
• https://patch-diff.githubusercontent.com/raw/pydanny/cookiecutter-django/pull/2803.patch

You can can then apply these to fresh working directory

[arnav13081994]

Happy to help, @foarsitter @Andrew-Chen-Wang.

I actually found a better way to use multi-stage builds by using python wheels. The final image would be around the same size but would take slightly longer to build. The advantage, however, would be that this way would not involve manually copying standard python directories but just the wheels directory and that would then be used to install all python packages.

If you all agree, I can make that change and raise 1 new PR with updates to both local/django/Dockerfile and production/django/Dockerfile.

@browniebroke Thank you for pointing that out. I will close and raise new PRs after creating a fresh fork.

[arnav13081994]

Raised a PR for this here: #2815