Once installed, you can use the heroku command from your command shell. Log in using the email address and password you used when creating your Heroku account:
$ heroku loginEnter your Heroku credentials.Email: email@example.comPassword:Could not find an existing public key.Would you like to generate one? [Yn]Generating new SSH public key.Uploading ssh public key /Users/kenneth/.ssh/id_rsa.pub
Press enter at the prompt to upload your existing ssh key or create a new one, used for pushing code later on.
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 hello:app
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=1Scaling web processes... done, now running 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 hello:app`web.1: up for 5s
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 logs2011-08-20T16:33:39+00:00 heroku[slugc]: Slug compilation started2011-08-20T16:34:07+00:00 heroku[api]: Config add PYTHONUNBUFFERED by firstname.lastname@example.orgT16:34:07+00:00 heroku[api]: Release v1 created by email@example.comT16:34:07+00:00 heroku[api]: Deploy 67b7e54 by firstname.lastname@example.orgT16:34:07+00:00 heroku[api]: Release v2 created by email@example.comT16:34:08+00:00 heroku[web.1]: State changed from created to starting2011-08-20T16:34:08+00:00 heroku[slugc]: Slug compilation finished2011-08-20T16:34:10+00:00 heroku[web.1]: Starting process with command `gunicorn hello:app`2011-08-20T16:34:10+00:00 app[web.1]: * Running on http://0.0.0.0:17658/2011-08-20T16:34:11+00:00 heroku[web.1]: State changed from starting to up
Heroku allows you to run commands in a one-off dyno - scripts and applications that only need to be executed when needed - using the heroku run command. Use this to launch a Python shell attached to your local terminal for experimenting in your app’s environment:
$ heroku run pythonRunning python attached to terminal... up, run.1Python 2.7.4 (default, Apr 6 2013, 22:14:13)[GCC 4.4.3] on linux2Type "help", "copyright", "credits" or "license" for more information.>>>
From here you can import some of your application modules.