Investigate offering an additional CKAN image based on a non-alpine base image

[kowh-ai]

We currently use alpine as the base image for CKAN. At the CKAN Dev meeting today (Thu. 31st Aug 2023) we discussed offering an alternative to using alpine as the base image

[themowski]

I'm actually curious about why the move to Alpine occurred in the first place -- the pre-2.10 CKAN image that was hosted in the ckan/ckan repo was based on Debian. Do you have any insight into that? Was it mainly just to keep things minimal?

[kowh-ai]

@themowski, alpine seemed at the time to be the most-lightweight (therefore one of the most secure) of the base images to use, plus the OKFN and Keitaro CKAN on Docker distro’s were using it too…however after a discussion at the CKAN Dev meeting last week we thought another base image offering could be made. Debian Slim maybe...if you have any thought on this, please let us know

[themowski]

I don't necessarily have any preference, I was just curious. I definitely agree that supporting Alpine has been a good move (aside from the small issues that have popped up recently as a result) -- it's something of a standard these days, and for most users it should work just fine.

I think something like Debian Slim would be useful for people who want to extend the image (probably to install CKAN extensions), but aren't familiar with developing against Alpine Docker images. Debian is a lot closer to a "standard" desktop Linux setup that casual Docker users would be more familiar with, and a lot of instructions for software installation mention steps for Debian/Ubuntu and Fedora/RedHat, but omit Alpine (although that situation is definitely improving as container-based deployment continues to grow).

I personally haven't tried to extend the 2.10.1 image with a bunch of CKAN extensions yet, but I will be doing that soon. Once I get into that, I may have a better idea of whether there are things I need that either aren't in apk or are just "harder" in Alpine, but I'm optimistic that that won't be the case.

I should note, if you support another base image, you'll have yet another set of configurations to manage. Not a huge problem or a dealbreaker, but something to consider -- you're already managing base & dev images for 2.9.x and 2.10.x. Is it worth adding the maintenance burden of another 4 Dockerfiles to that? Will you be able to re-use scripts, or will you end up with even more code duplication (with subtle changes)? Can you easily set up tests to ensure that all images build successfully? Can you verify that containers deployed with the images actually run correctly/successfully?

In regards to that last point, one example of a common gotcha is that the default shell in Alpine is not bash (but bash can be installed via apk), so if you're sharing a script between an Alpine image and one that has bash as its default shell, you have to be careful not to use bash-specific code in the script. The source function is one that has bitten me in the past: it's actually a bash builtin, so source script.sh doesn't work in an Alpine image by default (use . script.sh instead). This is the type of thing that would be hard to notice during development, and would not cause issues with the image build, but would immediately cause a failure at runtime.

Instead of moving forward with a new set of images, I personally would just leave this issue open for a while and see if anyone else chimes in to ask for this, or even just gives it a +1. That way, you would know that there's an actual use-case for a second set of images, and you can better justify spending the time to design out how best to support that.

[kowh-ai]

@pwalsh - Following from our conversation this morning, this is the issue/discussion I started last year on moving to a new base image rather than using alpine. We could include here potentially using GitHub Actions to (weekly) scan our newly built images and produce a report we could manually look at...

[kowh-ai]

Linked issues: #46 and #47