Provide a ready-to-use Docker Image of the Portal

[boldt]

Let's provide a ready-to-use docker image of the new portal on Docker Hub. Like this, thus the deployment of a portal is much easier and requires the use of only 3 images:

• postgres,
• keycloak and
• obs-portal

The build of the image can be handled by Docker Hubs Automated Builds:

• https://docs.docker.com/docker-hub/builds/

[boldt]

Docker Hub does not allow "free" orgs any more. They only provide payed plans now.

Thus, let's use the "Github Package Registy" to host our images:

• https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
• https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-docker-registry

Github Actions:

• https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions
• https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

[amandel]

For a web based flasher I've created also a container that hosts all static content, can be directly exposed as https://install.openbikesensor.org/ or might be integrated into the portal? We need to think about it, whichever is better to maintain. For a new version of the firmware a new container is needed, since it is only needed for the initial esp flash, updating to the latest release is not "urgent".

The container is build as described above but not pushed to the registry yet.

Background for the container: openbikesensor/OpenBikeSensorFirmware#275

cc @opatut

[opatut]

We could try out the github registry with the very simple flasher image. Then, if that works, we can consider building a docker image in github CI for the portal.

For integrating the ESP flashing logic into the portal I'd make another ticket -- for later. Until then I'm happy to set up an install page from your image.

[opatut]

@amandel see #125

[amandel]

So the image with the installer is now at ghcr.io/openbikesensor/openbikesensorflasher:main build with https://github.com/openbikesensor/OpenBikeSensorFlasher - with every commit.

[notudu]

I would also suggest to face a longterm development with split components.
And yes, I would support a "All in One" docker container for testing purposes. (I wasn't able to create a working setup with the available information. There are some missing links...)
For example a DB Cluster for postgres and HA Proxy as TLS terminating frontend with multiple application backends to provide scalabitlity. Connection from portal frontends via pgbouncer to DB? Is there a description of the working principles or an architectural sketch of the system available?

[opatut]

That sounds contradictory, why would you want an "all in one" image that gives you a whole cluster with proxies and load balancing and whatnot? I don't understand what the purpose of this would be. IMO, you would either:

• Install a highly available cluster of components separately, manage each well on its own, and connect them via LBs and proxies and the like to provide the most stable and performant solution.
• Install "the simple case" to get off the ground, a single image with all you need inside of it.

Also I don't think it makes sense to integrate the DB and the keycloak into the image, as there are well maintained images of these components available and you'll need to manually manage them anyway, even in the simple setup. You can't just have "a default installation" of keycloak -- it needs your manual intervention to be your keycloak. Same for the DB. I would rather treat them as "external services" that the portal connect to, than part of the portal itself.

[notudu]

You need to split dev and prod.
In a prod environment it is highly recommended to separate frontend servers from DB and IDP.
Best practise is to put all those different services in their own network segments.