[Technology] Galton Boards and OCI Containers

A friendly recently showed me a Galton Board.  Think binomial distributions and maybe even Plinko.  (Wiki, and a simulation by Wolfgang Christian.)

I ended up implementing one of my own using TypeScript and as an excuse to play more with podman (an OCI container manager like Docker).

You can find the source code on gitlab and run it there, too: https://aquarichy.gitlab.io/kosmo-galton

Here are some random notes from the effort:

• Gitlab pipelines for to deploy pages only work on the default branch.  I tried to work on my .gitlab-ci.yml file in a side branch and that didn't work.   Oops.
• I had a path hard-coded in my Makefile that I didn't really want to expose, so I had some in git fun branching to its commit, editing, rebasing, and then clearing my reflog and doing some gc. :D
  
• Since typescript is available for npm, using the node:lts image that gitlab likes to suggest is great.  Just need to do "npm install -g typescript" first.
  
• Podman images: I played with a variety of Containerfile approaches to look at resulting image size.  See below.

Containers

I played around with single and two-stage Containerfiles.  The point of two stage was to have typescript's tsc available to compile the code within a container, without needing to carry nodejs in the final image.  In general I used Apache's httpd.  

I appreciate that images are stored as layers and common layers are reused, so making use of, say, a 1GB container image (node) in 3 images of my own doesn't result in 3GB of additional disk space used.  Still, I find it valuable to be conscious of space and memory usage, and minimizing unnecessary files when preparing and deploying software.

Also, while I may "save space" by using smaller images, in this case, that results in extra network I/O and CPU time as I now end up needing to use dnf/microdnf/apk/npm to install nodejs/npm/typescript (depending on combination).

Single-stage:

1. httpd: Pre-transcompile .ts into .js outside of the image; then use docker's httpd image and just add my HTML/JS/CSS files to it.

Two stage (first compile ts; second deploy in Apache)

2. fedora-minimal>httpd: First stage, start with the fedora-minimal image from registry.fedoraproject.org, install its typescript using microdnf (pulls in node), transcompile .ts; second stage, start with httpd again and copy over transcompiled .js, and add HTML/CSS from outside of the image.
3. node>httpd: First stage, start with node image from docker, install typescript using npm, add and transcompile .ts; second stage like #2.
4. alpine>httpd: First stage, start with tiny alpine image from docker, add npm using apk, then install typescript with npm.  The rest like #2 and #3.
5. alpine>alpine: First stage, same as #4 using alpine; stage two, start with alpine again, add apache2 with apk, copy in HTML/CSS/JS as before, and add CMD to store httpd in the foreground (warning: dumb, simple configuration; not appropriate for real usage as is) 

For base image sizes:

• docker.io/library/alpine: 7.63MB
• registry.fedoraproject.org/library/fedora-minimal: 97.8MB
• registry.fedoraproject.org/library/fedora: 196MB
  
• docker.io/library/httpd: 173MB
• docker.io/library/node: 1.12GB

 For my intermediary and final images, I end up with:

Approach	Stage	Image description	Modified image size	Base image size	Note
1	(n/a)	httpd	173 MB	173 MB	No notable change!
2	1	fedora-minimal + nodejs, typescript	332 MB	97 MB	nodejs + typescript add a lot
3	1	node + typescript	1.18 GB	1.12 GB	node image starts off big
4	1	alpine + npm, typescript	133 MB	7.63 MB	nodejs, npm and typescript adding a lot again
5	2	alpine + httpd	13.5 MB	7.63 MB	so tiny vs. the 173 MB httpd image!

This makes it worthwhile to tag and have a container with TypeScript set-up already. :)