Convert Figma logo to code with AI

mhart logoalpine-node

Minimal Node.js Docker Images built on Alpine Linux

2,455
303
2,455
10

Top Related Projects

Official Docker Image for Node.js :whale: :turtle: :rocket:

Bitnami container images

1,403

Docker build for FFmpeg on Ubuntu / Alpine / Centos / Scratch / nvidia / vaapi

A minimal Ubuntu base image modified for Docker-friendliness

Quick Overview

mhart/alpine-node is a Docker image project that combines Alpine Linux with Node.js. It provides a minimal, lightweight Docker image for running Node.js applications, significantly reducing the overall image size compared to standard Node.js Docker images.

Pros

  • Extremely small image size, reducing storage and transfer times
  • Based on Alpine Linux, known for its security and simplicity
  • Regularly updated with the latest Node.js versions
  • Includes npm and yarn package managers

Cons

  • May lack some system libraries or tools found in larger distributions
  • Potential compatibility issues with native Node.js modules due to Alpine's use of musl libc
  • Limited shell utilities, which might affect some development workflows
  • Steeper learning curve for developers unfamiliar with Alpine Linux

Getting Started

To use the mhart/alpine-node image, follow these steps:

  1. Pull the image from Docker Hub:

    docker pull mhart/alpine-node
    
  2. Create a Dockerfile for your Node.js application:

    FROM mhart/alpine-node:14
    WORKDIR /app
    COPY package.json .
    RUN npm install
    COPY . .
    CMD ["node", "app.js"]
    
  3. Build and run your Docker image:

    docker build -t my-node-app .
    docker run -p 3000:3000 my-node-app
    

This will create a Docker container running your Node.js application based on the Alpine Node image.

Competitor Comparisons

Official Docker Image for Node.js :whale: :turtle: :rocket:

Pros of docker-node

  • Official Node.js Docker images with better long-term support and maintenance
  • Wider variety of base images (Alpine, Debian, etc.) for different use cases
  • More comprehensive documentation and examples for various Node.js versions

Cons of docker-node

  • Larger image sizes compared to alpine-node, especially for non-Alpine variants
  • May include unnecessary packages or dependencies for some use cases
  • Potentially slower build times due to more comprehensive setup

Code Comparison

alpine-node:

FROM alpine:3.14
ENV NODE_VERSION 14.17.6
RUN addgroup -g 1000 node \
    && adduser -u 1000 -G node -s /bin/sh -D node \
    && apk add --no-cache libstdc++

docker-node:

FROM buildpack-deps:bullseye

ENV NODE_VERSION 16.13.0
RUN groupadd --gid 1000 node \
    && useradd --uid 1000 --gid node --shell /bin/bash --create-home node

The alpine-node Dockerfile uses Alpine Linux as the base image and installs Node.js directly, while docker-node uses a Debian-based image with more pre-installed dependencies. This reflects the difference in image size and build approach between the two projects.

Bitnami container images

Pros of containers

  • Wider range of container images for various applications and frameworks
  • Regular updates and security patches across all images
  • Comprehensive documentation and support from Bitnami

Cons of containers

  • Larger image sizes due to additional components and dependencies
  • More complex configuration options, potentially steeper learning curve
  • May include unnecessary components for simple Node.js applications

Code comparison

alpine-node:

FROM alpine:3.14
ENV NODE_VERSION 16.13.0
RUN apk add --no-cache nodejs~=${NODE_VERSION%.*}
CMD ["node"]

containers (Node.js example):

FROM docker.io/bitnami/minideb:bullseye
ARG TARGETARCH
LABEL org.opencontainers.image.base.name="docker.io/bitnami/minideb:bullseye"
LABEL org.opencontainers.image.created="2023-06-22T14:04:59Z"
LABEL org.opencontainers.image.description="Application packaged by Bitnami"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.ref.name="18.16.1-debian-11-r3"
LABEL org.opencontainers.image.title="node"
LABEL org.opencontainers.image.vendor="Bitnami"
LABEL org.opencontainers.image.version="18.16.1"

The alpine-node Dockerfile is simpler and more focused on providing a minimal Node.js environment, while the containers Dockerfile includes additional metadata and is based on a different base image (minideb). The containers image also specifies more details about the packaged application and its licensing.

1,403

Docker build for FFmpeg on Ubuntu / Alpine / Centos / Scratch / nvidia / vaapi

Pros of ffmpeg

  • Focuses on providing a comprehensive multimedia framework for handling audio and video
  • Offers a wide range of codecs and filters for media processing
  • Regularly updated with the latest FFmpeg versions and features

Cons of ffmpeg

  • Larger image size due to inclusion of multimedia libraries and dependencies
  • May require more system resources for operation
  • Less suitable for general-purpose Node.js applications

Code comparison

ffmpeg:

FROM        ubuntu:20.04
WORKDIR     /tmp/workdir
RUN         apt-get -yqq update && \
            apt-get install -yq --no-install-recommends ca-certificates expat libgomp1 && \
            apt-get autoremove -y && \
            apt-get clean -y

alpine-node:

FROM alpine:3.14
ENV NODE_VERSION 16.6.1
RUN addgroup -g 1000 node \
    && adduser -u 1000 -G node -s /bin/sh -D node \
    && apk add --no-cache \
        libstdc++ \
    && apk add --no-cache --virtual .build-deps

Summary

While ffmpeg specializes in multimedia processing with a wide range of codecs and filters, alpine-node provides a lightweight Node.js environment based on Alpine Linux. ffmpeg is better suited for media-heavy applications, while alpine-node is more appropriate for general-purpose Node.js projects requiring a smaller footprint.

A minimal Ubuntu base image modified for Docker-friendliness

Pros of baseimage-docker

  • More comprehensive system setup with init process and system services
  • Better suited for complex applications requiring multiple processes
  • Includes useful tools and utilities for debugging and maintenance

Cons of baseimage-docker

  • Larger image size due to additional components and utilities
  • Higher resource consumption compared to minimalist Alpine-based images
  • Potentially slower build and deployment times

Code Comparison

alpine-node:

FROM alpine:3.14
RUN apk add --no-cache nodejs npm
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "app.js"]

baseimage-docker:

FROM phusion/baseimage:focal-1.0.0
RUN apt-get update && apt-get install -y nodejs npm
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["/sbin/my_init"]
RUN mkdir /etc/service/app
COPY run.sh /etc/service/app/run

Key Differences

  • alpine-node uses Alpine Linux, resulting in a smaller image size
  • baseimage-docker includes an init system and service management
  • alpine-node is simpler to set up for single-process Node.js applications
  • baseimage-docker offers more flexibility for complex, multi-process applications

Use Cases

  • Choose alpine-node for lightweight, single-process Node.js applications
  • Opt for baseimage-docker when building complex applications requiring multiple processes or system services

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Deprecated

This project is now in archive mode. Please use the official Node.js Alpine images at:

https://github.com/nodejs/docker-node#nodealpine

Minimal Node.js Docker Images

Versions v16.4.2, v14.17.3, v12.22.3, v10.24.1, v8.17.0, v6.17.1, v4.9.1, v0.12.18 and v0.10.48 – built on Alpine Linux.

All versions use the one mhart/alpine-node repository, but each version aligns with the following tags (ie, mhart/alpine-node:<tag>). The sizes are for the unpacked images as reported by Docker – compressed sizes are about 1/3 of these:

  • Full install built with npm and yarn:
    • latest, 16, 16.4, 16.4.2 – 108 MB (npm 7.19.1, yarn 1.22.10)
    • 14, 14.17, 14.17.3 – 109 MB (npm 6.14.13, yarn 1.22.10)
    • 12, 12.22, 12.22.3 – 80.4 MB (npm 6.14.13, yarn 1.22.10)
    • 10, 10.24, 10.24.1 – 73.1 MB (npm 6.14.12, yarn 1.22.10)
    • 8, 8.17, 8.17.0 – 67.8 MB (npm 6.14.11, yarn 1.22.10)
  • Full install build with npm:
    • 6, 6.17, 6.17.1 – 49 MB (npm 3.10.10)
    • 4, 4.9, 4.9.1 – 35.2 MB (npm 2.15.12)
    • 0.12, 0.12.18 – 32.4 MB (npm 2.15.12)
    • 0.10, 0.10.48 – 27.8 MB (npm 2.15.12)
  • Slim install with no npm or yarn:
    • slim, slim-16, slim-16.4, slim-16.4.2 – 78.1 MB
    • slim-14, slim-14.17, slim-14.17.3 – 73.9 MB
    • slim-12, slim-12.22, slim-12.22.3 – 46.9 MB
    • slim-10, slim-10.24, slim-10.24.1 – 41.3 MB
    • slim-8, slim-8.17, slim-8.17.0 – 37.2 MB
    • slim-6, slim-6.17, slim-6.17.1 – 32.5 MB

Examples

$ docker run --rm mhart/alpine-node:14 node --version
v14.17.3

$ docker run --rm mhart/alpine-node:12 node --version
v12.22.3

$ docker run --rm mhart/alpine-node:14 npm --version
6.14.13

$ docker run --rm mhart/alpine-node:14 yarn --version
1.22.10

$ docker run --rm mhart/alpine-node:slim-14 node --version
v14.17.3

$ docker run --rm mhart/alpine-node:slim-12 node --version
v12.22.3

Example Dockerfile for your own Node.js project

If you're doing your npm install/npm ci or yarn install from your Dockerfile, then you'll probably want to add node_modules to your .dockerignore file first, so that it doesn't get sent to the docker daemon.

For the smallest builds, use a multi-stage build – where you install your modules using the full install image, but then create your app using the slim image – this can reduce the size of your final image by ~35MB or so.

# This stage installs our modules
FROM mhart/alpine-node:12
WORKDIR /app
COPY package.json package-lock.json ./

# If you have native dependencies, you'll need extra tools
# RUN apk add --no-cache make gcc g++ python3

RUN npm ci --prod

# Then we copy over the modules from above onto a `slim` image
FROM mhart/alpine-node:slim-12

# If possible, run your container using `docker run --init`
# Otherwise, you can use `tini`:
# RUN apk add --no-cache tini
# ENTRYPOINT ["/sbin/tini", "--"]

WORKDIR /app
COPY --from=0 /app .
COPY . .
CMD ["node", "index.js"]

If you can't do multi-stage builds, then you can just do everything on a "full install" image:

FROM mhart/alpine-node:12

# If possible, run your container using `docker run --init`
# Otherwise, you can use `tini`:
# RUN apk add --no-cache tini
# ENTRYPOINT ["/sbin/tini", "--"]

WORKDIR /app
COPY . .

# If you have native dependencies, you'll need extra tools
# RUN apk add --no-cache make gcc g++ python3

RUN npm ci --prod

CMD ["node", "index.js"]

Caveats

As Alpine Linux uses musl, you may run into some issues with environments expecting glibc-like behavior – especially if you try to use binaries compiled with glibc. You should recompile these binaries to use musl (compiling on Alpine is probably the easiest way to do this).

If you get an error similar to error loading shared library ld-linux-x86-64.so.2, it may be that you have dependencies relying on libc – you can try to fix this by adding RUN apk add --no-cache libc6-compat or RUN ln -s /lib/libc.musl-x86_64.so.1 /lib/ld-linux-x86-64.so.2 to your Dockerfile.

Inspired by: