Create docker.yml workflow for automated image building

[tenekev]

I'm trying to eliminate friction points for people that want to try selfhosting Librum. This is a basic workflow that builds a librum-server image and offers tags such as :latest. The image is pushed to ghcr.io. No extra credentials needed, the package becomes a part of the repo.

The docker-compose.yml needs to be updated with the new image:

version: "3.8"
services:
  librum:
    image: ghcr.io/Librum-Reader/librum-server:latest
    hostname: librum
    container_name: librum

The README.md needs to be updated with shorter instructions:

Running with Docker

Librum-Server can be run with Docker.

git clone https://github.com/Librum-Reader/Librum-Server
cd Librum-Server
docker compose up -d

[DavidLazarescu]

The docker action run seems to fail.

[tenekev]

The issue came from your repo's owner's username.

I did some testing on another account that resembles your username pattern Capitalized-Capitalized akin to Librum-Reader and it produces the same error.

It's an oversight by the creators of the docker/build-push-action but I bet that your repo username will pop up as an issue elsewhere down the line. For now, I will sanitize the inputted strings but keep in mind the potential issue.

Here is the fix #24

[DavidLazarescu]

Thanks for the fix. I'll merge it.

[DavidLazarescu]

Do I understand it correctly that this workflow builds the docker image for the server and uploads it to a repository so that it can be downloaded for each platform?

If so, is docker compose up -d supposed to download that image in its process?

[tenekev]

This workflow builds and pushes images to GitHub's own Image Repository, opposed to Docker Hub. I though it would be less hassle for you this way because it takes the credentials from your own account (or organisation in this case). You can find your images here: https://github.com/orgs/Librum-Reader/packages.

The job logs indicate that the build and push were successful but I can't see them. Can you check yourself and confirm? Maybe they are not publicly accessible.

Here is more on how to configure public access to packages.

[tenekev]

To answer you initial question, once the packages are public, people will be able to pull them via docker pull, docker run or docker compose up if the correct image is specified in the docker-compose.yml.

The docker-compose.yml in this repo must be updated with image: ghcr.io/librum-reader/librum-server:latest. After that, all people would need to do is write docker compose up -d

Notice the lowercase in the librum-reader in the image name. That's the namespace and it can only be lowercase. That was giving the errors earlier.

[DavidLazarescu]

I have changed the package visibility to public.

[DavidLazarescu]

To ensure that all of the changes are correct, would you mind creating a PR with the image: ghcr.io/librum-reader/librum-server:latest and the Readme.md with the correct instructions?

[tenekev]

Great! I'm really happy because this is my first time doing this workflow-ghcr-organisation combo.

I'll PR the changes in a moment. I'm adding a heartbeat dependency in the docker-compose. To start the server after the database. I noticed it trips a lot of people into thinking the server isn't working for the wrong reasons.

[tenekev]

Did you figure out the database issue? I had not touched it. Just the startup order.

[DavidLazarescu]

I haven't found a solution yet, but I'm on it.

In the meanwhile I'd like to understand the whole docker process since I don't have much docker experience. From what I understand:

• docker.yml creates the image and pushes it to the github registry for packages
• the docker.yml file calls the Dockerfile in the repo which then builds the image that is pushed
• The user calls docker compose up -d which gets the image from the registry and sets up the database and everything
• The server updates the database on startup

Do I understand it correctly?

[tenekev]

Regarding the docker.yml, it does pretty much what you described. It takes the load off the end user to build+push the image to a public registry. It also ensures the environment has all the necessary dependencies and also pre-generates all the tags and labels, depending on the matrix, specified in the beginning of the workflow.

Regarding docker container lifecycle, It depends. If the definition of the container in the docker-compose has changed, Docker will recreate the container with the necessary changes. In turn, any data in the container that is not persistent (as bind mount or volume) will be lost. But this will only happen if the definition changed. The database did not change so the most it will experience is a restart.

When people update the stack via docker, they will probably delete the librum server container, delete the old image and redeploy the stack. Docker will try to find a local image but fail and then it will look in the public registry, eventually pulling the updated version.

The database container could be left running during all of this. It can also be deleted and once the stack is redeployed, it will run just like before because the conditions are the same and its data is persistent in a docker volume called librum_db.

Now, you have the same db and an updated server. I guess it should check and skip database initialization or whatever it does on initial setup because the database setup was carried over. I don't know what other updates are carried by the server on the database.

I hope I'm making sense. I'm not an expert.