Here is how the four choices compare:
Full node image: it is based on Debian, with many build tools and libraries. It is large. Native modules (packages with C/C++ code that must be compiled) usually just work. This makes it a good choice for a build stage.
-slim variant: Debian with most extras removed. It is much smaller. It still uses glibc (the standard C library on most Linux systems). It is a safe default image for running the app.
-alpine variant: the smallest. Alpine uses musl instead of glibc. Because of this:
- native modules or prebuilt binaries made for glibc can fail
- some of them may need to be compiled
- some behaviour is different, for example DNS resolution
Distroless images: they contain the Node runtime and very little else. There is no shell and no package manager. This shrinks the attack surface (the parts an attacker could use). But you cannot docker exec into a shell to debug. So you depend on logs and on the debug variants of the image.
- The full image is large and has build tools.
- The slim image is smaller, uses glibc and is a safe default.
- The alpine image is the smallest, but musl can break native modules.
- Distroless images have no shell or package manager, so they are harder to debug.