[ckan-changes] [okfn/ckan] 808391: [#519] Update deployment docs for CKAN 2.0

Wed Apr 24 22:23:39 UTC 2013

  Branch: refs/heads/519-update-deployment-docs
  Home:   https://github.com/okfn/ckan
  Commit: 808391f0930ee4caa8dd5a0e8c96a2169f103e67
      https://github.com/okfn/ckan/commit/808391f0930ee4caa8dd5a0e8c96a2169f103e67
  Author: Sean Hammond <seanhammond at lavabit.com>
  Date:   2013-04-24 (Wed, 24 Apr 2013)

  Changed paths:
    M ckan/config/deployment.ini_tmpl
    M doc/datastore-setup.rst
    M doc/deployment.rst
    M doc/install-from-source.rst
    M doc/post-installation.rst
    M doc/solr-setup.rst
    M doc/test.rst
    M test-core.ini

  Log Message:
  -----------
  [#519] Update deployment docs for CKAN 2.0

This is a fairly big rewrite of the deployment docs that also necessitates
changes to other docs (like the source install docs, etc.)

The idea is to document the deployment process that OKFN is currently using on
its servers, so that the deployment docs can become the docs for the OKFN dev
team and we can dogfood our own docs, instead of having a bunch of wiki pages,
READMEs, etc. that we follow and ignoring the "official" deployment docs.

Secondly, this aims to merge source install and deployment into one process.
Deploying CKAN is just doing a source install, and then doing a couple of
extra things to create the WSGI and Apache config files. But because the
source install docs used `~/pyenv` and the deployment docs used
`/usr/local/demo.ckan.net`, it was much harder to do a deployment than it
should be. You would first have to follow the source install docs but replace
`~/pyenv` with `/usr/local/demo.ckan.net` everywhere and deal with all the
consequences. Then you would follow the deployment docs.

So both the Source Install and Deployment docs now describe the layout we use
on our servers, where there's space for multiple CKAN sites on the same
server, with virtualenvs in `/lib/ckan/` and config files in `/etc/ckan/`.

Since the multi-site layout requires a site name (for the name of the site's
virtualenv, etc.) I've invented a fictional CKAN site called `masaq` as an
example.

- Update the deployment docs to use a virtualenv at `/lib/ckan/masaq`, config
  files at `/etc/ckan/masaq`, etc.
- The deployment docs now use the WSGI and Apache config files that we're
  actually using on our servers, not the old versions that were in the docs
- Deleted stuff about enabling CORS from deployment, apparently this is
  builtin since CKAN 1.5.

- Update the install-from-source docs to use a virtualenv at `/lib/ckan/masaq`
  and config files at `/etc/ckan/masaq`, etc.

  The install-from-source and deployment now use the same ``masaq`` example
  with the same directory layout, database names, etc. So it's possible to
  step through the source install and the deployment docs exactly as written
  (copy-pasting everything without modification) and end up with a working
  deployed site.

- Also added info to the install-from-source docs about how the filesystem
  layout etc is done and why

- Update the DataStore Setup docs to use the `masaq` database user, and to
  call the datastore database `masaq-datastore`.

- Update the solr-setup docs, this is just tweaking some formatting issues
  and updating some commands to follow the `masaq` example.

- Update the post-install docs to fit with the `masaq` example as well

- Update the testing docs to fit with the `masaq` example

- Update `test-core.ini` to use the `masaq` postgres user name

- Disable the log file in `deployment.ini_tmpl`, as we do on our servers, and
  rely only on the Apache logs