MCP HubMCP Hub
Volver a habilidades

create-multistage-dockerfile

pjt222
Actualizado 2 days ago
5 vistas
17
2
17
Ver en GitHub
Metaaidesign

Acerca de

Esta habilidad de Claude genera Dockerfiles optimizados de múltiples etapas que separan los entornos de construcción y ejecución para crear imágenes de producción mínimas. Es útil cuando tus imágenes son demasiado grandes, contienen herramientas de construcción innecesarias o necesitan desplegarse en entornos restringidos como la computación de borde. La habilidad cubre la separación de etapas constructor/ejecución, la copia de artefactos y objetivos como bases scratch, distroless y Alpine.

Instalación rápida

Claude Code

Recomendado
Principal
npx skills add pjt222/agent-almanac -a claude-code
Comando PluginAlternativo
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternativo
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/create-multistage-dockerfile

Copia y pega este comando en Claude Code para instalar esta habilidad

Documentación

Create Multi-Stage Dockerfile

Build multi-stage Dockerfiles that produce minimal production images by separating build tooling from runtime.

When to Use

  • Production images are too large (>500MB for compiled languages)
  • Build tools (compilers, dev headers) are included in the final image
  • Need separate images for development and production from one Dockerfile
  • Deploying to constrained environments (edge, serverless)

Inputs

  • Required: Existing Dockerfile or project to containerize
  • Required: Language and build system (npm, pip, go build, cargo, maven)
  • Optional: Target runtime base (slim, alpine, distroless, scratch)
  • Optional: Size budget for final image

Procedure

Step 1: Identify Build vs Runtime Dependencies

CategoryBuild StageRuntime Stage
Compilersgcc, g++, rustcNot needed
Package managersnpm, pip, cargoSometimes (interpreted langs)
Dev headers-dev packagesNot needed
Source codeFull source treeOnly compiled output
Test frameworksjest, pytestNot needed

Step 2: Structure the Multi-Stage Build

The core pattern: build in a fat image, copy artifacts to a slim image.

# ---- Build Stage ----
FROM <build-image> AS builder
WORKDIR /src
COPY <dependency-manifest> .
RUN <install-dependencies>
COPY . .
RUN <build-command>

# ---- Runtime Stage ----
FROM <runtime-image>
COPY --from=builder /src/<artifact> /<dest>
EXPOSE <port>
CMD [<entrypoint>]

Step 3: Apply Language-Specific Patterns

Node.js (pruned node_modules)

FROM node:22-bookworm AS builder
WORKDIR /src
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM node:22-bookworm-slim
RUN groupadd -r app && useradd -r -g app app
WORKDIR /app
COPY --from=builder /src/dist ./dist
COPY --from=builder /src/node_modules ./node_modules
COPY --from=builder /src/package.json .
USER app
EXPOSE 3000
CMD ["node", "dist/index.js"]

Python (virtualenv copy)

FROM python:3.12-bookworm AS builder
WORKDIR /src
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

FROM python:3.12-slim-bookworm
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app
COPY --from=builder /src .
RUN groupadd -r app && useradd -r -g app app
USER app
EXPOSE 8000
CMD ["python", "app.py"]

Go (static binary to scratch)

FROM golang:1.23-bookworm AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

Rust (static musl binary)

FROM rust:1.82-bookworm AS builder
RUN apt-get update && apt-get install -y musl-tools && rm -rf /var/lib/apt/lists/*
RUN rustup target add x86_64-unknown-linux-musl
WORKDIR /src
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs \
    && cargo build --release --target x86_64-unknown-linux-musl \
    && rm -rf src
COPY . .
RUN touch src/main.rs && cargo build --release --target x86_64-unknown-linux-musl

FROM scratch
COPY --from=builder /src/target/x86_64-unknown-linux-musl/release/myapp /myapp
EXPOSE 8080
ENTRYPOINT ["/myapp"]

Got: Final image contains only the runtime and compiled artifacts.

If fail: Check COPY --from=builder paths. Use docker build --target builder to debug the build stage.

Step 4: Choose Runtime Base

BaseSizeShellUse Case
scratch0 MBNoStatic Go/Rust binaries
gcr.io/distroless/static~2 MBNoStatic binaries + CA certs
gcr.io/distroless/base~20 MBNoDynamic binaries (libc)
*-slim50-150 MBYesInterpreted languages
alpine~7 MBYesWhen shell access needed

Note: Alpine uses musl libc. Some Python wheels and Node native modules may not work. Prefer -slim (glibc) for interpreted languages.

Step 5: Build Args Across Stages

ARG APP_VERSION=0.0.0

FROM golang:1.23 AS builder
ARG APP_VERSION
RUN go build -ldflags="-X main.version=${APP_VERSION}" -o /server .

FROM gcr.io/distroless/static
COPY --from=builder /server /server
ENTRYPOINT ["/server"]

Build with: docker build --build-arg APP_VERSION=1.2.3 .

Note: ARG before FROM is global. Each stage must re-declare ARG to use it.

Step 6: Compare Image Sizes

# Build both variants
docker build -t myapp:fat --target builder .
docker build -t myapp:slim .

# Compare sizes
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | grep myapp

Got: Production image is 50-90% smaller than the build stage.

Validation

  • docker build completes for all stages
  • Final image does not contain build tools (compilers, dev headers)
  • docker run works correctly from the slim image
  • Image size is significantly reduced vs single-stage
  • COPY --from=builder paths are correct
  • No source code leaks into the production image

Pitfalls

  • Missing runtime libraries: Compiled code may need shared libraries (libc, libssl). Test the slim image thoroughly.
  • Broken COPY --from paths: The artifact path must match exactly. Use docker build --target builder then docker run --rm builder ls /path to debug.
  • Alpine musl issues: Native Node.js addons and some Python packages fail on Alpine. Use -slim instead.
  • Global ARG scope: An ARG declared before FROM is available to FROM lines only. Re-declare inside each stage that needs it.
  • Forgetting CA certificates: scratch has no certificates. Copy /etc/ssl/certs/ca-certificates.crt from the builder or use distroless.

Related Skills

  • create-dockerfile - single-stage general Dockerfiles
  • create-r-dockerfile - R-specific Dockerfiles with rocker images
  • optimize-docker-build-cache - layer caching and BuildKit features
  • setup-compose-stack - compose configurations using multi-stage images

Repositorio GitHub

pjt222/agent-almanac
Ruta: i18n/caveman-lite/skills/create-multistage-dockerfile
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Habilidades relacionadas

content-collections

Meta

Esta habilidad proporciona una configuración probada en producción para Content Collections, una herramienta centrada en TypeScript que transforma archivos Markdown/MDX en colecciones de datos con tipado seguro mediante validación Zod. Úsala al construir blogs, sitios de documentación o aplicaciones Vite + React con mucho contenido para garantizar seguridad de tipos y validación automática de contenido. Abarca todo, desde la configuración del plugin de Vite y compilación MDX hasta la optimización de despliegue y validación de esquemas.

Ver habilidad

polymarket

Meta

Esta habilidad permite a los desarrolladores crear aplicaciones con la plataforma de mercados de predicción Polymarket, incluyendo la integración de API para operaciones y datos de mercado. También proporciona transmisión de datos en tiempo real a través de WebSocket para monitorear operaciones en vivo y actividad del mercado. Úsela para implementar estrategias de trading o crear herramientas que procesen actualizaciones de mercado en tiempo real.

Ver habilidad

creating-opencode-plugins

Meta

Esta habilidad ayuda a los desarrolladores a crear complementos de OpenCode que se conectan a más de 25 tipos de eventos, como comandos, archivos y operaciones LSP. Proporciona la estructura del complemento, las especificaciones de la API de eventos y los patrones de implementación para módulos en JavaScript/TypeScript. Úsala cuando necesites interceptar, monitorear o extender el ciclo de vida del asistente de IA de OpenCode con lógica personalizada basada en eventos.

Ver habilidad

sglang

Meta

SGLang es un framework de alto rendimiento para el servicio de LLM que se especializa en generación rápida y estructurada para JSON, expresiones regulares y flujos de trabajo de agentes utilizando su caché de prefijos RadixAttention. Ofrece una inferencia significativamente más rápida, especialmente para tareas con prefijos repetidos, lo que lo hace ideal para salidas complejas y estructuradas, y conversaciones multiturno. Elige SGLang sobre alternativas como vLLM cuando necesites decodificación restringida o estés construyendo aplicaciones con uso extensivo de prefijos compartidos.

Ver habilidad