Building small Docker images faster

Goを選んだ理由

$DAYJOB で初めて Go サービスを構築することになりました。社内はほぼ Python 専門ですが、なぜ Go を選択したかというと、同僚の中にはゴーファー（Gopher）好きもいるし、Go は簡潔で大手企業にサポートがあり、Python よりずっと高速なので、Rust や残念ながら Nix ではなく Go を推進しやすいという判断でした。

私の担当したプロジェクトは「RCE‑as‑a‑Service」的なものです。リモートでコードを実行できる言語の中で信頼できるのが Go の実装しか無く、いつも通りに「スネークロップ」をやらずに一息つける余地があると感じました。Nix に特化した環境を作ろうと短期的に試してみたものの、結局 Docker と Docker Compose（我々が通常使っているツール）へ切り替えました。

Nix で最小限のイメージ

OCI イメージ構築には Nix が得意です。以下はサービスだけを入れた極小イメージ（

/bin/sh

{ pkgs ? import <nixpkgs> {} }:

pkgs.dockerTools.streamLayeredImage {
  name = "someimage";
  tag  = "latest";
  config.Cmd = [
    "${pkgs.hello}/bin/hello"
  ];
}

nix-build docker-test.nix

./result

./result | docker load
docker image ls

結果は 45.8 MB。ほとんどが glibc のサイズです。

Docker で同等の構築

静的 Go バイナリ（

CGO_ENABLED=0

サンプル：最小イメージ

データベースマイグレーションには goose を使っています。

docker-compose.yml

services:
  migrate:
    image: migrate:latest
    pull_policy: build
    build:
      context: https://github.com/pressly/goose.git#v3.26.0
      dockerfile: $PWD/Dockerfile.migrate
    environment:
      GOOSE_DBSTRING: postgresql://AzureDiamond:hunter2@db:5432/bobby
      GOOSE_MIGRATION_DIR: /migrations
      GOOSE_DRIVER: postgres
    depends_on:
      db:
        condition: service_started
    volumes:
      - ./migrations:/migrations

build.context

.

build.dockerfile

$PWD

docker compose

Dockerfile

FROM golang:1.25-alpine3.23 AS builder
WORKDIR /build

ARG CGO_ENABLED=0
ARG GOCACHE=/root/.cache/go-build
ARG GOMODCACHE=/root/.cache/go-mod

RUN --mount=type=cache,target=$GOCACHE \
    --mount=type=cache,target=$GOMODCACHE \
    --mount=type=bind,source=.,target=/build \
    go build -tags='no_clickhouse no_libsql no_sqlite3 no_mssql no_vertica no_mysql no_ydb' \
    -o /goose ./cmd/goose

FROM scratch
COPY --from=builder /goose /goose
CMD ["/goose", "up"]

• Alpine をビルダーに使うことで軽量化。

• CGO_ENABLED=0

  で静的リンク済みバイナリを保証。

• --mount=type=cache

  により BuildKit が Go のビルドキャッシュを再利用。
• ソースは

  --mount=type=bind,source=.,target=/build

  でコピーせずにマウントし、余計なコピーを防止。
• 最終ステージは

  scratch

  にしてイメージ内にバイナリだけ残す。

結果は 15.9 MB の単層イメージで、ビルド・ロード・起動が瞬時です。

ビルドコンテキスト

Docker は

docker build

.dockerignore

# .dockerignore
.*
Dockerfile*
docker-compose.yml

重要点：コンテキストには

.dockerignore

.git

./.jj

レイヤーを細分化

レイヤーを分割・並べ替えることでビルド時間とキャッシュ利用率が向上します。以下はもう少し複雑な例です。

FROM golang:1.25-alpine3.23 AS builder
WORKDIR /build

ARG CGO_ENABLED=0
ARG GOCACHE=/root/.cache/go-build
ARG GOMODCACHE=/root/.cache/go-mod

# 依存ツールを早めにインストール（例：orchestrion）
RUN --mount=type=cache,target=$GOCACHE \
    --mount=type=cache,target=$GOMODCACHE \
    go install github.com/DataDog/orchestrion@latest

# 依存関係のダウンロード（変更頻度が低い）
RUN --mount=type=bind,source=go.mod,target=go.mod \
    --mount=type=bind,source=go.sum,target=go.sum \
    --mount=type=cache,target=$GOCACHE \
    --mount=type=cache,target=$GOMODCACHE \
    go mod download

# バイナリのビルド
RUN --mount=type=bind,source=go.mod,target=go.mod \
    --mount=type=bind,source=go.sum,target=go.sum \
    --mount=type=cache,target=$GOCACHE \
    --mount=type=cache,target=$GOMODCACHE \
    --mount=type=bind,source=internal,target=internal \
    --mount=type=bind,source=cmd,target=cmd \
    --mount=type=bind,source=orchestrion.tool.go,target=orchestrion.tool.go \
    orchestrion go build -o server ./cmd/server

FROM alpine:3.23 AS prod
WORKDIR /app
COPY --from=builder /build/server .
ENTRYPOINT ["/app/server"]

• 変更頻度が低いツール（

  orchestrion

  等）を早期にインストール。
• 依存関係はコードより先にダウンロードしてキャッシュ化。
• 各ステップで必要なディレクトリだけをバインドマウントし、レイヤーサイズとキャッシュ効率を最適化。

結論

ENV

ARG

WORKDIR

scratch

busybox

alpine

.dockerignore

.git

bind

ADD

以上です。お役に立てれば幸いです。 Happy building!