Closed perennialtech closed 3 months ago
It's great, but I have wanted to have inv_sig_helper inside scratch image so that there is nothing that google may exploit from if they really want to.
Something like this:
FROM scratch
COPY --from=builder /app/app .
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
CMD ["./app"]
It's great, but I have wanted to have inv_sig_helper inside scratch image so that there is nothing that google may exploit from if they really want to.
I'd tried to use a scratch image for the second stage but had issues with OpenSSL dependencies initially.
I've pushed a commit that implements a scratch image, but the trade-off is that the Dockerfile is now more complex, as we need to compile OpenSSL from source for musl.
Just realised that we can skip building OpenSSL for musl if we use an Alpine-based Rust image for the build stage; see 6e195d4860edc972c9b78748ba47fea51327253b
I'd appreciate your thoughts.
It's great but the final goal is to have a multi architecture docker image.
Because invidious does not support only x86.
@unixfox Multi-arch builds in 1547376f2a8446923c1e5bb6dd21a56de70915b6 seem to be working now, with the resulting image loading the correct binary (at least on AMD64).
Great, awesome! We might even be able to add build to quay.io?
You can take example on https://github.com/iv-org/invidious/blob/master/.github/workflows/build-stable-container.yml and I'll add the correct tokens for quay.io login
Would you mind checking if you could lock down the container by removing some capabilities like searxng is doing: https://github.com/searxng/searxng-docker/blob/master/docker-compose.yaml?
I think we will only need NET_BIND_SERVICE
but I'm not sure.
And could you set read_only: true
in docker-compose? https://superuser.com/a/1635761
Credentials were added for quay.io: https://quay.io/repository/invidious/inv-sig-helper
@unixfox Added a workflow to build and push a container image to quay.io in 95b602e9f4661e1beee2fc57384cd98a574335d2
Triggers on pushes to master and version tags, with semver used for tagging (e.g., 0.1.2
). Also includes a quay.io expiration label like the Invidious workflow
Let me know if any changes are needed
I think we will only need
NET_BIND_SERVICE
but I'm not sure.
NET_BIND_SERVICE
shouldn't be necessary since we're binding to 12999
(so not a port number less than 1024), but can't test at the moment though
Could you try to run under a non-privileged user in scratch: https://medium.com/@lizrice/non-privileged-containers-based-on-the-scratch-image-a80105d6d341?
Is there a way to include a healthcheck:
in a docker-compose.yml
?
E.g. some endpoint
healthcheck:
test: wget -nv --tries=1 --spider http://127.0.0.1:12999/REPLACEME || exit 1
interval: 30s
timeout: 5s
retries: 2
Is there a way to include a
healthcheck:
in adocker-compose.yml
?E.g. some endpoint
healthcheck: test: wget -nv --tries=1 --spider http://127.0.0.1:12999/REPLACEME || exit 1 interval: 30s timeout: 5s retries: 2
inv_sig_helper doesn't use the HTTP protocol, so just check if the port is still open? (or use one of the opcodes that do nothing but return info like PLAYER_STATUS
, and see if the server responds with something)
Is there a way to include a
healthcheck:
in adocker-compose.yml
?E.g. some endpoint
healthcheck: test: wget -nv --tries=1 --spider http://127.0.0.1:12999/REPLACEME || exit 1 interval: 30s timeout: 5s retries: 2
No. It's going to be the development docker compose not the production one. A production docker compose will be published under https://docs.invidious.io
Since we're using a scratch image, I don't think healthchecks are possible unless we copy a utility like netcat from an earlier stage
Not sure how to meaningfully improve the Dockerfile as of 6b947181519bb2b32ef9cc1ee4ac1d88972539c4
The target arch detection isn't overly complex and doesn't hard-code architectures in the build process, and image tests via docker run --platform linux/amd64
and docker run --platform linux/arm64
show the binary being loaded and run correctly
Thank you for all the effort @perennialtech!
It's already a very good start. We will see another time if we need to improve the Docker image, for now it works great.
Thanks for your contribution @perennialtech
This PR introduces containerisation support for
inv_sig_helper
and improves documentation:Fixes #3.