3つのキーワードからDockerを始める
Dockerを使い始めたので、学んだことをメモします。
DockerにはWeb制作とは異なる概念や用語が数多く登場するため敷居が高いと感じました。いろいろ調べていくうちに、3つのキーワードが浮かんできました。それは、Container, Image, Volumeです。
これらの概念から考えると理解しやすかったので、この記事ではこの3つを起点に内容をまとめていきます。
Container, Image, Volume それぞれの役割
Container
Imageから作成されるアプリの実行環境。ホストOSから隔離され、任意に起動・停止・削除ができます。削除するとデータも消えるため、残すべきデータはVolumeに保存します。
Image
Containerを作成するための「設計図」。コンテナの実行に必要なファイル群(OS・ライブラリ・アプリなど)をまとめたものです。Docker Hubから公式イメージを取得することもできます。自分で作成する方法もあります(この記事では割愛します)。
Volume
コンテナを削除してもデータを残すための仕組み。コンテナ内の特定ディレクトリをMacのフォルダへ引き出すことで、投稿・テーマなど大切なデータを永続化し続けます。
3つの概念の関係を図にすると次のようになります。(WordPressを例として使います)

WordPressで学ぶ、Docker環境の構築手順
例として、「WordPressの環境」を作る場合の手順を整理します。
Step 1 : Container と Image を決める
WordPressを動かすために必要なものを分解し、各コンテナに対応するImageを選びます。
WordPress環境に必要なもの ├── Webサーバー(Apache) ├── PHP ├── WordPress本体 └── データベース(MySQL)公式の wordpress イメージはApache + PHP + WordPress本体が1つにまとまっています。そのため必要なコンテナは以下の2つになります。
wordpressコンテナ ← wordpress 公式イメージ(Docker Hub)mysqlコンテナ ← mysql 公式イメージ(Docker Hub)自作不要で、公式Imageがそのまま使えます。
Step 2 : Volume を設計する
Containerを作り直した時、WordPressのテーマファイルや投稿データが消えてしまうと困ります。永続化したいデータはVolumeとして保存することができます。
- テーマ・プラグイン・画像 →
wp-content/→ 保存したい - 投稿・ユーザーデータ →
/var/lib/mysql→ 保存したい wp-admin/など → WordPressコア → Imageに入っているので保存しなくていい
2つのVolumeが必要とわかります。
Step 3: docker-compose.yml を書く
docker-compose.yml とは、複数のコンテナの構成を1つのファイルにまとめたものです。使う Image、ポート、環境変数、Volume などを書いておけば、docker compose up で環境全体をまとめて起動できます。
Step 1、2 で決めた内容は次のとおりです。
- Container: wordpress と mysql の2つが必要
- Image: 公式イメージをDocker Hubから取得して使う
- Volume: wp-content とデータベースを永続化する
services: # 起動するコンテナ(サービス)の一覧
wordpress: # WordPress 用コンテナの定義 image: wordpress:latest # 使用する Docker イメージ(公式 WordPress、常に最新版) ports: - "8080:80" # ホストの 8080 番 → コンテナ内の 80 番(http://localhost:8080 でアクセス) environment: # WordPress コンテナ内の環境変数(DB 接続設定) WORDPRESS_DB_HOST: mysql # DB のホスト名(下の mysql サービス名と一致させる) WORDPRESS_DB_NAME: wordpress # 接続先データベース名 WORDPRESS_DB_USER: wp_user # DB 接続用ユーザー名 WORDPRESS_DB_PASSWORD: wp_pass # DB 接続用パスワード volumes: - ./wp-content:/var/www/html/wp-content # テーマ・プラグイン・アップロードをホスト側に永続化 depends_on: - mysql # mysql コンテナの起動後に wordpress を起動する
mysql: # MySQL 用コンテナの定義 image: mysql:8.0 # 使用する Docker イメージ(MySQL 8.0 系) environment: # MySQL コンテナ内の環境変数(DB 初期化設定) MYSQL_DATABASE: wordpress # 起動時に自動作成するデータベース名 MYSQL_USER: wp_user # 上記 DB 用に作成するユーザー名 MYSQL_PASSWORD: wp_pass # 上記ユーザーのパスワード MYSQL_ROOT_PASSWORD: root_pass # MySQL 管理者(root)のパスワード volumes: - ./db-data:/var/lib/mysql # DB データをホスト側に永続化(コンテナ削除後も残る)※実際の運用では、環境変数は.envから読み込むなどの秘匿化をします。
Step 4: Containerを起動する
docker-compose up -d #コンテナを作成して起動 -dオプションを付けるとターミナルのバックグラウンドで実行localhost:8080 をブラウザで開くとWordPressのセットアップ画面が表示されます。
停止や再スタートは以下のコマンドです。
docker-compose stop # 停止(コンテナは残る)docker-compose start # 作成済みで停止中のコンテナを起動docker-compose down # 停止してコンテナを削除stop と down の違いは、コンテナを残すかどうかです。設定を変えて作り直したいときは down を使います。
まとめ
Container, Image, Volumeに絞って考えて理解を深めてみました。
今回は image: wordpress:latest のように、Docker Hubにある公式Imageをそのまま使いましたが、環境やライブラリを追加したい場合は Dockerfile を作成しカスタマイズできます。
Desktopアプリの導入についても省いていますし、まだまだ知らないことがたくさんあるはずです。勉強あるのみですね!
余談: Containerはなぜ作ったり削除したりするのか?
この疑問に対する回答を上手くまとめられなかったので、AIに聞いてみました。
AIの回答Containerは起動中にファイルが書き換わったり、設定が変わったりすることがあります。しかしImageという設計図があれば、いつでも同じ状態のContainerを作り直せます。
そのため、Dockerでは「直す」より「作り直す」という考え方をとります。
従来のサーバー管理 Dockerのやり方 壊れたら修復する 削除して作り直す 環境の設定が蓄積していく 毎回クリーンな状態から始まる 復旧に時間がかかる Imageがあれば数秒で再作成 また、設定を変えたい場合も同様です。環境変数やポート番号を変更するときは、Containerを削除して新しい設定で作り直すのが一般的です。
フロントエンドのみの環境だと npm だけで賄えるケースも多いですが、バックエンドが絡むと環境の複雑さは一気に増えます。
その複雑さをクリーンに保つために、Docker では「直す」よりゼロから「作り直す」ことを前提にしているのだな、と解釈しました。