Why Docker? Standardizing CI/CD and Deployment for Frontend Applications

Docker container technology has become one of the most important infrastructure components today, essentially providing a standardized runtime environment for services.

From a software‑engineering perspective, Docker brings two key values: providing a consistent environment across development, testing, and production, and offering a standardized way to package service programs as images.

Standardized CI/CD – Docker enables unified build pipelines. By writing a Dockerfile that installs dependencies, runs unit tests, and builds the application, teams can achieve reproducible builds across different CI platforms (GitLab, GitHub Actions, Jenkins, Zadig, etc.).

Example of a simple unit‑test Dockerfile:

FROM node:20-slim
# 🔴 pnpm install
RUN corepack enable
COPY . /app
WORKDIR /app
RUN pnpm install
RUN pnpm test

Remember to include a .dockerignore file to avoid copying unnecessary files:

node_modules
.git
.gitignore
*.md
dist

Docker builds use layered caching; each instruction creates a new layer. If a layer’s inputs (e.g., COPY sources) haven’t changed, Docker reuses the cached layer, dramatically speeding up rebuilds.

Caching Strategies – Split the copy of dependency manifests from source code to keep the pnpm install layer cache stable:

FROM node:20-slim
RUN corepack enable
WORKDIR /app
COPY package.json pnpm-lock.yaml /app/
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install
COPY . /app
RUN pnpm test

Alternatively, mount a cache directory during RUN to persist node_modules or the pnpm store across builds.

Multi‑Stage Builds – Use separate stages for installing dependencies, testing, building, and finally deploying, reducing final image size and hiding build details:

# stage 1: install deps
FROM node:20-slim as base
RUN corepack enable
WORKDIR /app
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
COPY package.json pnpm-lock.yaml /app/
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install

# stage 2: test
FROM base as test
COPY . /app
RUN pnpm test

# stage 3: build
FROM test as build
RUN pnpm build

# stage 4: deploy (nginx)
FROM nginx:stable-alpine as deploy
COPY --from=build /app/dist/ /usr/nginx/wwwroot
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Docker images can be built with a target stage, allowing developers to run only tests ( --target test ) or the full build.

Deployment Patterns

Static assets – copy the dist folder into a lightweight busybox or nginx image.

Node.js services – treat the frontend as a regular backend service (e.g., Next.js) and deploy the built server.

Micro‑frontend – use a sidecar pattern where each sub‑app registers itself to a base shell (e.g., qiankun) and is served via Ingress.

For static deployments, a simple Dockerfile might be:

FROM busybox:latest
COPY dist /data

For an Nginx‑based static site with custom configuration:

FROM nginx:stable-alpine
COPY --from=build /app/dist/ /usr/nginx/wwwroot
# COPY nginx.conf /etc/nginx/nginx.conf (optional)
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Advanced Topics

To support “one code base, many deployments”, the article discusses using environment variables, SSR, template replacement, or SSI (Server‑Side Include) with Nginx. An example Vite configuration injects a placeholder that Nginx replaces at runtime via envsubst :

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
export default defineConfig({
  plugins: [vue()],
  experimental: {
    renderBuiltUrl(filename) {
      return "
" + filename
    }
  }
})

Dockerfile for SSI:

FROM nginx:stable-alpine
COPY dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD (cat /etc/nginx/nginx.conf | envsubst '${PUBLIC_URL}' > /etc/nginx/nginx.conf) && nginx -g 'daemon off;'

Finally, the article outlines simple gray‑release and blue‑green strategies in Kubernetes using Services or Nginx Ingress, and how micro‑frontend sidecars can be versioned and switched via a registry.

In summary, Docker provides a unified environment for frontend developers to run tests, build, and deploy consistently, while leveraging Kubernetes and modern CI/CD platforms to handle complex deployment scenarios.