Use a Procfile, a text file in the root directory of your application, to explicitly declare what command should be executed to start a web dyno. In this case, you need to execute Gunicorn with a few arguments.
Here’s a Procfile for our new app. It should be called Procfile and live at the root directory of our project:
web: gunicorn hellodjango.wsgi
You can now start the processes in your Procfile locally using Foreman (installed as part of the Toolbelt):
Heroku recognizes Python applications by the existence of arequirements.txt file in the root of a repository. This simple format is used by most Python projects to specify the external Python modules the application requires.
Pip has a nice command (pip freeze) that will generate this file for us:
You’ve deployed your code to Heroku, and specified the process types in aProcfile. You can now instruct Heroku to execute a process type. Heroku does this by running the associated command in a dyno - a lightweight container which is the basic unit of composition on Heroku.
Let’s ensure we have one dyno running the web process type:
$ heroku ps:scale web=1
You can check the state of the app’s dynos. The heroku ps command lists the running dynos of your application:
$ heroku ps=== web: `gunicorn hellodjango.wsgi`web.1: up for 10s
Here, one dyno is running.
We can now visit the app in our browser with heroku open.
Having only a single web dyno running will result in Heroku periodically idling the dyno after a period of inactivity. This causes a delay of a few seconds for the first request after idling. Subsequent requests will perform normally.
To avoid this, you can scale to more than one web dyno. For example:
$ heroku ps:scale web=2
For each application, Heroku provides 750 free dyno-hours. Running your app at 2 dynos would exceed this free, monthly allowance, so let’s scale back:
Heroku treats logs as streams of time-ordered events aggregated from the output streams of all the dynos running the components of your application. Heroku’sLogplex provides a single channel for all of these events.
View information about your running app using one of the logging commands,heroku logs:
$ heroku logs2012-04-06T19:38:25+00:00 heroku[web.1]: State changed from created to starting2012-04-06T19:38:29+00:00 heroku[web.1]: Starting process with command `gunicorn hellodjango.wsgi`2012-04-06T19:38:29+00:00 app[web.1]: Validating models...2012-04-06T19:38:29+00:00 app[web.1]:2012-04-06T19:38:29+00:00 app[web.1]: 0 errors found2012-04-06T19:38:29+00:00 app[web.1]: Django version 1.5, using settings 'hellodjango.settings'2012-04-06T19:38:29+00:00 app[web.1]: Development server is running at http://0.0.0.0:6566/2012-04-06T19:38:29+00:00 app[web.1]: Quit the server with CONTROL-C.2012-04-06T19:38:30+00:00 heroku[web.1]: State changed from starting to up2012-04-06T19:38:32+00:00 heroku[slugc]: Slug compilation finished
The heroku run command lets you run one-off admin dynos. You can use this to sync the Django models with the database schema:
$ heroku run python manage.py syncdbRunning python manage.py syncdb attached to terminal... up, run.1Creating tables ...Creating table auth_permissionCreating table auth_group_permissionsCreating table auth_groupCreating table auth_user_groupsCreating table auth_user_user_permissionsCreating table auth_userCreating table django_content_typeCreating table django_sessionCreating table django_siteYou just installed Django's auth system, which means you don't have any superusers defined.Would you like to create one now? (yes/no): yesUsername (leave blank to use 'u53976'): kennethEmail address: email@example.comPassword: Password (again): Superuser created successfully.Installing custom SQL ...Installing indexes ...Installed 0 object(s) from 0 fixture(s)