Docker使い方メモ：Compose・Dockerfile・よく使うコマンド【2026年版】

Dockerを使う機会が増えてきたので、自分用のメモとして基本操作とCompose、Dockerfileの書き方を整理し直す。以前の記事はCompose V1時代の書き方や古いNode.js例が残っていたため、2026年9月時点の内容に更新した。

DockerとDocker Composeの使い分け
よく使うDocker / Composeコマンド
1. down -vは注意
compose.yamlの基本
depends_onは「準備完了」まで待たない
主要なCompose設定
Dockerfileの基本
1. npm installよりnpm ciを使う場面
本番用はマルチステージビルドを検討
.dockerignoreも忘れない
自分用の使い分け
関連記事
公式情報メモ

DockerとDocker Composeの使い分け

ざっくり分けると、dockerはイメージや個々のコンテナを操作するコマンド、docker composeは複数サービスをまとめて扱うためのコマンドとして使っている。

docker build：Dockerfileからイメージを作る
docker run：単体コンテナを起動する
docker compose up：compose.yamlに定義した複数サービスをまとめて起動する

以前よく使われていたdocker-composeではなく、現在はdocker composeを基本にする。

よく使うDocker / Composeコマンド

用途	コマンド
稼働中コンテナ確認	`docker ps`
停止中も含めて確認	`docker ps -a`
Composeサービス確認	`docker compose ps`
起動	`docker compose up -d`
ビルドして起動	`docker compose up -d --build`
停止	`docker compose stop`
停止＋コンテナ削除	`docker compose down`
ログ確認	`docker compose logs`
特定サービスのログ	`docker compose logs backend`
ログを追いかける	`docker compose logs -f backend`
サービス内でコマンド実行	`docker compose exec backend sh`
再起動	`docker compose restart backend`
イメージ一覧	`docker images`
不要リソース確認・削除	`docker system prune`

down -vは注意

docker compose down -vを使うと、Composeで作成したコンテナやネットワークだけでなく、名前付きボリュームも削除される。MySQLやPostgreSQLのデータをボリュームに保存している場合、初期化につながるので普段の停止では使わない。

# 普通に停止・削除
docker compose down

# ボリュームまで削除する場合だけ
docker compose down -v

compose.yamlの基本

現在はCompose Specificationを使うため、昔の例にあるversion: "3.8"は書かなくてよい。トップレベルのversionは互換性のために残っているだけで、現在はobsolete扱い。

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: password
      POSTGRES_DB: app
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

ファイル名もdocker-compose.ymlで動くが、現在のDocker公式例に合わせるならcompose.yamlを使う。

depends_onは「準備完了」まで待たない

ここは以前のメモで誤解していたところ。短い形式のdepends_onは依存先コンテナの起動順序は制御するが、DBが接続可能な状態になるまで待つわけではない。

services:
  web:
    depends_on:
      - db

アプリ側がDBの準備完了を待つ必要がある場合は、DBにhealthcheckを設定して、condition: service_healthyを使う。

services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: password
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

MySQL、PostgreSQL、Keycloakなど起動に時間がかかるサービスを扱うときは、この違いを意識する。

主要なCompose設定

項目	用途
`image`	既存イメージを利用
`build`	Dockerfileからビルド
`ports`	ホストとコンテナのポートをマッピング
`environment`	環境変数を直接指定
`env_file`	環境変数ファイルを読み込む
`volumes`	永続化やファイル共有
`depends_on`	サービスの依存関係を定義
`healthcheck`	コンテナが利用可能な状態か確認
`restart`	再起動ポリシー
`networks`	ネットワークを明示的に定義

Dockerfileの基本

Dockerfileはイメージを作るための手順書。よく使う命令はこのあたり。

FROM node:24-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

2026年9月時点ではNode.js 24がLTS。以前のメモで使っていたNode.js 18はすでにEOLなので、新しく作る例では24系を基準にする。

npm installよりnpm ciを使う場面

package-lock.jsonをGit管理しているアプリの再現可能なビルドでは、基本的にnpm ciを使う。依存関係ファイルを先にCOPYしてからインストールすると、アプリコードだけを変更した場合にDockerのビルドキャッシュを利用しやすい。

本番用はマルチステージビルドを検討

フロントエンドのビルドやTypeScriptのコンパイルが必要な場合、ビルド用の依存関係を本番イメージへ全部入れないためにマルチステージビルドを使う。

FROM node:24-alpine AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:24-alpine AS runner

WORKDIR /app
ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist

EXPOSE 3000
CMD ["node", "dist/index.js"]

実際のプロジェクトでは、Nodeアプリをそのまま実行するのか、Viteなどで生成した静的ファイルをNginxへ渡すのかで最終ステージは変える。

.dockerignoreも忘れない

不要なファイルをビルドコンテキストに含めないようにする。

node_modules
.git
.env
*.log
dist
coverage

特に.envや認証情報を含むファイルは、意図せずイメージへコピーしないように注意する。

自分用の使い分け

普段は以下の流れで十分。

# 状態確認
docker compose ps

# 通常起動
docker compose up -d

# Dockerfileや依存関係を変更したとき
docker compose up -d --build

# ログ確認
docker compose logs -f backend

# 普通に終了
docker compose down

DBなどの起動待ちが必要ならhealthcheckを追加する。データを消したい明確な理由がない限りdown -vは使わない。