Docker
Docker について
🐳 Dockerとは?
Docker は 「アプリケーションを動かす環境をまるごとパッケージ化し、どこでも同じように動かせる仕組み」 を提供するプラットフォームです。
通常アプリを動かすには以下が必要です:
- OS(Windows / Linux / macOS)
- ミドルウェア(例:Webサーバー、DBサーバー)
- ライブラリや依存関係
- アプリケーションコード
これらを手動でセットアップすると
「環境が違うから動かない」「開発環境では動くのに本番でエラー」
といった問題が起きやすいです。
Dockerを使うと、これらを コンテナ(軽量な仮想環境) にまとめて配布・実行できます。
💡 仮想マシンとの違い
従来は VirtualBox や VMware などで「仮想マシン(VM)」を使って環境を分離していました。
ただし、VM は OSごと丸ごと起動するため 重い・起動が遅い という欠点があります。
Docker の コンテナ はホストOSのカーネルを共有し、必要な部分だけ分離する仕組みなので:
- 起動が速い(数秒)
- 軽い(数MB〜数百MB)
- 一台のマシンに大量に立てられる
というメリットがあります。
📦 Dockerの基本要素
-
イメージ(Image)
- アプリとその環境をまとめた設計図。
- 例:
python:3.11
イメージ → Python 3.11 が入った環境。
-
コンテナ(Container)
- イメージを実際に動かしたインスタンス。
- 例:
docker run python:3.11
→ Python環境を即利用可能。
-
Dockerfile
- イメージを作るためのレシピファイル。
- 例:Node.jsアプリを動かすための設定を書く。
-
Docker Hub
- 公式・非公式イメージが公開されている共有サービス(アプリの「App Store」のようなもの)。
🚀 使うと何が便利か?
-
開発環境の統一
→ 「このコマンドを打てば誰でも同じ環境がすぐ動く」 -
デプロイが楽
→ 本番サーバーに同じコンテナを持っていけば動く -
スケーリングしやすい
→ Kubernetes などと組み合わせて大量のコンテナを自動管理できる -
軽量で高速
→ VM よりも効率的
🔧 簡単な例
例えば「Hello World」を表示するコンテナを動かす場合:
docker run hello-world
これだけで、Docker Hub から hello-world
イメージをダウンロードし、実行してくれます。
また、Python の開発環境を一瞬で作りたいなら:
docker run -it python:3.11 bash
これでコンテナ内に入ってすぐ Python 3.11 が使えます。
👉 まとめると、Docker は 「環境の違いによるトラブルをなくし、開発から本番まで同じ形でアプリを動かせる」 便利な仕組みです。
docker コマンドについて
docker compose build
docker compose up -d
この2つのコマンドは、Docker Compose(複数コンテナをまとめて管理するツール) を使ってアプリケーションを構築・起動しようとしています。
それぞれの役割を順に解説します👇
🧩 前提:Docker Composeとは?
Docker Compose は
「複数のコンテナで構成されるアプリ(例:Webサーバー+DB+キャッシュ)を、1つの設定ファイルでまとめて管理する仕組み」
です。
通常、複数のコンテナを個別に docker run
するのは面倒ですが、
docker-compose.yml
という設定ファイルにサービス構成を記述すれば、
1コマンドでビルド・起動・停止 ができます。
docker compose build
🧱 1️⃣ このコマンドは:
Composeファイル(docker-compose.yml)に定義された各サービスのDockerイメージをビルド します。
つまり、Dockerfile
に基づいてアプリケーション環境を構築しています。
🔍 具体的な動作
-
docker-compose.yml
に記載された各サービス(例:web、db、redisなど)を確認 -
build:
で指定されたディレクトリやDockerfile
をもとにイメージを作成 - 必要な依存関係をダウンロード(例:Pythonパッケージ、Node.jsモジュールなど)
- イメージが作成され、ローカルに保存される
🧠 つまり、「アプリを動かす準備(設計図から環境を作る)」をする段階です。
docker compose up -d
🚀 2️⃣ このコマンドは:
定義されたコンテナを実際に起動する コマンドです。
-d
は「デタッチドモード(バックグラウンド実行)」を意味します。
つまり、コンソールを占有せずに裏でコンテナを動かします。
🔍 具体的な動作
- 必要なイメージが存在しない場合、自動的に
build
またはpull
する -
docker-compose.yml
に定義されたネットワークやボリュームを作成 - 各サービス(例:
web
、db
)のコンテナを起動 - ログは
docker compose logs
で確認可能
🧠 つまり、「アプリを実際に起動する」段階です。
docker-compose.yml
📄 例:よくある version: "3"
services:
web:
build: .
ports:
- "8000:8000"
depends_on:
- db
db:
image: postgres:15
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
この設定で実行すると:
docker compose build # webサービスのイメージをDockerfileからビルド
docker compose up -d # webとdbコンテナをバックグラウンドで起動
結果として、PostgreSQL と Web アプリが連携して動作する環境が一発で立ち上がります。
✅ まとめ
コマンド | 役割 | 補足 |
---|---|---|
docker compose build |
イメージをビルド(環境構築) |
Dockerfile に基づいて環境を準備 |
docker compose up -d |
コンテナを起動(実行開始) |
-d でバックグラウンド起動 |
docker-compose.yml について
version: "3.8"
services:
db:
container_name: postgres
image: postgres:13.6-bullseye
environment:
POSTGRES_PASSWORD: password
POSTGRES_INITDB_ARGS: "--encoding=UTF-8 --locale=C"
TZ: Asia/Tokyo
ports:
- "5432:5432"
volumes:
- db-data:/var/lib/postgresql/data
app:
container_name: app
build:
dockerfile: docker-php/app.Dockerfile
ports:
- "8080:80"
volumes:
- .:/var/www/html
working_dir: /app
depends_on:
- db
volumes:
db-data:
この docker-compose.yml
の内容は 「PHPアプリケーション」と「PostgreSQLデータベース」 を連携させて動かす構成になっています。
それぞれのコンテナがどのような役割を果たすか、順に解説します👇
🧱 全体構成の概要
┌────────────┐ ┌──────────────┐
│ app(php) │◄────►│ db(postgres) │
└────────────┘ └──────────────┘
▲
│
(localhost:8080)
- dbサービス:PostgreSQL 13.6 のデータベースコンテナ
- appサービス:PHP(おそらくWebサーバー付き)アプリケーションのコンテナ
- volumes:DBデータを永続化するためのストレージ領域
db
サービス(PostgreSQL)
🐘 db:
container_name: postgres
image: postgres:13.6-bullseye
environment:
POSTGRES_PASSWORD: password
POSTGRES_INITDB_ARGS: "--encoding=UTF-8 --locale=C"
TZ: Asia/Tokyo
ports:
- "5432:5432"
volumes:
- db-data:/var/lib/postgresql/data
🔍 役割と挙動
-
postgres:13.6-bullseye
イメージを使って PostgreSQL を起動します。 - DBユーザー
postgres
のパスワードをpassword
に設定。 - 文字コードを UTF-8、ロケールを C に設定。
- タイムゾーンを日本時間(Asia/Tokyo)に。
-
5432:5432
でホストマシンとポートをバインド(外部からも接続可能)。 -
db-data
ボリュームにデータを保存し、コンテナ削除後もDB内容が保持されます。
🧠 要するに:
PostgreSQLを動かすためのデータベースサーバーを構築しています。
データはローカルの永続ボリュームに保存されます。
app
サービス(PHPアプリ)
🧩 app:
container_name: app
build:
dockerfile: docker-php/app.Dockerfile
ports:
- "8080:80"
volumes:
- .:/var/www/html
working_dir: /app
depends_on:
- db
🔍 役割と挙動
-
docker-php/app.Dockerfile
という独自Dockerfileからビルドします。
(PHPのバージョンや拡張モジュールのセットアップなどがここに書かれているはずです) -
8080:80
でホストのポート8080→コンテナ内の80番ポート(HTTP)をマッピング。
→ ブラウザでhttp://localhost:8080
にアクセスすればアプリが見えるはず。 -
.:/var/www/html
により、ローカルのソースコードをコンテナに同期。
→ コードを編集すれば即反映されます(開発向け構成)。 -
working_dir: /app
はコンテナ内での作業ディレクトリを/app
に指定。 -
depends_on: db
により、起動時に「db」コンテナが先に立ち上がるようになります。
🧠 要するに:
PHPアプリを動かすWebサーバー(+アプリロジック)を提供するコンテナです。
この中からdb
コンテナの PostgreSQL に接続してデータを扱います。
volumes
セクション
🗃️ volumes:
db-data:
これは 永続ボリュームの定義 です。
Docker内部で /var/lib/docker/volumes/db-data/_data
のようなパスにデータが保存され、
PostgreSQL のデータベースがコンテナ削除後も残るようになります。
⚙️ まとめ:2行のコマンドがやっていること
コマンド | 処理内容 |
---|---|
docker compose build |
app サービスを docker-php/app.Dockerfile からビルドして、PHP実行環境のイメージを作る。db は既存の postgres:13.6-bullseye イメージを使うためビルドしない。 |
docker compose up -d |
db → app の順にコンテナを起動し、Webサーバー+DB環境をバックグラウンドで立ち上げる。 |
✅ 起動後の確認ポイント
# コンテナの稼働状況
docker compose ps
# ログの確認(例:app)
docker compose logs app
# ブラウザアクセス
http://localhost:8080
PostgreSQL は localhost:5432
、
PHPアプリは http://localhost:8080
でアクセス可能です。
Dockerfile について
FROM php:8.1.7-apache-bullseye
RUN apt-get update && \
# pdo_pgsql を使うための依存
apt-get install -y libpq-dev && \
docker-php-ext-install pdo_pgsql
WORKDIR /var/www/html
この Dockerfile
は非常にシンプルかつ目的が明確で、PHP + Apache + PostgreSQL対応 のWebアプリ実行環境を構築するためのものです。
以下で、行ごとに詳しく解説します👇
🧱 全体の目的
このDockerfileは:
PHP 8.1 + Apache のWebサーバーをベースに、PostgreSQLデータベースに接続できるよう拡張モジュール(pdo_pgsql)を組み込む。
という構成になっています。
🧩 各行の意味
FROM php:8.1.7-apache-bullseye
- ベースイメージとして PHP 8.1.7 + Apache を採用しています。
-
-bullseye
は Debian GNU/Linux の安定版ディストリビューション名(Debian 11)です。 - このイメージには Apache HTTP サーバーがすでに組み込まれており、
/var/www/html
がデフォルトのドキュメントルート。
👉 つまり:Webサーバー付きの PHP 実行環境をベースにします。
RUN apt-get update && \
# pdo_pgsql を使うための依存
apt-get install -y libpq-dev && \
docker-php-ext-install pdo_pgsql
🔍 ここがこのDockerfileの重要ポイント
-
apt-get update
→ パッケージリストを最新化(新しいソフトをインストールできるようにする) -
apt-get install -y libpq-dev
→ PostgreSQL クライアントライブラリ(C言語レベル)をインストール
→ PHP拡張のpdo_pgsql
をコンパイルするのに必要な依存ライブラリです。 -
docker-php-ext-install pdo_pgsql
→ PHP公式イメージが提供するビルトインスクリプトで、指定した拡張を有効化・コンパイルします。
→ この場合、PostgreSQLにアクセスするためのPDOドライバが組み込まれます。
👉 つまり:
PHPからPostgreSQLデータベースへ接続するための拡張を組み込んでいます。
WORKDIR /var/www/html
- コンテナ内での作業ディレクトリを設定します。
- Apacheのデフォルトのドキュメントルート
/var/www/html
に合わせて指定しているため、
ホスト側のソースコード(Composeのvolumes: .:/var/www/html
)がここにマウントされます。
👉 つまり:
docker-compose.yml
のvolumes
設定と整合しており、開発中にホストのコードを即反映できます。
🧠 まとめ
セクション | 内容 | 意味 |
---|---|---|
FROM php:8.1.7-apache-bullseye |
PHP + Apache ベース環境 | Webサーバー付きPHP環境を利用 |
apt-get install libpq-dev |
PostgreSQL接続用ライブラリ | pdo_pgsqlをビルドするための依存 |
docker-php-ext-install pdo_pgsql |
PHP拡張の有効化 | PHPでPostgreSQLを使えるようにする |
WORKDIR /var/www/html |
作業ディレクトリ設定 | ソースを置くルートディレクトリ指定 |
🚀 起動イメージ
これを docker-compose.yml
と組み合わせて動かすと:
-
docker compose build
→ この Dockerfile を元に PHP+Apache+PostgreSQL対応のイメージを作成 -
docker compose up -d
→ appコンテナ(PHPサーバー)と dbコンテナ(PostgreSQL)が起動 -
ブラウザでアクセス:
http://localhost:8080
→
/var/www/html
以下のファイル(例:index.php)が実行される
→ PHPスクリプトからpdo_pgsql
経由で DB に接続可能
起動したコンテナを終了させる方法
docker compose up -d
で起動したコンテナは バックグラウンド(デタッチドモード) で動いているため、
停止させるには明示的に「停止コマンド」を実行する必要があります。
🧯 コンテナを終了させる(停止する)方法
✅ 基本的な方法
docker compose down
これが一番よく使われる方法です。
🔍 このコマンドの動作
-
docker-compose.yml
に基づいて起動していた すべてのコンテナを停止・削除 - 関連する ネットワーク も削除
- ボリュームはデフォルトでは削除しない(DBデータなどは残る)
✅ 停止だけして削除しない場合
もし「一時的に止めたいだけで、後で再開したい」なら:
docker compose stop
これだとコンテナは停止しますが、削除はされません。
後で再開するには:
docker compose start
を実行すれば、再び同じコンテナが起動します(データも保持されたまま)。
✅ 完全にクリーンアップ(ボリューム含め削除)
もし「データも含めてすべてリセットしたい」場合は:
docker compose down -v
これで:
- コンテナ削除
- ネットワーク削除
- ボリューム削除(=DBなどのデータも消える)
になります。
✅ 状況確認コマンド
どのコンテナが動いているかは以下で確認できます:
docker compose ps
🧠 まとめ
目的 | コマンド | 内容 |
---|---|---|
コンテナを停止+削除 | docker compose down |
一般的な終了方法 |
コンテナを停止のみ | docker compose stop |
後で再開できる |
コンテナ+ボリュームも削除 | docker compose down -v |
データごと完全終了 |
停止中のコンテナを再開 | docker compose start |
再び動作を開始 |
状態確認 | docker compose ps |
実行・停止中の一覧を確認 |
🔹通常の開発中であれば:
docker compose down
で十分です。
🔹まっさらな状態からやり直したいときは:
docker compose down -v
を使うのが安全なリセット方法です。
WordPress のソース格納場所について
version: '3.1'
services:
wordpress:
image: wordpress
ports:
- 8081:80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
volumes:
- wordpress:/var/www/html
db:
image: mysql:5.7
restart: always
environment:
MYSQL_DATABASE: exampledb
MYSQL_USER: exampleuser
MYSQL_PASSWORD: examplepass
MYSQL_RANDOM_ROOT_PASSWORD: '1'
volumes:
- db:/var/lib/mysql
volumes:
wordpress:
db:
この docker-compose.yml
の構成では、WordPress の「ソースコード(PHPファイル群)」はコンテナ内部に存在しており、デフォルトではホスト(あなたのPC側)からは見えません。
以下で詳しく説明します👇
🧱 全体構成の理解
あなたの docker-compose.yml
では:
volumes:
- wordpress:/var/www/html
と指定されています。
この wordpress
は 名前付きボリューム(named volume) です。
つまり:
- WordPress コンテナ内の
/var/www/html
(=WordPress本体のソースが置かれる場所) - それが Docker の内部ボリューム(ホストの特定ディレクトリではなく、Docker管理領域内)
に保存されています。
📁 実際の場所
Docker の名前付きボリュームは、ホストマシン上ではおおむね以下のような場所に格納されています:
/var/lib/docker/volumes/wordpress/_data/
この中に WordPress の実体(index.php
, wp-content/
, wp-admin/
, wp-includes/
など)が入っています。
🔍 確認手順
1️⃣ ボリュームの確認
docker volume ls
出力例:
DRIVER VOLUME NAME
local yourproject_wordpress
local yourproject_db
(Composeプロジェクト名が自動的に接頭されることがあります。例:yourfolder_wordpress
)
2️⃣ ボリュームのマウント先を確認
docker volume inspect yourproject_wordpress
出力の中に:
"Mountpoint": "/var/lib/docker/volumes/yourproject_wordpress/_data"
という項目があります。
これが WordPress の実際のファイルの場所です。
3️⃣ 中を見てみる
(Linux や macOS なら)
sudo ls /var/lib/docker/volumes/yourproject_wordpress/_data
中にこんな構成が見えるはずです:
index.php
wp-admin/
wp-content/
wp-includes/
license.txt
readme.html
...
💡 ソースを編集したい場合の方法
現在の構成では、WordPressのソースがホスト側にマウントされていないため、
直接 /var/lib/docker/volumes/...
以下を編集するのはあまりお勧めできません(root権限が必要な上、管理が煩雑です)。
✅ 推奨される方法:ホストにマウントする
Composeファイルの volumes:
を、名前付きボリュームではなく ローカルフォルダをバインドマウント に変更します。
修正版(例)
wordpress:
image: wordpress
ports:
- 8081:80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
volumes:
- ./wordpress:/var/www/html
→ このようにすると:
- ホストのカレントディレクトリ直下の
wordpress/
フォルダに WordPressのソースが展開される - その中のファイルを編集すると、即座にコンテナ側に反映される
🚀 変更後の再構築手順
1️⃣ 既存のコンテナとボリュームを削除:
docker compose down -v
2️⃣ 修正版 docker-compose.yml
で再構築:
docker compose up -d
3️⃣ カレントディレクトリに wordpress/
フォルダができて、その中にソースが展開されます。
✅ まとめ
方法 | 内容 | 編集のしやすさ |
---|---|---|
名前付きボリューム(現状) | Docker内部(/var/lib/docker/volumes/... )に保存 |
❌ 編集困難 |
ローカルマウント(推奨) | ホストの ./wordpress フォルダにマウント |
✅ 編集しやすい(VSCodeなどで直接編集可) |