test new Dockerfile with s6-overlay

[paspo]

I created a new Dockerfile which aims to manage hbbr and hbbs services with s6-overlay.

At the moment, since I don't know the details of your CD system, this doesn't fetch the precompiled binaries, but rather it builds them itself using a rust:alpine container.

[paspo]

The final release container is build against the busybox image, which is even lighter than alpine.

Both services are running with /data as workdir so this is the only necessary volume export.

You can specify the relay using the RELAY environment variable.

[rustdesk]

Thanks

[paspo]

@rustdesk we were supposed to talk about that, before merging...

I mean: there are a couple of points I would like to address:

• multi arch builds
• put all docker images (for a specific tag) in a single docker image (with manifest) so that you can always use rustdesk/rustdesk-server:latest and the host will choose the right image for the current architecture
• maybe some info on the build system would help

At the moment this is building from source, and it's targeting the latest branch. Ideally you want the build system to build on a specific branch/tag.

I think we should start from the last point, the build system. What are you currently using?

[rustdesk]

• in a single docker image

I do not know if it is convenient to build a single docker image for different archs with Rust cross-compile on one machine.

[rustdesk]

branch/tag

Latest is ok, rustdesk-server won't be updated frequenently as client.

[paspo]

• in a single docker image

I do not know if it is convenient to build a single docker image for different archs with Rust cross-compile on one machine.

Let me explain better.

Look here and here: the rustdesk/rustdesk-server has 2 images, one for each arch; instead, busybox:latest is a multiarch manifest that is pointing to multiple images, one for each arch.

That way, you can do docker run ..... rustdesk/rustdesk-server:latest on amd64 or arm64v8 or i386 and you get a running rustdesk-server without caring for the correct tag.

I'm assuming that there's no automatic build system, we can start with that. Ideally we should have a system that run tests on every push to master/main branch, and builds (and publishes) docker images on every tag (on master/main).

I have almost zero experience with github as a CI/CD tool, all my repos are on a different server (I don't trust Microsoft) and I mainly use Gitea + Drone; but I worked with Jenkins and others, I think I can give github a try.

[rustdesk]

Honestly, I have no such experience either, all our CI/CD are written by contributors.

[rustdesk]

I think I can give github a try

Thanks

[mini-bomba]

Honestly, you should've marked this pull request as a draft if it wasn't ready yet. I guess it's time to open another draft PR with more changes...
Also, I've found this page about publishing docker images from GH Actions: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images
Another thing: I think it would be wise to remove source code from the image, to cut down on the image size.

[paspo]

Honestly, you should've marked this pull request as a draft if it wasn't ready yet.

You're right... as I said, github is not my main tool...

Another thing: I think it would be wise to remove source code from the image, to cut down on the image size.

That was the point of the discussion. I didn't know how the binaries were made (now I know: manually), and I needed to build the docker images starting from the binaries. I really didn't think to use this Dockerfile as-is (because, you know, minutes of build time), the draft-marking would've been a real blessing.

I'll work on multiarch rust compile with github actions, then I'll add the image creation. When everything works (on my fork), I'll PR.