[ckan-dev] Docker setup for CKAN - some ideas/comments

Tue Jul 9 13:13:23 UTC 2019

Dear list,

I'm just getting started with CKAN and will be deploying using Docker. It
works great so far and is very straightforward to use.

Still, here are a few comments that I initially opened as issues on Github,
but was redirected here. If there's some agreement on these, I may have a
little bit of time to open some PRs in the future, as I may spend some time
on this anyways soon if funding gets through.

*1. Docker setup for production *

The provided Docker setup seems to work fine for testing purposes but
doesn't seem suited to production at all :
- it uses paster serve instead of a proper production server
- it doesn't support HTTPS nor instruction on how to set it up
- there's no indication about other settings to change for production (e.g.
sensible security/performance settings)

Taking into account how much Docker is being used, and how practical it is
to deploy applications, I'd suggest to provide a complete production-ready
setup for Docker, including a sensible configuration for a typical
small-scale installation.

Do you agree with this idea ? Or would you rather just keep docker as a dev
setup, maybe only improve the docs on how to move from dev to prod ? Is
there already any work undergoing on this ?

The main rationale is to join efforts for a sensible deployment setup,
rather than having every user redoing the same work on his own.

*2. Management of production.ini*

Currently, the Docker setup for CKAN uses a volume for production.ini. The
file is generated the first time in the entrypoint, and the volume is not
mounted on the host.

That's not really optimal :

- there's a duplication of settings between production.ini and .env (e.g.
CKAN_SMTP_* env vars from .env must be defined again in production.ini)
- config can only be edited live
- config is hard to find (hidden in docker's internal volume files) and
thus also hard to manage/version

I think a template production.ini should be shipped with the source rather
than generated on the fly. It could either :
a/ contain variables that would be replaced with envsubst in the docker
entrypoint
b/ be mounted directly in the source directory

Variant a/ would be nicer to use in a typical docker workflow, as config
would exclusively happen as env vars (everything in .env), but would be
less flexible. Variant b/ would be more flexible, as you could manually
change the production.ini file to whatever you need. We could even mix
both, but that may become a bit cryptic...

What do you think ?

Kind regards,

Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20190709/bc35b52a/attachment.html>