~patrick-hetu/charms/precise/python-django/ansible

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
# Python-django Charm

Authors:

- Patrick Hetu <patrick.hetu@gmail.com>
- Bruno Girin

## What is Django?

Django is a high-level web application framework that loosely follows
the model-view-controller (MVC) design pattern.  Python's equivalent to
Ruby on Rails, Django lets you build complex data-driven websites quickly
and easily - Django focuses on automating as much as possible and
adhering to the "Don't Repeat Yourself" (DRY) principle.  Django
additionally emphasizes reusability and "pluggability" of components;
many generic third-party "applications" are available to enhance
projects or to simply reduce development time even further.

Notable features include:

- An object-relational mapper (ORM)
- Automatic admin interface
- Elegant URL dispatcher
- Form serialization and validation system
- Templating system
- Lightweight, standalone web server for development and testing
- Internationalization support
- Testing framework and client

## The charm

This charm will install Django. It can also install your Django
project and its dependencies from either a template or from a
version control system.

It can also link your project to a database and sync the schemas.
This charm also comes with a Fabric fabfile to interact with the
deployment in a cloud-aware manner.

## Quick start

Simply:
    
    juju bootstrap
    juju deploy python-django

    juju deploy postgresql
    juju add-relation python-django postgresql:db

    juju deploy gunicorn
    juju add-relation python-django gunicorn
    juju expose python-django

In a couple of minutes, your new (vanilla) Django site should be ready at
the public address of gunicorn. You can find it in the output of the
`juju status` command.

This is roughtly equivalent to the [Creating a project](https://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-a-project)
step in Django's tutorial.

### Example: Deploying using a site template

1. Setup your Django specific parameters in mydjangosite.yaml like this one:

        mydjangosite:
            project_template_url: https://github.com/xenith/django-base-template/zipball/master
            project_template_extension: py,md,rst

1. Deployment with `Gunicorn`:

        juju bootstrap
        juju deploy --config mydjangosite.yaml mydjangosite

        juju deploy postgresql
        juju add-relation mydjangosite postgresql:db

        juju deploy gunicorn
        juju add-relation mydjangosite gunicorn
        juju expose mydjangosite


### Example: Deploying using a code repository

1. Setup your Django specific parameters in mydjangosite.yaml like this one:

        mydjangosite:
            vcs: bzr
            repos_url: lp:~patrick-hetu/my_site

1. Deployment with `Gunicorn`:

        juju bootstrap
        juju deploy --config mydjangosite.yaml python-django mydjangosite

        juju deploy postgresql
        juju add-relation python-django postgresql:db

        juju deploy gunicorn
        juju add-relation mydjangosite gunicorn
        juju expose mydjangosite

1. Your new Django site should be accessible at the public address of
   Gunicorn. To find it, look for it in the output of the `juju status` command.  

## Project layout and code injection

Continuing from the previous example, your web site should be on the Django node at:

    /srv/mydjangosite/

As you can see there the charm has injected some code at the end of your settings.py
file (or created it if it was not there) to be able to import what's in the
`juju_settings/` directory.

It's recommended that you make your vcs ignore database and secret files or
any files that have information that you don't want to publish.

## Complex configuration example: dpaste

    mydpastesite:
      django_version: ''
      django_south: True
      django_south_version: ''
      vcs: 'git'
      repos_url: 'https://github.com/bartTC/dpaste.git'
      repos_branch: '2.6'
      application_path: 'dpaste'
      django_settings: 'dpaste.settings'
      settings_injection_path: 'settings/__init__.py'
      urls_injection_path: 'urls/__init__.py'
      requirements_pip_files: 'requirements.txt'
      additional_distro_packages: "python-imaging,python-tz,python-dev,build-essential,libpq-dev,libmysqlclient-dev,libxml2-dev,libxslt1-dev"


## Upgrade the charm

This charm allow you to upgrade your deployment using Juju's `upgrade-charm`
command. This command will:

- upgrade Django
- upgrade additional pip packages
- upgrade additional Debian packages
- upgrade using requirements files in your project

## Management with Fabric

[Fabric](http://docs.fabfile.org) is a Python (2.5 or higher) library and command-line tool for
streamlining the use of SSH for application deployment or system administration tasks.

It provides a basic suite of operations for executing
local or remote shell commands (normally or via sudo) and uploading/downloading
files, as well as auxiliary functionality such as prompting the running user
for input, or aborting execution.

This charm includes a Fabric script that use Juju's information to perform various
tasks.

For a list of tasks type this command after bootstraping your Juju environment:

    fab -l

For example, with a python-django service deployed you can run commands on all of its units:

    fab -R python-django pull
    [10.0.0.2] Executing task 'pull'
    [10.0.0.2] run: bzr pull lp:~my_name/django_code/my_site
    ...
    [10.0.0.2] run: invoke-rc.d gunicorn restart
    ...

Or you can also run commands on a single unit:

    fab -R python-django/0 manage:createsuperuser
    ...
    [10.0.0.2] out: Username (leave blank to use 'ubuntu'):


Limitation:

- You can only execute tasks for one role at a time.
  But it can be a service or unit.

If you want to extend the fabfile check out [fabtools](http://fabtools.readthedocs.org/).

## Ansible

See: https://github.com/cmars/juju-ansible

## Security

Note that if you're using a `requirement.txt` file the packages will
be downloaded with `pip` and it doesn't do any cryptographic
verification of its downloads.

## Writing application charm

To create an application subordinate charm that can be related to this charm you need
to at least define an interface named `directory-path` in your `metadate.yaml` file
like this:

    [...]
    requires:
      python-django:
        interface: directory-path
        scope: container
        optional: true

When you add a relation between your charm and the python-django charm,
you will be able to get those relation variables from the hook:

- `settings_dir_path`
- `urls_dir_path`
- `django_admin_cmd`
- `install_root`

Now your charm will be informed about where it needs to add new settings
and urls files and how to run additionnal Django commands. 
The Django charm reloads Gunicorn after the relation to catch the changes.

## Changelog

### X: Not yet released

- Python3 compatibility
- Support for Django 1.7
- Support for virtualenv
- Tests
- More vcs options
- More pip options

### 6: Notable changes:

- The charm now use charm-helpers for hooks
- The chams now use ansible for installation
- Mysql and Redis and rabbitmq (celery) support was added
- The charm can install South and do migrations
- The charm include a Fabric and Ansible scripts to interact with Juju

Note that I still need to think about the role of Fabric, Ansible, Salt, charm-helpers, etc

Configuration changes:

- python_path now accept multiple path separated by commas
- requirements_pip_files now also accept urls
- requirements_pip_files and requirements_apt_files are empty by default
- settings_secret_key_path was renamed settings_secret_key_name
- settings_database_path was renamed settings_database_name

New options:

- unit_config
- settings_amqp_name
- celery_always_eager
- django_south
- django_south_version
- django_debug
- django_allowed_host
- django_extra_settings
- settings_injection_path
- url_injection_path
- pip_extra_args

Backwards incompatible changes:

- Some default options changed so be sure to checkout your configuration files.
- The use of Ansible change a bit how things are done now be sure to test.

### 3: Notable changes:

- Rewrite the charm using python instead of BASH scripts
- Django projects now need no modification to work with the charm
- Use the `django-admin startproject` command with configurable arguments if no repos is specified
- Juju's generated settings and urls files are now added in a juju_settings and a juju_urls directories by default
- New MongoDB relation (server side is yet to be done)
- New upgrade hook that upgrade pip and debian packages
- Expose ports is now handle by the charm

Configuration changes:

- default user and group is now ubuntu
- new install_root option
- new django_version option
- new additional_pip_packages option
- new repos_branch,repos_username,repos_password options
- new project_name, project_template_extension, project_template_url options
- new urls_dir_name and settings_dir_name options
- new project_template_url and project_template_extension options
- database, uploads, static, secret and cache settings locations are now configurable
- extra_deb_pkg was renamed additional_distro_packages
- requirements was renamed requirements_pip_files and now support multiple files
- if python_path is empty set as install_root
    
Backwards incompatible changes:

- swift support was moved to a subordinate charm
- postgresql relation hook was rename pgsql instead of db

### 2: Notable changes:

- You can configure all wsgi (Gunicorn) settings via the config.yaml file
- Juju compatible Fabric fabfile.py is included for PAAS commands
- Swift storage backend is now optional

Backwards incompatible changes:

- Use split settings and urls
- Permissons are now based on WSGI's user and group instead of just being www-data
- media and static files are now in new directories ./uploads and ./static/
- Deprecated configuration variables: site_domain, site_username, site_password, site_admin_email


### 1: Notable changes:

- Initial release

## Inspiration

- http://www.deploydjango.com
- http://lincolnloop.com/django-best-practices/
- https://github.com/30loops/djangocms-on-30loops.git
- https://github.com/openshift/django-example
- http://lincolnloop.com/blog/2013/feb/15/django-settings-parity-youre-doing-it-wrong/
- http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/
- http://www.rdegges.com/the-perfect-django-settings-file/
- https://github.com/xenith/django-base-template.git
- https://github.com/transifex/transifex/blob/devel/transifex/settings.py
- http://peterlyons.com/problog/2010/02/environment-variables-considered-harmful