Page MenuHomePhabricator

[tbs] Create documentation on how to build and deploy a python application
Open, In Progress, HighPublic


The docs can be created in a preliminar subpage of, pending finding the best place for them (they can be started in a google doc for the early stages if preferred).

The application should be the same as the current docs show:

(Python+django+DB+static files+uwsgi)

Note that some restrictions in those docs will not apply anymore (like needing the file).

Event Timeline

dcaro triaged this task as High priority.Mar 10 2023, 1:39 PM

There is yes :), though this task is focused on doing so with buildpacks (that is not yet released), but eventually yes, it will be the same once the toolforge build service is released.

Slst2020 changed the task status from Open to In Progress.Mar 16 2023, 1:11 PM

How will secrets work with buildpacks? The previous recommendation was to create a config file inside the tool account and change the permissions so that only the tool user could read it. But now the code will be cloned directly from a git repo and baked into the application image, so this wouldn't work. On Heroku, configuration is managed via "config vars" that can be set and unset via their CLI tool or the web UI. These are exposed as environment variables to the running application.

From the Heroku docs:

Django does not support serving static files in production. However, the fantastic WhiteNoise project can integrate into your Django application, and was designed with exactly this purpose in mind.

See the WhiteNoise Django documentation for more details.

There is also a full example in the Getting Started with Python project on GitHub.

Collectstatic during builds
When a Django application is deployed to Heroku, $ python collectstatic --noinput is run automatically during the build. A build will fail if the collectstatic step is not successful.

Will this apply to our use case of Heroku buildpacks too?

The app when started by toolforge will run as the tool user, and the home will be mounted at the same place it is now, so it will be able to read the config the same way it does now.

I have not personally tested it yet, but that is the idea, so the secrets process would not change (yet!)