Add the `nginx-module-acme` module

[Ecco]

Bug Overview

Currently the nginx-module-acme module is not included in any Docker image. It'd be great if it was.

[thresheek]

Hi @Ecco!

Indeed, we need to work on it. For now, I tend to think we should include it into "regular" non-slim images. Other option is a separate image similar to otel one, but I think it's not the best way to do it.

Thoughts?

[Ecco]

Honestly, I don't really know!

I'm not quite sure why there are already separate images to begin with. After all, the point of dynamic modules is precisely to let users load them as needed and not waste RAM. So the only upside of separate images is that we would save a bit on container sizes. Given how massively bloated containers are in general, I really don't think that adding a few nginx modules to an nginx image would really matter.

Also what if a user wants module-a and module-b, but not module-c? Should we build an image for every single combination?

If I were to make a (not very well informed) decision, I would simply build a single one-size-fits-all image with all modules. And if someone is unhappy with the container size, they can build their own image (which is not that hard if you use Debian packages).

In the meantime, here's my own Dockerfile that's usable today:

FROM nginx:1.29.1


RUN echo "deb [signed-by=/etc/apt/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ bookworm nginx" > /etc/apt/sources.list.d/nginx.list &&\
    apt-get update && \
    apt-get install -y --no-install-recommends nginx-module-acme && \
    rm -rf /var/lib/apt/lists/*

[khanhicetea]

Hi @Ecco!

Indeed, we need to work on it. For now, I tend to think we should include it into "regular" non-slim images. Other option is a separate image similar to otel one, but I think it's not the best way to do it.

Thoughts?

Agree with @Ecco , if you plan to make a separated image, better make it as a full-features image (dynamic modules) and let developer choose to use and load it :)

[thresheek]

So I take a look at implementing the suggested by including the nginx-module-acme to a "main" image. It all works fine for the architectures that we already build for on nginx.org (amd64, aarch64), but things become a bit complicated for other arches.

As you might know, nginx-module-acme is written in Rust, which means we need to install the Rust toolchain so we could rebuild the source packages.

For Alpine, we could use the officially provided Rust toolchain since the version shipped in Alpine 3.22 is new enough and we can get away with it for the time being (we do use Rustup-provided toolchain for nginx.org builds, though, for various reasons).

For Debian, though, we have no other choice but to use Rustup-provided toolchain, and I'm not sure it's available for all the architectures we build Debian-based nginx images for.

Looking at https://hub.docker.com/_/rust I can see that Rustup is used for at least:

• amd64, arm32v7, arm64v8, i386, ppc64le, riscv64, s390x

Compared to the nginx Debian-based image:

• amd64, arm32v5, arm32v7, arm64v8, i386, mips64le, ppc64le, s390x

Seems like we don't have: arm32v5 and mips64le (and they're also not tier1/tier2 targets on https://doc.rust-lang.org/rustc/platform-support.html.

[thresheek]

WIP branch is at https://github.com/thresheek/docker-nginx/tree/acme for now.

[thresheek]

Another option is to migrate to trixie and then we can also use the Rust toolchain from Debian repos.

EDIT: except for mips64, it seems:

[yosifkit]

except for mips64, it seems

Yeah, unfortunately Debian Trixie dropped it completely. So, with Trixie we get to add riscv64, but lose mips64le.

From trixie, the architectures mipsel and mips64el are no longer supported by Debian. Users of these architectures are advised to switch to different hardware.

-https://www.debian.org/releases/trixie/release-notes/issues.en.html#mips-architectures-removed

[Ecco]

Another option is to migrate to trixie and then we can also use the Rust toolchain from Debian repos.

That would definitely be my preference, at least for Debian-based images. I mean, you'll want to use an up-to-date base image anyway, and as a bonus it removes the problem of the Rust toolchain altogether.

[thresheek]

Yeah, I think that's a proper way to go. I've updated the mainline image to trixie (to be propagated to the library), and stable is next - we hope to get a stable release soon-ish (next week or so), will update to trixie as well.

[nginx-discourse-bot]

This issue has been mentioned on NGINX Community Forum. There might be relevant details there:

https://community.nginx.org/t/nginx-acme-module-hasnt-arrived-in-docker-image-yet/7483/2

[ben221199]

Honestly, I don't really know!

I'm not quite sure why there are already separate images to begin with. After all, the point of dynamic modules is precisely to let users load them as needed and not waste RAM. So the only upside of separate images is that we would save a bit on container sizes. Given how massively bloated containers are in general, I really don't think that adding a few nginx modules to an nginx image would really matter.

Also what if a user wants module-a and module-b, but not module-c? Should we build an image for every single combination?

If I were to make a (not very well informed) decision, I would simply build a single one-size-fits-all image with all modules. And if someone is unhappy with the container size, they can build their own image (which is not that hard if you use Debian packages).

In the meantime, here's my own Dockerfile that's usable today:

FROM nginx:1.29.1

RUN echo "deb [signed-by=/etc/apt/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ bookworm nginx" > /etc/apt/sources.list.d/nginx.list &&
apt-get update &&
apt-get install -y --no-install-recommends nginx-module-acme &&
rm -rf /var/lib/apt/lists/*

And for Alpine:

FROM nginx:1.29.1

RUN apk add nginx-module-acme --repository=https://nginx.org/packages/mainline/alpine/v3.22/main && \
	rm -rf /var/cache/apk/*