Question 84199 in Docker Question posted in
The official documentation can be found here.

What is the difference between node images for Docker and when to use which?

Hello guys sorry I am new to docker so bear with me.
I am learning to use docker for building, running and shipping some apps but still don’t know the difference between Node images (ex. latest, alpine..)
I’ve read somewhere that alpine is a small Linux distribution (in terms of size) but still don’t know the difference between all these images and especially when to use which?

Dockerfile:

enter image description here

Tags:

2

Answers


  1. 0

    Usually there is a description of the different types of images available within their docker hub page.
    For Node we have it here: https://hub.docker.com/_/node

    The section Image Variants states the following:

    • node:<version>

    This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
    Some of these tags may have names like bullseye, buster, or stretch in them. These are the suite code names for releases of Debian and indicate which release the image is based on. If your image needs to install any additional packages beyond what comes with the image, you’ll likely want to specify one of these explicitly to minimize breakage when there are new releases of Debian.
    This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

    • node:<version>-alpine

    This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
    This variant is useful when final image size being as small as possible is your primary concern. The main caveat to note is that it does use musl libc instead of glibc and friends, so software will often run into issues depending on the depth of their libc requirements/assumptions. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.
    To minimize image size, it’s uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

    • node:<version>-slim

    This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run node. Unless you are working in an environment where only the node image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

    Login or Signup to reply.
  2. 0

    All of the standard Docker Hub images have a corresponding Docker Hub page; for Node it’s https://hub.docker.com/_/node. There’s a section entitled "Image Variants" on that page that lists out the major options.

    Debian/Ubuntu/Alpine. Most Docker images are built on top of one of these base Linux distributions. Debian and Ubuntu are very similar and in fact are closely related; if you see something labeled "bullseye", "buster", or "stretch", these are the names of specific Debian major releases. Alpine has a reputation for being very small, but with that tininess comes some potential low-level C library issues. I’d recommend the Debian-based option unless you really need the tens of megabytes of space savings.

    "Slim" images. The node image has a "slim" variant. The default image mentions that it’s built on top of a buildpack-deps image, but that base image is not small (~300 MB). That image includes a full C toolchain and many development headers. Some npm install commands could need this, but you don’t want it in your final image. Prefer the "slim" option if it’s a choice.

    Version tags. The top of the Docker Hub page has a bewildering list of tags. If you look at these, each line has several names; as of this writing, node:16, node:16.14, node:16.14.0, node:lts, node:16-buster, and several other things are all actually the same image. One thing to note is that only "current" versions get any sort of updates at all; if Node 16.14.0 is the current version then no node:16.13 package will ever be rebuilt. I’d suggest picking a specific major version and using a "long-term support" version if it’s an option, but not specifying a minor or patch version.

    Combining all of those together, my default would be something like

    FROM node:16-slim # Debian-based
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search