feat: docker improvements

[oplik0]

This PR brings over most of the improvements from #8704, foregoing the move to alpine for now due to issues with sass

Summary of the changes:

• docker volumes to allow for easier changes and persistence of NodeBB config, package.json and uploaded media
• use of profiles in docker-compose file to allow usage of all supported databases
• NodeBB port is exposed to host by default, making for easier onboarding experience (users who know how to use a container native reverse proxy should also know to remove ports section. Current default has nodebb seemingly just not work)
• configurable use of installation method, with web install being the default
• configurable build before start (with default being false - currently the image works as if it was always true)
• separate rebuild stage for compiled dependencies (actually seems to yield a bit of a CI speedup, but more importantly means build deps don't have to be included in the final image, resulting in a smaller size than even the alpine image from Use Node Alpine Version as Docker image base & use Yarn instead of NPM #8704)
• mongodb container actually working out of the box with nodebb database and not just admin

NodeBB/docs#78 should be merged after this is pushed to master - though with the additional mongodb section removed since it's been fixed here.

Thanks to @stevefan1999-personal for authoring most of the changes here

[nodebb-misty]

💡 Friendly Note

This pull request was made against the develop branch, which is reserved for commits destined for a minor or major release.If your commits simply fixes a bug, please rebase this PR against the master instead.

• patch releases — bug fixes only
• minor releases — new features, enhancements, and bug fixes
• major releases — breaking changes, including all of the above

Thanks!

[CLAassistant]

All committers have signed the CLA.

[kecrily]

I think its a good time to add devcontainer support too

[oplik0]

It'd be mostly independent from the changes here, so I'd leave it for a separate PR.

I'll also probably update my quickstart plugin devcontainer PR first though, as I think it's a bit more useful (since I think more people in the community work on plugins than core NodeBB and it's a better entry point :)

[stevefan1999-personal]

It seems like I have to sign in my formal account for some of the commits I accidentally made using that. Let me handle that.

Edit: Done!

[QuietRocket]

When can we see this merged? An up-to-date docker installation is a must.

[barisusakli]

Thanks @oplik0 & @stevefan1999

[ernstki]

Hi, all.

I'm a prospective NodeBB user stuck on this issue from the forums, namely that I didn't have a local node user, this the entrypoint script for the Docker image immediately fails with

 panic: no write permission for /opt/config nodebb

Okay, I know how to work around this¹, and could easily do a PR, but I can't be sure if my workaround is breaking something else, particularly if you're using this Dockerfile in some GitHub Actions plumbing.

I know it's not your job to give Docker lessons, but may I know what the purpose of all the chown -R node:nodes, COPY --chown=node:nodes, and the (duplicate) USER nodes? Don't services within Docker containers normally just run as root?

Footnotes

1. Just create the node user on my system, would be one possible solution, if that were documented somewhere. ↩

[NavyStack]

I'm still unclear on why rebuilding is necessary for each architecture in Stage 2,
as well as the precise handling of permissions for the /opt/config/ directory.

While the final image is not yet complete, should you encounter any permissions-related errors, you're welcome to reference my image. @ernstki docker-compose.yml

1. Tini is employed to address the issue with PID=1.
2. Docker volumes are utilized to resolve permission-related issues.
3. During the initial setup, WebUI-related values are overwritten by hardcoded values from setup.json, although this is not intentional, and it is also unclear to me.
4. PNPM is opted over NPM due to its lighter weight.
5. You're invited to inspect my Docker images.

[oplik0]

I'm still unclear on why rebuilding is necessary for each architecture in Stage 2, as well as the precise handling of permissions for the /opt/config/ directory.

Rebuild is mainly for CI where aarch64 and arm32 builds are also made with qemu - it seems like IO operations are really slow in qemu, and running npm install inside the virtualized build environments took much longer than doing it once on the x86 host, and then rebuilding the few (I think two) dependencies that have components requiring native builds. It feels wrong, but substantially sped up the build in my testing. Also - it's not run if you're not doing a cross-platform build (see the condition), so the additional cost there is just copying the files unnecessarily (which really shouldn't be taking long)

Compare these two runs:

• with rebuild: 5m 9s https://github.com/oplik0/NodeBB/actions/runs/7856678742/job/21439692732
• without: 9m 48s https://github.com/oplik0/NodeBB/actions/runs/7856693161/job/21439722801

2. Docker volumes are utilized to resolve permission-related issues.

Huh, I trusted Docker docs that options for local volume driver are unsupported on Windows, which is why I thought bind mounts were the only cross-platform way of mounting directories where you want them. Turns out this was a lie, and it does seem to deal with permissions a bit better than bind mounts (it'll still break if there isn't a user with uid 1000, and for the deeper nesting I'll keep for compatibility reasons requires the directory structure to already exist, but otherwise seems to work more reliably)

3. During the initial setup, WebUI-related values are overwritten by hardcoded values from `setup.json`, although this is not intentional, and it is also unclear to me.

Did something change here? I thought they were only loaded as defaults, but no - they really do have priority over values set from the web. I guess this should be fixed.

4. PNPM is opted over NPM due to its lighter weight.

Is it actually that lighter weight? I'll probably need to do some testing, but even by PNPMs own benchmarks, NPM is comparable in the situation this container mostly runs into on startup - running with node_modules and lockfile - and since it's more "standard" and included with node, I thought it'd be a better solution, at least for the official image. The original PR at some point went with yarn instead, but also abandoned that.

And I'm saying this as someone who generally prefers PNPM :) If it turns out to be significantly faster and doesn't cause any issues I'd certainly be for switching.

[NavyStack]

1. I guess there should be a separate Dockerfile for CI.
   If I try to do a native local build on arm64, it takes forever because of Stage2.

2. There is a part in the image I created for my personal use where you can set the target OS.
   https://github.com/NavyStack/nodebb-docker/blob/6dd720dd9bdbaec05db7806f878916e228307b30/Dockerfile

3. Also, after switching to PNPM, the npm install-like behaviour of the first docker startup task is faster then before.

4. If you need to branch by specific architecture in Dockerfile, you can use the RUN case.
   I hope this helps you.
   https://github.com/NavyStack/answer-docker/blob/6ad68e1cc98c45b53fb5993f7d461becbaaf6c55/Dockerfile#L56

Use it if you need it :)

[NavyStack]

Obviously I am also PNPM lover, but I'm sure everyone has a favourite package manager, and I don't want to force it on anyone.

What about specifying a package manager in an environment variable in docker-compose.yml instead?

It's more elegant :)

[oplik0]

1. I guess there should be a separate Dockerfile for CI.
   If I try to do a native local build on arm64, it takes forever because of Stage2.

Huh, that's actually really weird, my experience on an aarch64 Linux platform (2 Ampre A1 cores) the entire second stage takes 4.8 seconds, 4.6 of which is the copy. Are you on an ARM Mac perhaps?

But if it's causing issues it might be a good idea to try fixing it, so I'll look into it more.

3. Also, after switching to PNPM, the npm install-like behaviour of the first docker startup task is faster then before.

It might've been at least in part because npm audit isn't disabled in the current image (which I'm trying to fix in #12335) - it actually takes majority of npm's runtime here :D

What about specifying a package manager in an environment variable in docker-compose.yml instead?

Hmm... I guess I could make the image respect a package_manager env variable (that can be set to specify package manager for e.g. nodebb upgrade)...