search

souramoo / commentoplusplus

Commento with out of the box patches and updates to add useful features and fixes. Also with one-click deploy to Heroku so you can get up and running fast.
MIT License
389 stars 62 forks source link

rework Dockerfile (dependencies, distroless, non-root) #89

Closed Wonderfall closed 2 years ago

Wonderfall commented 2 years ago

I've had this in mind for quite some time (also thanks to this PR on the original project for the inspiration!).

We disable CGO to make sure we produce static builds that can run in a "distroless" environment (that is, a minimal environment providing nothing more than ca-certificates and the like). That will reduce the final image size and reduce the attack surface of the container for those who deploy Commento that way.

We don't need to run Commento as root. That was the case before (if no user is specified, root is used by default), and this meant that on traditional Docker installations, root in the container was also root on the host, and that is not desirable or needed since there isn't any volume to mount, so the change should be painless even for existing installs.

I took the liberty to update the other images used for the build, and I reorganized the Dockerfile to make it so the main build-time variables are at the top. This makes it easier to maintain. Current version of node-sass prevents building with Node v16 (it would be nice to update to the last LTS), so let's use Node v14 for now.

Also, what do you say about publishing the Docker image in the GitHub Container Registry and link it to this repository? The current Action doesn't seem to be enabled too (the Docker Hub image hasn't been updated for quite a while).

olof-nord commented 2 years ago

Speaking of Container Registries, I noticed that the new Dockerfile is using gcr.io for its distroless image.

What speaks for or against using Google/Docker/GitLab/GitHub/others container registries ? For pushing, and/or as for their base images.

I noticed that Docker Hub introduced some pull limits some time ago, is that also the case for other registries?

olof-nord commented 2 years ago

Additionally, I took the liberty of creating an issue as not to forget the node-sass frontend library upgrade, hope that was ok.

Wonderfall commented 2 years ago

What speaks for or against using Google/Docker/GitLab/GitHub/others container registries ?

I guess it mostly depends on your ecosystem. Also Docker Hub was quite popular at the time (and is still the "default registry" in many OCI tools), Google uses its own registry internally (for instance distroless and cadvisor), GitLab might be nice if you're already working with it. I find the GitHub Container Registry particularly nice for GitHub-hosted projects since it avoids relying on additional third-parties and is well-integrated in the repository.

Worth noting that Docker Hub has an attached Notary server which helps setting up Docker Content Trust for signed images. But there's an alternative called cosign which works with any OCI registry, which is what GitHub recommends.

Wonderfall commented 2 years ago

Thanks for the work! Think it's safe to update to Node v16, I'll try later before pushing a new commit.

Also you should only set amd64 and arm64 in your Docker workflow, other architectures will result in the current errors you're having, because official images don't support them sadly.

souramoo commented 2 years ago

Thank you for this and all very good ideas! I have managed to get all of the github actions workflows working now and the docker image should publish to both docker hub and ghcr.io. I am happy to merge once you are happy with it - node 16 should work fine now!

Wonderfall commented 2 years ago

Yup! You should also change the package visibility for the container from "private" to "public" so we can grab it. :)

souramoo commented 2 years ago

Apologies - an oversight on my part! It's now set to public and have merged the new dockerfile. The docker CI is also running so the new docker image should be published shortly :)