Using https://github.com/ckan/ckan-docker as the “official” CKAN Docker repo

[kowh-ai]

There is always a lot of discussion (and issues) regarding ‘CKAN on Docker’. During the Dev Core meeting yesterday (Oct 26, 2021) it was thought we could open a discussion on using https://github.com/ckan/ckan-docker as the new repo for ‘CKAN on Docker’

There are many many ways and options to configure CKAN on Docker however I think it makes the most sense to provide a very generic Docker environment that is targeted more to developers rather than a production environment. Productionalizing CKAN on Docker would surely be heading towards using orchestration tools (Kubernetes, Swarm etc) to take care of scaling. This is beyond the scope of something maintainable by the Core Dev team (and major contributors)

Here’s a first swing at defining what to think about…I’m sure there is there’s plenty more

1. Use https://github.com/ckan/ckan-docker as the official CKAN Docker repo
2. remove current CKAN Docker https://github.com/ckan/ckan/contrib/docker (plus the CKAN Dockerfile)
3. Include an NGINX container?
4. Look at the option of using ghcr.io (GitHub Packages) to store Docker Images rather than DockerHub
5. automate uploading images to this repo when PR’s are successfully merged into master
6. How to use build variables? What is loaded at build time, what is loaded at runtime loaded (.env vs .ckan-env files)
7. Do we need to use ARG?
8. Do we use ubuntu or alpine as the base image?
9. Shall we use multi stage builds and/or buildkit?
10. Do we hardcode container names eg: db and therefore hostname’s or shall we use variables?
11. Create an admin user during the container deployment?
12. should there be a datapusher image pre-built like ckan? If so what about when XLoader is the preference?
13. CKAN (Dev) should mount CKAN code / extension code / config files as volume mounts
14. Include a set of (main) CKAN extensions in the CKAN Dockerfile that have been commented out - which could be used (uncommented) or used as a reference for other CKAN extensions
15. What are the main CKAN extensions that should be included? Would they all be running in the same container as CKAN core?
16. What about a second CKAN container running worker? ie: for XLoader

I personally think we should keep things as minimal as possible

[frafra]

1. I do not consider ckan/ckan-docker to be a good setup to start from
2. --
3. NGINX container for non-dev mode would be useful
4. --
5. Use of build variables should be very limited in my opinion: no configuration variables should be needed at build time
6. No, usually
7. --
8. --
9. Multistage are useful if you have some build dependencies that you do not want to end up in the final image; buildkit is just an alternative way to build stuff, which users can use if they like
10. I am against hardcoded container names, as they create conflicts when running multiple stacks
11. That is what I usually do, but it could be initialized easily by running the same container with a different command in docker-compose,
12. --
13. Right; I wouldn't use a different Dockerfile though (and avoid applying patches on-the-fly)
14. --
15. Standard ones? Extensions which do not need a different process run in the same container; otherwise a different container can be started

Everything else seems fine to me :)