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

[Olivier Dalang]

Hi !

@amercadero @frafra I took the liberty to CC you in this discussion, hope
you don't mind !

@Florian nice to hear there's at least one user of my work :-)

Can we have a consensus where we work on CKAN dockerization
>
@Harald Yes that's probably the most important point. I'd strongly argue in
favour of doing it in ckan/ckan for the following reasons :
- ability to reuse the setup for development
- ability to use setup for CI
- ability to make complete docker-releases with just a git tag

Cheers,

Olivier




On Tue, 9 Jul 2019 at 15:41, von Waldow, Harald <Harald.vonWaldow at eawag.ch>
wrote:

> Hi Olivier
>
> 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
>
> https://github.com/okfn/docker-ckan
>
> 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
> variables.
>
> Question to everybody:
> Can we have a consensus where we work on CKAN dockerization
> (okfn/docker-ckan or ckan/ckan)?
>
> Kind regards,
> Harald
>
>
>
>
>
>
>  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
> > 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
>
>
>
> --
> Harald von Waldow
> Eawag
> ICT Services
> Research Data Management
> Ueberlandstrasse 133
> 8600 Duebendorf
> http://www.eawag.ch
> https://opendata.eawag.ch
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20190709/71ef7571/attachment-0002.html>