[ckan-dev] Docker setup for CKAN - some ideas/comments
von Waldow, Harald
Harald.vonWaldow at eawag.ch
Tue Jul 9 13:26:40 UTC 2019
I am looking at dockerizing my CKAN setup too, right now.
From you comments it looks like you are starting from the Docker setup
in the main CKAN repo. I found that the dockerization in
seems to be more advanced, e.g. there is a separate production version
with uwsgi. This repo also seems more active. There is still a lot to
iron out though, also with respect to handling of configuration
Question to everybody:
Can we have a consensus where we work on CKAN dockerization
(okfn/docker-ckan or ckan/ckan)?
On Tue, 9 Jul 2019
15:13:23 +0200 Olivier Dalang <olivier.dalang at gmail.com> wrote:
> 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
> - 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,
Harald von Waldow
Research Data Management
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the ckan-dev