Run ckan and dependencies from a venv, add maintenance user

[wardi]

This would let us

• remove warnings on package install about overwriting system-maintained files
• install dependencies as an unprivileged maintenance user (separate from ckan user) so that admin tasks in the container aren't all done as root (use https://docs.docker.com/reference/dockerfile/#user to set this as the default for docker run use)
• in development use a volume for complete installed virtualenv including bin and other folders, and one for the maintenance home directory for conveniences like .bash_history

In development we can set up an entrypoint that syncs the maintenance UID and GID inside the container with the ones from the mounted /srv/app/src_extensions folder. This lets us do things like create extensions from templates or edit/create files and directories while VS Code debugging without creating a bunch of root-owned files in the host directory.

[wardi]

maintenance likely isn't the best name for this user, any other suggestions?

[kowh-ai]

@wardi - Iv’e created a new branch of ckan-docker-base and have been working on getting rid of root owning all files. This will be the first change to make our Docker setup a bit more security focused

I have a Dockerfile to do the following:

• install system libraries, ckan software etc as root
• change the ownership of all ckan directories and files to a non-root user/group (in my case I use “ckan-sys/ckan-sys”)
• run ckan processes as this new user

I could have used “ckan/ckan” but maybe we want to just run the processes as the ckan user

As far as the bind mount ie: src/ directory on the host machine mapping to the src_extensions/ directory in the running ckan container I’m struggling to get this to do what I want. The documentation says the uid/gid of the directory on the host will determine what is used in the running container. However it seems it will only use the root user in the container. I’ll keep digging here to see how I can change this..

Happy to hear your thoughts

[wardi]

Would you explain "it will only use the root user in the container"? When I add a bind mount in docker all the uid/gid values in the mounted directory are the same inside the container as outside. Typically I'm mounting my user's files so everything is 1000/1000

Happy to see work on this! Is there a reason to install as root then chown instead of chowning the directory then installing as ckan-sys?

In my ideal development setup I'd like to have one user account mapped to the same uid/gid as the mapped src_extensions directory, (ckan-sys?) this user would own all the ckan install files and installed python libraries.

A second user (ckan?) would be used to run the ckan process, it would own the upload directory but not be able to write to the source or installed python packages for better security.

[kowh-ai]

@wardi - for some reason files on the bind mount within the container were getting created owned by root...didn't matter what the file ownership was on the host...Now that I hear it works for you I'll keep digging and find out what my problem seems to be.

It was just easier to install as root and then change ownership to ckan-sys rather than updating permissions on directories to allow a non-root user to install into them (and then changing permissions back)

Thanks for the info on how you would like the setup to be. This is very useful and what I was thinking too.