Enable local development via `podman` and `buildah`

[jayaddison]

Is your feature request related to a problem? Please describe.
Currently it's challenging and time-consuming to set up a local development environment because there is an assumption that the developer will run a CRI-O-backed Kubernetes cluster.

Describe the solution you'd like
The buildah and podman tools can run in unprivileged userspace and build containers that are compatible with CRI-O Kubernetes.

Indeed, openculinary projects already use these tools to build and push (but not run) these images.

These tools could be a good fit to allow developers to run containers locally for each of the openculinary projects.

Questions here include:

• How would inter-service communication be organized in a local dev environment like this?
• Would persistence be supported via volumes?
• Is there a migration path whereby a single service could be migrated before others, in order to evaluate this approach?

Describe alternatives you've considered
docker-compose would be an alternative route to take here -- essentially, we could define a compose file to define and configure the set of services required.

This has a short-term benefit of being a relatively widely-used tool and a relatively straightforward solution. It does introduce a larger attack surface and requires a privileged install environment since a Docker daemon is required.

[jayaddison]

👨‍🍳 💋 https://github.com/containers/podman-compose

[jayaddison]

Regarding persistence: investigate overlay mounts in podman (-O command-line argument) - https://github.com/containers/podman/blob/e8f48a11b6100c6d0ec21366c66a95fd7abfd154/docs/source/markdown/podman-build.1.md

[jayaddison]

A functional syntax for bind-mounting the local directory into a running container via podman run is: --mount=type=bind,ro,src=web,dst=/web,relabel=shared

[jayaddison]

During work to investigate openculinary/frontend#255 I followed a local buildah + podman based workflow.

I achieved that somewhat successfully without any multi-container environment; I simply repeatedly rebuild the frontend application container, and then ran it locally.

One challenge was that api responses are usually retrieved from the same-origin as the frontend application is running in. I found that a reasonable workaround for that, in the case of API search results (/api/search?include[]=...) was to place a static JSON file, in the same format as the production API response, into a file named static/api/search.

Doing that meant that the local application would attempt to query that URL using an HTTP GET request -- and the query-string parameters would be ignored by nginx and the static file would be served as a response, usable by the client application.