MCP HubMCP Hub
Volver a habilidades

optimize-docker-build-cache

pjt222
Actualizado 2 days ago
1 vistas
17
2
17
Ver en GitHub
Metadesign

Acerca de

Esta Skill de Claude optimiza los tiempos de construcción de Docker mediante la implementación de caché de capas, construcciones multi-etapa, características de BuildKit y patrones de copia priorizando dependencias. Está diseñada para proyectos en R, Node.js y Python que experimentan construcciones lentas debido a instalaciones repetidas de paquetes o tamaños de imagen innecesariamente grandes. Úsela cuando los cambios en el código desencadenen reinstalaciones completas de dependencias o cuando las construcciones en el pipeline de CI/CD se conviertan en un cuello de botella.

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/optimize-docker-build-cache

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

Documentación


name: optimize-docker-build-cache description: > レイヤーキャッシュ、マルチステージビルド、BuildKit機能、依存関係先行コピーパターンを使用して Dockerビルド時間を最適化する。R、Node.js、Pythonプロジェクトに適用可能。Dockerビルドが パッケージの繰り返しインストールにより遅い場合、リビルドがコード変更のたびにすべての依存関係を 再インストールする場合、イメージサイズが不必要に大きい場合、またはCI/CDパイプラインのビルドが ボトルネックになっている場合に使用する。 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: containerization complexity: intermediate language: Docker tags: docker, cache, optimization, multi-stage, buildkit locale: ja source_locale: en source_commit: 6f65f316 translator: claude-sonnet-4-6 translation_date: 2026-03-16

Dockerビルドキャッシュの最適化

効果的なレイヤーキャッシュとビルド最適化によりDockerビルド時間を短縮する。

使用タイミング

  • パッケージの繰り返しインストールによりDockerビルドが遅い場合
  • リビルドがコード変更のたびにすべての依存関係を再インストールする場合
  • イメージサイズが不必要に大きい場合
  • CI/CDパイプラインのビルドがボトルネックになっている場合

入力

  • 必須: 最適化する既存のDockerfile
  • 任意: 目標ビルド時間の改善値
  • 任意: 目標イメージサイズの削減値

手順

ステップ1: 変更頻度順にレイヤーを並べる

変更頻度の低いレイヤーを先に配置する:

# 1. ベースイメージ(ほとんど変更されない)
FROM rocker/r-ver:4.5.0

# 2. システム依存関係(たまに変更される)
RUN apt-get update && apt-get install -y \
    libcurl4-openssl-dev \
    libssl-dev \
    && rm -rf /var/lib/apt/lists/*

# 3. 依存関係ファイルのみ(依存関係変更時に変わる)
COPY renv.lock renv.lock
COPY renv/activate.R renv/activate.R
RUN R -e "renv::restore()"

# 4. ソースコード(頻繁に変更される)
COPY . .

基本原則: Dockerは各レイヤーをキャッシュする。レイヤーが変更されると、以降のすべてのレイヤーが再ビルドされる。依存関係のインストールはソースコードのコピーよりも前に行うべきである。

期待結果: Dockerfileのレイヤーが変更頻度の低い順(ベースイメージ、システム依存関係)から高い順(ソースコード)に並んでおり、依存関係ロックファイルがフルソースの前にコピーされている。

失敗時: コード変更のたびにビルドが依存関係を再インストールする場合、COPY . .が依存関係インストールのRUNコマンドの後に来ていることを確認する。

ステップ2: 依存関係インストールとコードを分離する

悪い例(コード変更のたびにパッケージをリビルド):

COPY . .
RUN R -e "renv::restore()"

良い例(ロックファイル変更時のみパッケージをリビルド):

COPY renv.lock renv.lock
RUN R -e "renv::restore()"
COPY . .

Node.jsでも同じパターン:

COPY package.json package-lock.json ./
RUN npm ci
COPY . .

期待結果: 依存関係ロックファイル(renv.lockpackage-lock.jsonrequirements.txt)がフルソースコードのCOPY . .の前に別レイヤーでコピーおよびインストールされている。

失敗時: ロックファイルのコピーに失敗する場合、ファイルがビルドコンテキストに存在し、.dockerignoreで除外されていないことを確認する。

ステップ3: マルチステージビルドの使用

ビルド依存関係とランタイムを分離する:

# ビルドステージ - 開発ツールを含む
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()"

# ランタイムステージ - 最小限のイメージ
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"]

期待結果: Dockerfileに開発ツールを含むビルドステージと本番依存関係のみを含むランタイムステージがある。最終イメージがシングルステージビルドよりも大幅に小さい。

失敗時: COPY --from=builderがライブラリを見つけられない場合、ステージ間でインストールパスが一致していることを確認する。docker build --target builder .を使用してビルドステージを独立してデバッグする。

ステップ4: RUNコマンドの結合

RUNがレイヤーを作成する。関連するコマンドを結合する:

悪い例(3レイヤー、aptキャッシュが残る):

RUN apt-get update
RUN apt-get install -y curl git
RUN rm -rf /var/lib/apt/lists/*

良い例(1レイヤー、キャッシュクリーン):

RUN apt-get update && apt-get install -y \
    curl \
    git \
    && rm -rf /var/lib/apt/lists/*

期待結果: 関連するapt-getやパッケージインストールコマンドが単一のRUN命令に結合され、それぞれがキャッシュクリーンアップ(rm -rf /var/lib/apt/lists/*)で終わっている。

失敗時: 結合したRUNコマンドが途中で失敗する場合、一時的に分割して失敗するコマンドを特定し、修正後に再結合する。

ステップ5: .dockerignoreの使用

不要なファイルがビルドコンテキストに入るのを防ぐ:

.git
.Rproj.user
.Rhistory
.RData
renv/library
renv/cache
node_modules
docs/
*.tar.gz
.env

期待結果: .gitnode_modulesrenv/library、ビルド成果物、環境ファイルを除外する.dockerignoreファイルがプロジェクトルートに存在する。ビルドコンテキストのサイズが目に見えて小さくなる。

失敗時: コンテナ内で必要なファイルが見つからない場合、.dockerignoreに広すぎるパターンがないか確認する。docker buildの詳細出力を使用して、デーモンに送信されるファイルを確認する。

ステップ6: BuildKitの有効化

DOCKER_BUILDKIT=1 docker build -t myimage .

またはdocker-compose.ymlで:

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile

COMPOSE_DOCKER_CLI_BUILD=1DOCKER_BUILDKIT=1環境変数を設定する。

BuildKitが有効にするもの:

  • ステージの並列ビルド
  • 改善されたキャッシュ管理
  • 永続的なパッケージキャッシュ用の--mount=type=cache

期待結果: BuildKitが有効な状態でビルドが実行される(#1 [internal] load build definitionスタイルの出力で示される)。マルチステージビルドが可能な場合にステージを並列実行する。

失敗時: BuildKitがアクティブでない場合、ビルドコマンドの前に環境変数がエクスポートされていることを確認する。古いDockerバージョンでは、BuildKitサポートのためDocker Engineを18.09以上にアップグレードする。

ステップ7: パッケージマネージャー用キャッシュマウントの使用

# 永続キャッシュ付きRパッケージ
RUN --mount=type=cache,target=/usr/local/lib/R/site-library \
    R -e "install.packages('dplyr')"

# 永続キャッシュ付きnpm
RUN --mount=type=cache,target=/root/.npm \
    npm ci

期待結果: 後続のビルドがマウントからキャッシュされたパッケージを再利用し、レイヤーが無効化された場合でもインストール時間が大幅に短縮される。キャッシュはビルド間で永続化される。

失敗時: --mount=type=cacheが認識されない場合、BuildKitが有効になっていることを確認する(DOCKER_BUILDKIT=1)。この構文はBuildKitが必要で、レガシービルダーではサポートされていない。

バリデーション

  • コードのみの変更後のリビルドが大幅に高速化される
  • ロックファイルが変更されていない場合、依存関係インストールレイヤーがキャッシュされる
  • .dockerignoreが不要なファイルを除外している
  • 最適化前のビルドと比較してイメージサイズが縮小される
  • マルチステージビルド(使用する場合)がビルドとランタイムの依存関係を分離する

よくある落とし穴

  • 依存関係インストール前にすべてのファイルをコピー: コード変更のたびに依存関係キャッシュが無効化される
  • .dockerignoreの忘れ: 大きなビルドコンテキストがすべてのビルドを遅くする
  • レイヤーが多すぎる: 各RUNCOPYADDがレイヤーを作成する。論理的にまとめて結合する
  • aptキャッシュのクリーンアップ忘れ: apt-getインストールの最後に常に&& rm -rf /var/lib/apt/lists/*を付ける
  • プラットフォーム固有のキャッシュ: キャッシュレイヤーはプラットフォーム固有。CIランナーはローカルキャッシュの恩恵を受けない場合がある

関連スキル

  • create-r-dockerfile - 初期Dockerfileの作成
  • setup-docker-compose - composeビルドの設定
  • containerize-mcp-server - MCPサーバービルドへの最適化の適用

Repositorio GitHub

pjt222/agent-almanac
Ruta: i18n/ja/skills/optimize-docker-build-cache
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