Create non-Alpine, Debian/Ubuntu images

[amercader]

Alpine's own peculiarities (particularly its use of musl instead of glibc) sometimes causes problems that are hard to track down (see eg amercader/ckanext-embeddings#4). Alpine was used as a base image originally to reduce the image size, but given that CKAN itself is not a micro-service where this might be important when deploying, I think most users would prefer the predictability and convenience of working in a Debian/Ubuntu based image.

Image	Size (linux/amd64)
alpine:3.19	3.25 Mb
debian:12-slim	27.77 Mb
debian:12	47.26 Mb
ubuntu:22.04	28.17 Mb

My personal preference is to use the Ubuntu one as this aligns with what we support in the Deb packages and the source installs, but happy to hear other thoughts.

We should tag these images differently, ev ckan:2.10-ubuntu

Note that the Keitaro folks have been maintaining Ubuntu based images for a while: https://github.com/keitaroinc/docker-ckan

[pwalsh]

I support Ubuntu or Debian slim, and dropping Alpine completely

[wardi]

I'd choose debian slim because ubuntu sometimes breaks things that work fine in debian. @EricSoroos did you have a more compelling reason to prefer debian over ubuntu?

[EricSoroos]

Really I like either -- Debian is pure open source which is probably an advantage. I wouldn't expect large differences between the two images though.

[kowh-ai]

I'm happy to try building seperate CKAN test images using Debian (slim) and Ubuntu...just to see what issues appear for both, if any...and then report back here to vote

Another thing to consider is do we pin base image versions down to specific builds?

Keitaroinc uses specific builds for it's Ubuntu CKAN images, however if we did this we would miss out on any security patch updates if we used a more generic tag base image approach. We have discussed this before. I'm thinking we go with generic (to capture new security updates) however if we experience breakages outside our comfort zone we pin to a specific build

[EricSoroos]

Definitely go with distribution pins -- e.g. debian-bookworm or ubuntu-focal. I'd even push for a dist-upgrade in the initial phases of the build, possibly as a base image because of the general stability of the update process* is enough that we're likely to see more problems from security issues than upgrades.

The other issue to think about is the lifetime of the base image that we're using for the major release, because of the version of python that's packaged there. Focal (20.04) is 3.8, Jaunty (22.04) is 3.10, 24.04 is going to be 3.12.

A further wrinkle is that we could use the python3.x-bookworm images -- pinning a specific major python release using the underlying bookworm issue, and then get the python updates from the python core instead of debian's packaging.

(* I've been doing dist-upgrade on live servers for 20 years or so, and can't remember the last time debian stable or ubuntu LTS badly broke something in that time. (dist-upgrade is the upgrade but install new dependent packages that might not already be installed, it's not major stable -> stable+1). Docker on the other hand...)

[EricSoroos]

Addressing the size issue -- I think the overall image size advantage for alpine goes away when you install gcc & g++.

[pwalsh]

Following on from @EricSoroos on a few points:

• I also do dist upgrades on live servers as part of automated deploy scripts, across Ubuntu and Debian, and actually never had a significant issue, so doing it as part of build in the base image sounds reasonable to me
• Whichever ubuntu, debian release etc, it is probably good to build again a couple of python versions, and not just rely on the version distributed with the image
• Definitely need to pin, according to some pinning logic

[kowh-ai]

I have a preliminary Ubuntu 22.04 base image working locally with minimal testing

• A separate Dockerfile for Ubuntu 22.04 (Jammy) released August 2022
• Makefile will run a separate build commands, with a new one to create a new (Ubuntu) image, which will be then pushed to DockerHub
• The Debian Slim image can also follow this process
• Used the default gcc libraries on Ubuntu 22.04 (rather than v10.x as Keitaroinc have done)
• Installed wget as it’s needed for the Docker compose healthcheck and didn’t want to include a change to ckan-docker to accompany this change
• Installed uWSGI using apt-get rather than pip3
• Could be a good time to change any uWSGI parameters. I had to update the plugin config to use python3 as the python plugin isn’t included
• Haven’t used Multi-stage builds to get images smaller. Should we do this? Keitaroinc use multi-stage builds. Is this still good practice?
• I haven’t looked at combining commands to decrease the number of layers yet
• The Ubuntu image size (uncompressed) is 1.02 GB without yet attempting to reduce it (the equivalent Alpine image is 1.89GB
• Python version shipped in the Ubuntu 22.04 base image is: 3.10.12

UPDATE:
I also have a preliminary Debian 12 base image working locally with minimal testing

• Straightforward after doing the work on Ubuntu
• The only major difference is that Debian 12 requires CKAN (or any pip-based install) to be installed into a Python Virtual environment
• The app paths are the same ie: /srv/app/src/ckan with /srv/app/ being a virtual environment in Debian
• The Debian image size (uncompressed) is 1.22 GB, no reduction in image size has been put in place (yet)
• Python version shipped in the Debian 12 base image is: 3.11.12