optimize-docker-build-cache
À propos
Cette compétence Claude optimise les builds Docker en mettant en œuvre la mise en cache des couches, les builds multi-étapes et les fonctionnalités de BuildKit pour réduire considérablement les temps de build. Elle est conçue pour les projets R, Node.js et Python où les installations répétées de dépendances ou les tailles d'image importantes constituent un goulot d'étranglement. Utilisez-la lorsque des rebuilds lents ou des délais dans les pipelines CI/CD sont causés par une structure Dockerfile inefficace.
Installation rapide
Claude Code
Recommandénpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/optimize-docker-build-cacheCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Optimize Docker Build Cache
Cut build times via layer cache + opt.
Use When
- Builds slow → repeated pkg installs
- Rebuilds reinstall all deps on code change
- Images too big
- CI/CD bottleneck
In
- Required: Existing Dockerfile to optimize
- Optional: Target build time
- Optional: Target image size reduction
Do
Step 1: Order layers by change freq
Least-changing first.
# 1. Base image (rarely changes)
FROM rocker/r-ver:4.5.0
# 2. System dependencies (change occasionally)
RUN apt-get update && apt-get install -y \
libcurl4-openssl-dev \
libssl-dev \
&& rm -rf /var/lib/apt/lists/*
# 3. Dependency files only (change when deps change)
COPY renv.lock renv.lock
COPY renv/activate.R renv/activate.R
RUN R -e "renv::restore()"
# 4. Source code (changes frequently)
COPY . .
Key: Docker caches each layer. Layer changes → all subsequent rebuild. Deps install BEFORE source copy.
→ Layers ordered least-changing → most-changing, lockfiles before full source.
If err: still reinstalls on code change → verify COPY . . AFTER RUN deps install, not before.
Step 2: Separate deps from code
Bad (rebuild pkgs every code change):
COPY . .
RUN R -e "renv::restore()"
Good (rebuild only on lockfile change):
COPY renv.lock renv.lock
RUN R -e "renv::restore()"
COPY . .
Same for Node.js:
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
→ Lockfile (renv.lock, package-lock.json, requirements.txt) copy + install in separate layer before full COPY . ..
If err: lockfile copy fails → verify file exists in build context, not excluded by .dockerignore.
Step 3: Multi-stage builds
Split build vs runtime.
# Build stage - includes dev tools
FROM rocker/r-ver:4.5.0 AS builder
RUN apt-get update && apt-get install -y \
libcurl4-openssl-dev libssl-dev build-essential
COPY renv.lock .
RUN R -e "install.packages('renv'); renv::restore()"
# Runtime stage - minimal image
FROM rocker/r-ver:4.5.0
RUN apt-get update && apt-get install -y \
libcurl4 libssl3 \
&& rm -rf /var/lib/apt/lists/*
COPY --from=builder /usr/local/lib/R/site-library /usr/local/lib/R/site-library
COPY . /app
WORKDIR /app
CMD ["Rscript", "main.R"]
→ Builder stage (dev tools) + runtime (prod only). Final image much smaller than single-stage.
If err: COPY --from=builder can't find libs → verify install paths match. Debug w/ docker build --target builder ..
Step 4: Combine RUN commands
Each RUN = layer. Combine related.
Bad (3 layers, apt cache persists):
RUN apt-get update
RUN apt-get install -y curl git
RUN rm -rf /var/lib/apt/lists/*
Good (1 layer, clean cache):
RUN apt-get update && apt-get install -y \
curl \
git \
&& rm -rf /var/lib/apt/lists/*
→ Related apt-get / pkg installs combined into single RUN, each ending w/ cleanup (rm -rf /var/lib/apt/lists/*).
If err: combined RUN fails midway → split temporarily to ID failing cmd, recombine after fix.
Step 5: .dockerignore
Block unnecessary files from build context.
.git
.Rproj.user
.Rhistory
.RData
renv/library
renv/cache
node_modules
docs/
*.tar.gz
.env
→ .dockerignore in root excludes .git, node_modules, renv/library, build artifacts, env files. Build context noticeably smaller.
If err: needed files missing in container → check .dockerignore for too-broad patterns. Verbose docker build output to verify what's sent.
Step 6: BuildKit
DOCKER_BUILDKIT=1 docker build -t myimage .
Or docker-compose.yml:
services:
app:
build:
context: .
dockerfile: Dockerfile
W/ COMPOSE_DOCKER_CLI_BUILD=1 + DOCKER_BUILDKIT=1 env vars.
BuildKit gives:
- Parallel stage builds
- Better cache mgmt
--mount=type=cachefor persistent pkg caches
→ BuildKit active (#1 [internal] load build definition style output). Multi-stage parallel where possible.
If err: BuildKit inactive → verify env vars exported pre-build. Old Docker → upgrade Engine 18.09+.
Step 7: Cache mounts for pkg mgrs
# R packages with persistent cache
RUN --mount=type=cache,target=/usr/local/lib/R/site-library \
R -e "install.packages('dplyr')"
# npm with persistent cache
RUN --mount=type=cache,target=/root/.npm \
npm ci
→ Subsequent builds reuse cached pkgs from mount → dramatic install time cut even when layer invalidated. Cache persists across builds.
If err: --mount=type=cache not recognized → BuildKit needed (DOCKER_BUILDKIT=1). Legacy builder doesn't support.
Check
- Code-only rebuilds significantly faster
- Deps layer cached when lockfile unchanged
-
.dockerignoreexcludes unnecessary - Image size reduced
- Multi-stage (if used) splits build/runtime
Traps
- Copy all before install: invalidates cache every code change
- No
.dockerignore: big context → every build slow - Too many layers: each
RUN/COPY/ADD= layer. Combine logically - No apt cache clean: always end w/
&& rm -rf /var/lib/apt/lists/* - Platform-specific caches: layers platform-specific. CI runners may not benefit from local
→
create-r-dockerfile— initial Dockerfilesetup-docker-compose— compose build configcontainerize-mcp-server— apply opts to MCP servers
Dépôt GitHub
Compétences associées
content-collections
MétaCette compétence propose une configuration éprouvée en production pour Content Collections, un outil axé sur TypeScript qui transforme des fichiers Markdown/MDX en collections de données typées de manière sûre avec une validation Zod. Utilisez-la lors de la création de blogs, de sites de documentation ou d'applications Vite + React riches en contenu pour garantir la sécurité de typage et la validation automatique du contenu. Elle couvre tout, de la configuration du plugin Vite et de la compilation MDX à l'optimisation des déploiements et la validation des schémas.
polymarket
MétaCette compétence permet aux développeurs de créer des applications avec la plateforme de marchés prédictifs Polymarket, incluant l'intégration d'API pour le trading et les données de marché. Elle fournit également une diffusion de données en temps réel via WebSocket pour surveiller les transactions en direct et l'activité du marché. Utilisez-la pour mettre en œuvre des stratégies de trading ou pour créer des outils traitant les mises à jour de marché en direct.
creating-opencode-plugins
MétaCette compétence aide les développeurs à créer des plugins OpenCode qui s'interconnectent avec plus de 25 types d'événements tels que les commandes, les fichiers et les opérations LSP. Elle fournit la structure du plugin, les spécifications de l'API événementielle et les modèles d'implémentation pour les modules JavaScript/TypeScript. Utilisez-la lorsque vous avez besoin d'intercepter, de surveiller ou d'étendre le cycle de vie de l'assistant IA OpenCode avec une logique personnalisée pilotée par les événements.
sglang
MétaSGLang est un framework de service LLM haute performance spécialisé dans la génération rapide et structurée pour les workflows JSON, regex et agentiques grâce à son cache de préfixe RadixAttention. Il offre une inférence nettement plus rapide, particulièrement pour les tâches avec des préfixes répétés, ce qui le rend idéal pour les sorties complexes et structurées ainsi que les conversations multi-tours. Choisissez SGLang plutôt que des alternatives comme vLLM lorsque vous avez besoin d'un décodage contraint ou que vous construisez des applications avec un partage étendu de préfixes.
