Mmm that’s a good point. The smaller attack surface is something I harp on about a lot when it comes to making minimal images. That’s actually led me down some very fun rabbit holes about operating systems and Linux in particular.
For instance, here’s the Dockerfile for ubuntu:latest. It’s actually quite minimal with the majority of the work being done by “ADD ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /”, which can be found at https://partner-images.canonical.com/core/bionic/current/ubuntu-bionic-core-cloudimg-amd64-root.tar.gz. When you open that up, it’s just a small Ubuntu root file system. Now what does that get us? First I’ll backtrack.
When the host boots, GRUB 2 finds the desired Linux kernel, loads the kernel and the initramfs, and then transfers control to the kernel, which runs the initramfs’s /init script (which typically invokes systemd these days). That /init script finds the “real” root file system, mounts it, and then executes systemd on the real root file system, which acts as the init system and becomes our old faithful PID 1.
Obviously that process doesn’t correspond to a container’s lifecycle. When a container is started, the kernel is already running and the root file system is already mounted. There’s already kernel mode and user mode code running to manage the computer. Docker gives us isolation using Linux kernel features like cgroups and namespaces, and takes care of special file system cases like /dev, /proc/, and /sys for us.
So a person doesn’t need a whole OS file system just to run a single program in Docker.
However, in our case, it gets complicated quickly, since Koha needs MySQL client libraries, Zebra client libraries, and whatever other libraries and files our Perl modules need (DateTime leverages OS-level datetime files I think, there’s libxml, probably GD, etc.). If we were really thorough, we probably could get Koha running in a very minimal container, but it would take some work. It could be fun though.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Kyle Hall
Sent: Tuesday, 18 February 2020 10:43 PM
To: Julian Maurice <julian.maurice@biblibre.com>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Minimal docker images for Koha
This is fantastic Julian! The only thing I can contribute that hasn't already been said by you or David is to suggest taking a look at MiniDeb as a base image ( https://github.com/bitnami/minideb ). I would also suggest using quay.io to build and host your Docker images, as it has built in security scanning. I prefer minimal install images not for size reduction ( though it is nice ), but for the smaller attack surface they provide. Fewer things installed means fewer exploits available!
Kyle
---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Feb 17, 2020 at 12:59 PM Julian Maurice <julian.maurice@biblibre.com> wrote:
Hi all,
I've been playing with docker lately, and I tried to build a minimal
docker image for Koha. Here are the results.
My goals were:
* Install only required "things" to get Koha up and running, and nothing
else (no testing or dev tools),
* No external dependencies except CPAN
* Follow Docker best practices as much as possible
The resulting images are here:
https://hub.docker.com/repository/docker/julianmaurice/koha
and the Dockerfiles are here:
https://github.com/jajm/koha-docker
A few things worth mentioning:
* I tried to build the smallest image possible by using alpine or perl
slim images at first but it was not that great, because the perl version
shipped with those images is missing some libs, which cause
MARC::Charset to build a database of several hundreds MBs (which is only
5MBs with a standard perl version). So I chose a more standard image
(debian:buster) as base.
* Koha doesn't work well when running with a perl version different than
the system perl installed in /usr/bin/perl. For example, the
updatedatabase doesn't work when called from the web installer. This is
because Perl scripts are called directly as executable files, and
shebangs contain '/usr/bin/perl'. Same problem from
misc/translator/translate which calls tmpl_process3.pl.
* I tried to make the Koha installation as self-contained as possible.
Almost everything is installed as a non-root user in /home/koha,
including Perl dependencies.
* It doesn't need a reverse proxy such as apache or nginx. The necessary
URL rewriting is handled in PSGI file. The container expose two ports,
one for intranet, the other one for OPAC.
* Each Perl dependency is installed in its latest version, so expect
things to break. I can only confirm that the webinstaller, basic
cataloguing and search/indexation work. I did not test anything else.
* There are docker-compose.yml files in the github repository to get
Koha running quickly with mariadb, memcached and elasticsearch.
* Zebra is not installed
* Images weigh ~1.15GB uncompressed (koha sources included)
If you made it this far, thanks for reading :)
And if you want to use these docker images, you should start by reading
https://github.com/jajm/koha-docker/blob/master/README.md
--
Julian Maurice
BibLibre
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/