Add a nginx-unit -based image

[ananace]

This sets up a new variant for nginx-unit, based on their nginx-unit PHP image and the Nextcloud example in their documentation.

Probably related to #1063 - though ths solution is different than the one suggested there as nginx-unit already includes a FastCGI-based PHP solution.

Images for testing have been built at ghcr.io/ananace/docker-nextcloud - only x86_64 and aarch64 as that's what's available in the upstream unit image.

[ananace]

Pushed another version of this to do some more testing myself, also pushed a version as ananace/nextcloud-unit:27 - only amd64/aarch64 as that's what's available for the upstream unit image.

[ananace]

Continued work on things, it should now mostly match cache headers for nginx/apache as well. I wasn't able to get the v argument handling working - will be digging more into that later.

It's supposed to support setting cache control using an inline template like this, but any attempts to include inline templates like they describe cause unit to fail to load the configuration.

"response_headers": {
  "Cache-Control": "public, max-age=15778463, `${ arg_v ? 'immutable' : '' }`"
}

[J0WI]

generate-stackbrew-library.sh needs an update too to include it in the library file. Once this is done, a test similar to nextcloud-apache-run can be added.

[tianon]

The main thing that makes me nervous here is the reimplementation of the unit entrypoint script inside the nextcloud entrypoint script -- what I'd suggest is copying /usr/local/bin/docker-entrypoint.sh inside the Dockerfile before overwriting it to something like /usr/local/bin/unit-entrypoint.sh which can be invoked directly instead so it can remain the source-of-truth for the fiddly bits of initializing unit instead.

I started fiddling with how I might implement this in the WordPress image, and I came up with something like this:

RUN set -eux; \
	sed -e 's/docker-entrypoint/unit-entrypoint/g' /usr/local/bin/docker-entrypoint.sh > /usr/local/bin/unit-entrypoint.sh; \
	grep -F '/unit-entrypoint.d/' /usr/local/bin/unit-entrypoint.sh; \
	chmod +x /usr/local/bin/unit-entrypoint.sh
COPY wordpress-unit.json /unit-entrypoint.d/wordpress.json

This allows me to invoke unit-entrypoint.sh inside the new entrypoint to make sure Unit is initialized before we exec it.

I also don't know whether the --control bit from https://github.com/nginx/unit/blob/fb33ec86a3b6ca6a844dfa6980bb9e083094abec/pkg/docker/Dockerfile.php8.2#L89 is strictly necessary or whether that's the default value, but that's also something to consider.

[ananace]

@tianon When I did the first version of this, it wasn't at all possible to use the original unit entrypoint script due to how it was set up, but I should be able to retool to let it do the configuration through there now.

The control argument is only necessary if you want to keep exposing the control socket, to be able to dynamically reconfigure unit while it's running, something which nextcloud lacks any functionality for.

[tianon]

Ah, I see -- in case you're curious, I finished up my WordPress PoC and pushed it to docker-library/wordpress#875 😅

[ananace]

Retooled the nginx-unit image to use the upstream entrypoint, not sure about any generate-stackbrew-library.sh change though. I tried running it locally on my test setup and the generated output looked correct.
Though I've only been pushing the changes to the configuration and scripts, not the generated files, to keep the PR manageable - and it's likely that those are required for it to generate the correct library file.

[ananace]

Rebased the branch, added in an IP forward config block, and built new image tags for 27, 28, and 29 for testing.

[J0WI]

Thanks for keeping this up to date. I just haven't merged it yet because I'm also following the progress in docker-library/wordpress#875.

[ananace]

Pushed new 29 and 30 images to ghcr.io/ananace/docker-nextcloud - since the dockerhub rate limit is really annoying me at this point.