This cookbook is designed to be able to describe and deploy Python web applications. Currently supported:

• plain python web applications
• Django
• Green Unicorn
• Celery

Note that this cookbook provides the Python-specific bindings for the application cookbook; you will find general documentation in that cookbook.

Other application stacks may be supported at a later date.

Chef 0.10.0 or higher required (for Chef environment use).

The following Opscode cookbooks are dependencies:

• application
• python
• gunicorn
• supervisor

The LWRPs provided by this cookbook are not meant to be used by themselves; make sure you are familiar with the application cookbook before proceeding.

The django sub-resource LWRP deals with deploying Django webapps from an SCM repository. It uses the deploy_revision LWRP to perform the bulk of its tasks, and many concepts and parameters map directly to it. Check the documentation for deploy_revision for more information.

A new virtualenv will be created for the application in "#{path}/shared/env"; pip package will be installed in that virtualenv.

• packages: an Array of pip packages to install
• requirements: the relative path to a requirements file. If not specified the provider will look for one in the project root, named either "requirements/#{chef_environment}.txt" or "requirements.txt"
• database_master_role: if a role name is provided, a Chef search will be run to find a node with than role in the same environment as the current role. If a node is found, its IP address will be used when rendering the context file, but see the "Database block parameters" section below
• local_settings_file: the name of the local settings file to be generated by template. Defaults to "local_settings.py"
• settings_template: the name of template that will be rendered to create the local settings file; if specified it will be looked up in the application cookbook. Defaults to "settings.py.erb" from this cookbook
• settings: a Hash of additional settings that will be made available to the template
• database: a block containing additional parameters for configuring the database connection
• legacy_database_settings: if true, the default settings template will generate legacy database config variables. Defaults to false
• debug: used by the default settings template to control debugging. Defaults to false
• collectstatic: controls the behavior of the staticfiles app. If true, if will invoke manage.py with collectstatic --noinput; you can also pass a String with an explicit command (see Usage below). Defaults to false

The database block can accept any method, which will result in an entry being created in the @database Hash which is passed to the context template. See Usage below for more information.

The flask sub-resource LWRP deals with deploying Flask webapps from an SCM repository. It uses the deploy_revision LWRP to perform the bulk of its tasks.

A new virtualenv will be created for the application in "#{path}/shared/env"; pip package will be installed in that virtualenv.

• packages: an Array of pip packages to install
• requirements: the relative path to a requirements file. If not specified the provider will look for one in the project root, named either "requirements/#{chef_environment}.txt" or "requirements.txt"
• local_settings_file: the name of the local settings file to be generated by template. Defaults to "local_settings.py"
• settings_template: the name of the template that will be rendered to create the local settings file; if specified it will be looked up in the application cookbook. Defaults to "flask_settings.py.erb" from this cookbook
• settings: a Hash of additional settings that will be made available in to the template. The default template only supports Strings, Boolean, and Array.
• debug: used by the default settings template to control debugging. Defaults to false

The gunicorn sub-resource LWRP configures Green Unicorn to run the application.

If used with a Django application, it will install gunicorn into the same virtualenv and run it with manage.py run_gunicorn. For other applications, gunicorn will be run with gunicorn #{app_module}.

• app_module: mandatory. If set to :django, gunicorn will be configured to run a Django application; if set to another String or Symbol, it will be used to build the gunicorn base command.
• settings_template: the template to render to create the gunicorn_config.py file; if specified it will be looked up in the application cookbook. Defaults to "se.py.erb" from the gunicorn cookbook
• host: passed to the gunicorn_config LWRP
• port: passed to the gunicorn_config LWRP
• backlog: passed to the gunicorn_config LWRP
• workers: passed to the gunicorn_config LWRP
• worker_class: passed to the gunicorn_config LWRP
• worker_connections: passed to the gunicorn_config LWRP
• max_requests: passed to the gunicorn_config LWRP
• timeout: passed to the gunicorn_config LWRP
• keepalive: passed to the gunicorn_config LWRP
• debug: passed to the gunicorn_config LWRP
• trace: passed to the gunicorn_config LWRP
• preload_app: passed to the gunicorn_config LWRP
• daemon: passed to the gunicorn_config LWRP
• pidfile: passed to the gunicorn_config LWRP
• umask: passed to the gunicorn_config LWRP
• logfile: passed to the gunicorn_config LWRP
• loglevel: passed to the gunicorn_config LWRP
• proc_name: passed to the gunicorn_config LWRP
• environment: hash of environment variables passed to supervisor_service
• autostart: passed to supervisor_service.

The uwsgi sub-resource LWRP configures UWSGI to run the application.

If used with a Django application, it will install uwsgi into the same virtualenv.

• app_module: mandatory. For django applications this is typically your_project_name.wsgi:application
• settings_template: the template to render to create the uwsgi.ini file; if specified it will be looked up in the application cookbook. Defaults to "uwsgi.ini.erb" from the application_python cookbook
• master: Enable the uwsgi master process. Defaults to 'true'.
• socket: Socket to listen on. It can be the path to a socket file, port assignment, or address and port assignment. If you use a socket file you will be responsible for ensuring the paths exist with the right permissions. Defaults to ':8080'
• protocol: Protocol uwsgi should use for socket. Defaults to 'http', can also be 'uwsgi' or 'fastcgi'.
• workers: Number of workers to spawn. Default is determined by the number of cpus on the node.
• directory: Directory to chdir into before starting uwsgi. Default is 'nil'.
• environment: hash of environment variables passed to supervisor_service.
• extra_options: hash of additional options to be passed to to the uwsgi settings template.

The celery sub resource LWRP configures the application to use Celery.

• config: passed to supervisor_service for CELERY_CONFIG_MODULE.
• template: name of the template to use, default celeryconfig.py.erb.
• django: use this if celery is for a django application, see celerycam below.
• celeryd: adds celeryd to processes managed for the application by supervisor.
• celerybeat: adds celerybeat to processes managed for the application by supervisor.
• celerycam: adds celerycam to the processes managed for the application by supervisor if django is true for celery sub-resource, or celeryev with the class specified with camera_class.
• camera_class: class passed into celeryev for the processes managed for the application by supervisor.
• environment: hash of environment variables passed to the supervisor_service.

A sample application that needs a database connection:

application 'packaginator' do
  path       '/srv/packaginator'
  owner      'nobody'
  group      'nogroup'
  repository 'https://github.com/coderanger/packaginator.git'
  revision   'master'
  migrate    true
  packages   ['libpq-dev', 'git-core', 'mercurial']

  django do
    packages          ['redis']
    requirements      'requirements/mkii.txt'
    settings_template 'settings.py.erb'
    debug             true
    collectstatic     'build_static --noinput'
    database do
      database 'packaginator'
      adapter  'postgresql_psycopg2'
      username 'packaginator'
      password 'awesome_password'
    end
    database_master_role 'packaginator_database_master'
  end
end

You can invoke any method on the database block:

application 'my-app' do
  path       '/srv/packaginator'
  repository '...'
  revision   '...'

  django do
    database_master_role 'packaginator_database_master'
    database do
      database 'name'
      quorum   2
      replicas ['Huey', 'Dewey', 'Louie']
    end
  end
end

The corresponding entries will be passed to the context template:

<%= @database['quorum'] %>
<%= @database['replicas'].join(',') %>

• Author:: Adam Jacob ([email protected])
• Author:: Andrea Campi ([email protected])
• Author:: Joshua Timberman ([email protected])
• Author:: Noah Kantrowitz ([email protected])
• Author:: Seth Chisamore ([email protected])

Copyright 2009-2013, Opscode, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.