Optimizing and Securing Docker Images

Dayton Jones
Devops Category

DOCKER Logo I still remember the first time I built a Docker image for a fairly small API I’d written in Node.js. I thought the Dockerfile was straightforward: pull a base image, copy in my source code, install dependencies, expose a port, and boom—done. Then I realized that every time I pushed changes to the repository, the build took way too long and resulted in a bulky image. Though Docker was supposed to make our CI/CD pipeline leaner, it felt like a black box constantly churning.

I set out on a quest to shrink my image size and speed up the build, convinced there had to be a better way. Over time, I discovered several “golden rules” of Docker optimization that dramatically reduced not only the image size but also the build time and deployment overhead. Here are the lessons I learned.

1. Start With the Smallest Possible Base Image

The starting point for any Docker image is your base image. It can be enticing to simply pick ubuntu:latest or node:latest and keep going, but these can be significantly larger than minimal alternatives. For instance:

  • Use Alpine-based images: Alpine Linux is often the go-to choice if you need a minimalist distribution. A typical node:alpine image can be a fraction of the size of a standard node image.
  • Slim variants: Many official Docker Hub images offer a -slim variant that omits extraneous packages, significantly reducing the footprint.

Example:

FROM node:14-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]

In this snippet, using node:14-alpine often cuts the image size by more than half compared to node:14. However, be prepared to occasionally troubleshoot Alpine-specific quirks, such as differences in package manager commands (apk vs. apt).

2. Leverage Docker’s Caching

Docker builds each layer incrementally. If one layer changes, all subsequent layers are invalidated and must be rebuilt. To speed up your builds, arrange your Dockerfile so that the most frequently changing instructions come last, preserving earlier layers.

  • Install dependencies early: Copy your package.json (or other dependency files) and perform the installation before copying the rest of the source code. This way, if your dependencies don’t change, Docker can reuse that cached layer.
  • Minimize commands that change frequently: Common file changes happen in application code, so it makes sense to copy those files in the final layers.

Bad Example:

FROM node:14-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

Good Example:

FROM node:14-alpine
WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]

3. Clean Up After Your Build

While crafting your Dockerfile, remove temporary artifacts and caches that are only needed during the build process. For instance, if you install system packages (apk or apt-get) for a particular step, uninstall or remove them afterward if they’re not needed to run your application at runtime.

Example:

FROM node:14-alpine AS builder

WORKDIR /app

RUN apk update && apk add --no-cache python3 make g++ \
 && npm install --global node-gyp \
 && apk del python3 make g++  \
 && rm -rf /var/cache/apk/*

COPY package*.json ./
RUN npm install

COPY . .

RUN npm run build

4. Use Multi-Stage Builds

Multi-stage builds are one of Docker’s most powerful optimization features. They let you create multiple “phases” within a single Dockerfile, so you only bundle what you need into the final image.

Example:

# Stage 1: Build
FROM node:14-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Final
FROM node:14-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm install --only=production

EXPOSE 3000
CMD ["node", "dist/index.js"]

5. Pin Versions and Use Specific Tags

Using latest as your base image tag can be risky. The latest tag can change overnight, potentially breaking your build or introducing new vulnerabilities. It’s best to pin to a specific version (like node:14.17.0-alpine) or at least a minor version (like node:14-alpine).

Securing Docker Images: Lessons Learned From Hard Knocks

Now that we’ve gotten the image sizes under control, let’s talk about secuity.

Security is one of those things people often treat like an afterthought—until a breach or an exploit changes their perspective. Docker images, like any packaged artifact, can contain vulnerabilities if not meticulously maintained. Below are some principles I’ve adopted (sometimes the hard way!) to ensure my Dockerized applications remain secure.

1. Use Official Images and Keep Them Updated

Stick to official, vetted images from trusted publishers whenever possible. Also:

  • Monitor Docker Hub or upstream release notes.
  • Rebuild your base image regularly.
  • Use automation in your CI/CD pipeline to detect vulnerabilities.

2. Scan Images for Vulnerabilities

Tools like Trivy, Anchore, or Clair can scan your images for known CVEs.

Example:

$ trivy image node:14-alpine

CI/CD integration:

trivy image myapp:latest --exit-code 1 --severity HIGH,CRITICAL

3. Run Containers as a Non-Root User

Example:

FROM node:14-alpine

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]

4. Limit Container Capabilities & Use Read-Only Filesystems

Example:

docker run \
  --read-only \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  -p 3000:3000 \
  myapp:latest

5. Minimize Attack Surface by Removing Unneeded Packages

Anything that’s part of your final image but not used by your application can be a potential attack surface. Remove unnecessary binaries and tools.

Bringing It All Together

Here’s an example Dockerfile combining best practices:

# Stage 1: Builder
FROM node:16-alpine AS builder

RUN apk update && apk add --no-cache python3 make g++ \
    && npm install --global node-gyp

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .
RUN npm run build

RUN apk del python3 make g++ && rm -rf /var/cache/apk/*

# Stage 2: Final minimal image
FROM node:16-alpine

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

WORKDIR /app

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm install --only=production

EXPOSE 3000
CMD ["node", "dist/index.js"]

The Takeaways

  • Size and speed: Use minimal base images, multi-stage builds, and smart Dockerfile ordering.
  • Caching: Place frequently changed files later in your Dockerfile.
  • Non-root user: Reduce privileges by default.
  • Vulnerability scanning: Use tools like Trivy and automate scanning in CI/CD.
  • Keep dependencies updated: Regularly rebuild your images.
  • Reduce attack surface: Remove unnecessary tools, packages, and files.

Over time, I’ve come to see Docker builds not as a single-step process but as a living, breathing artifact that needs continuous improvement. A well-crafted Docker image is often the unsung hero of a smooth deployment experience. It’s worth investing the time to get it right.