Reduce docker image size?

[gabrielwhite]

Is your feature request related to a problem? Please describe.

The docker image (at least on ARM64) seems overly large for what this system is doing - 871MB. This is by far the biggest docker image on my system.

Is there a way to make it all a bit more lean for systems with smaller storage?

Describe the solution you'd like

Reduce image size.

Describe alternatives you've considered

Buy a bigger SD card.

[apainter2]

Hi there,

Where are you getting your docker image from? The ARM64 image over at DockerHub is 311.87 Megabytes in size. If your running NPM. If you also include the suggested MariaDB-Aira docker image, which is 60.23 megabytes, then you're looking at a combined total of 372MB.

Depending on the situation you might not need the MariaDB and could look at using the internal SQLiteDB.

I run multiple instances of NPM on many platforms and VPS, on only one instance do I run both NPM and the MariaDB-Aria images together and that's because it's supplying thirty or so websites and streams, using a combination of LE and Cloudflare certs.

Alternatively, I also run NPM on a 1CPU/1GB RAM VPS instance, as the front-end for eight NGINX instances, and use the SQLiteDB option for that very reason, the host only has 1GB RAM and a single-core, and to be honest, there is no performance hit.

So, my recommendation, pull the latest image from DockerHub - https://hub.docker.com/r/jc21/nginx-proxy-manager/tags?page=1&ordering=last_updated&name=latest and it should be the size specified there.

Any concerns, please do let me know. Maybe I can help out.

Thanks!

[gabrielwhite]

Thanks for your detailed response! I think you're referring to the compressed size of the image. I have a small home NAS that I run the image on, and it's far and away the biggest image of everything (including several far more complex applications). See attached.

It doesn't prevent me from using the docker image, but I also wonder why it's so large?

[apainter2]

Ahh I see, well the shocker, my image is 904MB!

I do see your point, NGNIX by itself is tiny so, now you mention it I am also wondering why it is so big.

The top 5 biggest layers within the image are:

28	322.9 MB	RUN \	1 TARGETPLATFORM=linux/amd64 /bin/bash -o pipefail -c curl -fsSL https://deb.nodesource.com/setup_15.x \	bash - && apt-get update && apt-get install -y gcc make g++ git nodejs && apt-get clean && rm -rf /var/lib/apt/lists/* && npm install -g yarn # buildkit
12	164.1 MB	COPY /tmp/openresty /tmp/openresty # buildkit
44	126.8 MB	RUN |4 TARGETPLATFORM=linux/amd64 BUILD_VERSION=2.9.3 BUILD_COMMIT=92eec95 BUILD_DATE=2021-05-20 23:13:32 UTC /bin/bash -o pipefail -c yarn install # buildkit
7	88.3 MB	RUN |1 TARGETPLATFORM=linux/amd64 /bin/bash -o pipefail -c apt-get update && apt-get install -y --no-install-recommends apache2-utils ca-certificates curl figlet libncurses6 libpcre3 libreadline7 openssl perl python3 python3-distutils python3-venv tzdata unzip zlib1g && apt-get clean && rm -rf /var/lib/apt/lists/* # buildkit
1	69.3 MB	ADD file:639a904472920746fa3bd40ff823b7c2f30f80dd518f4328ca2a7c2ab040ccc1 in /

So thinking about it, NodeJS is the largest, yet the precompiled binary is 20-odd megabytes, rather than the 322MB here. Openresty is second, which here is 164MB, but a precompiled binary is 16-odd MB.

So an interesting viewpoint - @jc21 out of interest, why is the NPM docker image so big?

[jc21]

Some explanations:

Yes I agree it's annoyingly big for what it is. I was using an Alpine base image and the image was about 40% smaller, but recently I had to make changes to a minimal debian base image.

Apart from Alpine running musl instead of glibc, the nodejs packages in their repo were broken for ARM at some point. I would have fixed the version of nodejs to a previous working version, but Alpine repos don't keep older versions. This broke the NPM project for almost a month. I became increasingly annoyed with Alpine, I was using it for my work and issues with musl kept popping up so I made the decision to get more stability for this project as well.

In addition to that, certbot is a steaming pile of bloat by association. I've recently had to use the python-pip version as this seems like the only version they keep most up to date. This means a lot of python libraries have to be added too.

I've ran dive on the jc21/nginx-proxy-manager:2.9.3 image which analyzes the layers. Here's the results:

905MB
efficiency: 99.5039 %
wastedBytes: 8930987 bytes (8.9 MB)
userWastedPercent: 1.0685 %

honestly better than I was expecting...

A lot of this bloated stuff will be removed/replaced in v3 as it will be a go binary; no need for nodejs and associated build tools. Also replacing certbot with acme.sh will help substantially.

Here's the jc21/nginx-full:node image used as base for v2:

761MB
efficiency: 99.4904 %
wastedBytes: 8334139 bytes (8.3 MB)
userWastedPercent: 1.2044 %

vs the jc21/nginx-full:github-acme.sh image used as base for v3:

355MB
efficiency: 99.5888 %
wastedBytes: 3806260 bytes (3.8 MB)
userWastedPercent: 1.3332 %

[gabrielwhite]

Thanks for the clarification, and look forward to seeing v3!

[gabrielwhite]

For what it's worth, this docker image seems to build an image 25% of the size with v2 (unfortunately not ARM64, so I can't use it).

https://hub.docker.com/r/jlesage/nginx-proxy-manager/dockerfile

[jc21]

Yes, because it's based on alpine. See above for why I don't want to use that anymore.

[MrFloppy]

I just stumbled upon the same issue. Two things I noticed:

• /usr/local/share/.cache/yarn is around 110MB. Are these files needed? My feeling is, that you do not need yarn to be running in production. Am I wrong?
• /usr/lib/gcc is another 90.6MB. Is gcc needed in production?

Maybe these two things might help to reduce image size?

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1: