Official Docker image for the application

[yitsushi]

We have two separate PRs to discuss the topic (see #466 (comment) from @AlyxPink), and I think it's more like a Discussion thing and not a PR thing as we are not talking about the PR really, we are talking about how we want to handle it. Do we want an official one or not, and in both cases what's the next step?

Related discussions (PR):

• feat: add Docker image build on prod release and publish to ghcr.io #501
• Add Docker image to make it even easier to distribute Phanpy #466

I try to collect some key components:

I thought about this and thinking that it would be better if this is done separately from official repo, as I'm not the one maintaining this and I don't plan to spend time or learn how to maintain this 😬
@cheeaun #501 (comment)

Well I prefer official[^1] images because I can spin up a test container to see how it works, deploy easily without the need of...
@yitsushi #501 (comment)

[yitsushi]

I think I summarized my stance on the topic well here:

Well I prefer official¹ images because I can spin up a test container to see how it works, deploy easily without the need of

1. creating a dockerfile.
2. create a repo for it, so it's in a save place.
3. build the docker image every time.
4. store it somewhere in an OCR repository (dockerhub, ghcr, etc).

I'll not build docker images on the server my applications running, if I'm not at a computer where I can build one, the application will not be updated until I can sit down somewhere to build it (that's why I spend extra time creating github actions with manual triggering²). It's a lot more work and resources if I can access my raspberry and build there because that's arm and my VPS is not arm, so that's xbuild.

That's a lot of extra work instead of just using an image, even get notifications when new image is available and just update the image tag.

Right now my solution is a GitHub action that I can trigger manually with a build arg to get a new image without running any docker commands, I can even kick off a new build from my phone. I have a few projects with this logic because those don't provide an official image (or there is not reasonable image), so it's fine by me, but other's may get annoyed if they have to build their own image all the time.

Like imagine a person who uses a homelab with something like portainer. They want to host it themselves, but they may don't have environment setup to build docker images as they are using pre-built images only. In that case they will head to one of the search engines and try to find one which might or might not updated.

My plan for now is to add a cron job to my builder github workflow to check if there is a new tag on this repo and build a new one automatically. But that's the most I can do on this front as there is no way to trigger an action of a separate repository without sharing secrets (like I would have to give @cheeaun a personal access token to my github account, well I wouldn't do that). At least I don't know any other ways than calling github's dispatches api endpoint.

Footnotes

1. Official, or at least something that's not like a "I built it once, use :latest, be happy, and maybe I update it sometimes, maybe not". ↩

2. Like this: https://github.com/yitsushi/phanpy-docker/actions/workflows/build-and-publish.yaml I just start a new build when I get notifications from Releases RSS feed. ↩

[yitsushi]

In theory this patch on my docker image should build a new image when a new release is created on this repo. In theory because I don't know if it works really until a new release is out. It checks every 6 hours if there is a new one or not.

[yitsushi]

Just reporting back: My job works, so all new releases has a new build automatically on my repo. It's running every 4 hours now.

ghcr: https://github.com/yitsushi/phanpy-docker/pkgs/container/phanpy-docker

[burntcookie90]

gonna start with a response to @AlyxPink (#466 (comment))

@burntcookie90 good job 👌 Just to get an opinion, would you rather keep using your own build or you'd prefer having an official one?

I dont necessarily prefer an official one over my own, but I do prefer a well maintained image (third party or not) over maintaining my own. linuxserver.io is a good example of an image maintainer that I trust and run locally.

I think given @cheeaun's (totally respectable) lack of interest in maintaining a first party image, the best move for the repo would be to make sure that instance specific configurations can be safely and clearly managed by third party installations.

in response to (#501 (comment))

Is it possible to trigger docker builds without GitHub Action set on the official repo? Maybe trigger GitHub action from your own repo based on push or releases from a this (remote) repo 🤔. Or, maybe there's some webhook thing to auto-trigger this?

Technically yes, but iirc it either requires that the repos live under the same owner/org and share an app token. I think the normal procedure is that the image maintainer puts out nightly builds from main and tagged builds when the upstream has a release.

[Nitrousoxide]

As an alternative if you don't want to manage the whole ci/cd pipeline. You could add a simple dockerfile to your repo like this one:
#257 (comment)

And a quick one-liner docker/podman build and then run command in the readme.
podman build -t phanpy:latest .
podman run -p 8080:80 phanpy:latest

That would get a working version up for everyone who wants to self-host.

Maybe there's some volume mounts they would need to as well to let auth tokens and session settings survive redeployment of the container. I dunno where that would be.

[benjaoming]

Firstly, I think that it's great to run Phanpy locally. It would be fantastic if it was easier to "install" Phanpy this way, rather than relying on online deployments, which may be under control of an unknown or untrusted party.

I'll try to summarize the points that I find difficult - and which I think need a decision before anything official is done:

1. Declare if the Docker image is intended for localhost usage or public-facing. At least, clearly declare that it's not suitable for public usage.

2. I think there are issues about using localhost, too, because localStorage might be accessed from other browser session apps running on localhost (Add Docker image to make it even easier to distribute Phanpy #466).

3. It's possible that Phanpy chooses an approach whereby local configuration happens in npm build. If that's the case, then it makes more sense that users build their own Docker images following a documented recipe.

4. Phanpy is updated very often, therefore the Docker image has to be pulled and redeployed often, too. At this stage, I think that we might as well assume that some pre-existing Docker experience is necessary.. installing Docker is a challenge in itself.

In conclusion, I think it's better to aim for an officially endorsed documentation section about Docker-based local deployments and self-hosting. Using a documentation-approach allows to elaborate on necessary discussions, so the reader is well-informed. This also fits a "target group", i.e. people who will install via Docker already know something about it and can follow a recipe from documentation.

[b2cc]

I have added a simple Dockerfile for public-facing deployments in this PR: #883
Tested and works.

[yitsushi]

We already had PRs for that, one is still open. For example #501 this one is in use from another repo with automated builds on release.

[b2cc]

The one in from #501 just adds the contents from the tar.gz release to an nginx container. Mine is more geared towards development since it actually uses a node container to build the app.

Anyways, if you deem it not useful please feel free to close the PR.