Podman initContainers

Introduction

CUBE has some initialization steps, notably database migrations.

https://github.com/FNNDSC/ChRIS_ultron_backEnd/blob/5dfdaa2acc383899c8ad8e4e770ecd7507be0cd1/docker-entrypoint.sh

Kubernetes initContainers are the proper way of running these operations. Podman supports initContainers, however the system works differently than real Kubernetes. This article explains the shortcomings of podman play kube and the workarounds.

Even though the workarounds for not using initContainers in Podman are simpler than the workarounds needed for them, miniChRIS-k8s chooses to use initContainers so that the running Podman setup is cleaner and closer to how it'd work in Kubernetes.

Fundamentally, to run ChRIS using Podman all you would need is

cat podman/kube/*.yml | podman kube play -

The script podman/minichris.sh implements some workarounds and quality-of-life output behavior.

Sequential Pod Creation

Podman creates pods in the order they are defined. Since the initContainer migratedb of minichris-cube depends on minichris-postgres and minichris-postgres must be created by Podman before minichris-cube.

The file names in podman/kube are prefixed with digits, which orders the pod definitions. The file defining CUBE is named 99-cube.yml to guarantee that minichris-cube is created last by Podman, after the creation of minichris-postgres.

initContainers run during podman kube play which lacks progress reporting

initContainers run to completion during podman kube play. They might take a while (~30-120 seconds). Unfortunately, the command podman kube play does not print anything until it finishes. ./minichris.sh polls for the existence of the init container and runs podman logs --follow minichris-cube-pod-migratedb, so that it is more clear to the user that the script is not frozen.