Open6

Docker

s16as16a

Docker について

🐳 Dockerとは?

Docker は 「アプリケーションを動かす環境をまるごとパッケージ化し、どこでも同じように動かせる仕組み」 を提供するプラットフォームです。

通常アプリを動かすには以下が必要です:

  • OS(Windows / Linux / macOS)
  • ミドルウェア(例:Webサーバー、DBサーバー)
  • ライブラリや依存関係
  • アプリケーションコード

これらを手動でセットアップすると
「環境が違うから動かない」「開発環境では動くのに本番でエラー」
といった問題が起きやすいです。

Dockerを使うと、これらを コンテナ(軽量な仮想環境) にまとめて配布・実行できます。


💡 仮想マシンとの違い

従来は VirtualBox や VMware などで「仮想マシン(VM)」を使って環境を分離していました。
ただし、VM は OSごと丸ごと起動するため 重い・起動が遅い という欠点があります。

Docker の コンテナ はホストOSのカーネルを共有し、必要な部分だけ分離する仕組みなので:

  • 起動が速い(数秒)
  • 軽い(数MB〜数百MB)
  • 一台のマシンに大量に立てられる

というメリットがあります。


📦 Dockerの基本要素

  1. イメージ(Image)

    • アプリとその環境をまとめた設計図。
    • 例:python:3.11 イメージ → Python 3.11 が入った環境。
  2. コンテナ(Container)

    • イメージを実際に動かしたインスタンス。
    • 例:docker run python:3.11 → Python環境を即利用可能。
  3. Dockerfile

    • イメージを作るためのレシピファイル。
    • 例:Node.jsアプリを動かすための設定を書く。
  4. 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 は 「環境の違いによるトラブルをなくし、開発から本番まで同じ形でアプリを動かせる」 便利な仕組みです。

s16as16a

docker コマンドについて

docker compose build
docker compose up -d

この2つのコマンドは、Docker Compose(複数コンテナをまとめて管理するツール) を使ってアプリケーションを構築・起動しようとしています。
それぞれの役割を順に解説します👇


🧩 前提:Docker Composeとは?

Docker Compose は

「複数のコンテナで構成されるアプリ(例:Webサーバー+DB+キャッシュ)を、1つの設定ファイルでまとめて管理する仕組み」

です。

通常、複数のコンテナを個別に docker run するのは面倒ですが、
docker-compose.yml という設定ファイルにサービス構成を記述すれば、
1コマンドでビルド・起動・停止 ができます。


🧱 1️⃣ docker compose build

このコマンドは:

Composeファイル(docker-compose.yml)に定義された各サービスのDockerイメージをビルド します。

つまり、Dockerfile に基づいてアプリケーション環境を構築しています。


🔍 具体的な動作

  • docker-compose.yml に記載された各サービス(例:web、db、redisなど)を確認
  • build: で指定されたディレクトリや Dockerfile をもとにイメージを作成
  • 必要な依存関係をダウンロード(例:Pythonパッケージ、Node.jsモジュールなど)
  • イメージが作成され、ローカルに保存される

🧠 つまり、「アプリを動かす準備(設計図から環境を作る)」をする段階です。


🚀 2️⃣ docker compose up -d

このコマンドは:

定義されたコンテナを実際に起動する コマンドです。

-d は「デタッチドモード(バックグラウンド実行)」を意味します。
つまり、コンソールを占有せずに裏でコンテナを動かします。


🔍 具体的な動作

  1. 必要なイメージが存在しない場合、自動的に build または pull する
  2. docker-compose.yml に定義されたネットワークやボリュームを作成
  3. 各サービス(例:webdb)のコンテナを起動
  4. ログは 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でバックグラウンド起動
s16as16a

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 dbapp の順にコンテナを起動し、Webサーバー+DB環境をバックグラウンドで立ち上げる。

✅ 起動後の確認ポイント

# コンテナの稼働状況
docker compose ps

# ログの確認(例:app)
docker compose logs app

# ブラウザアクセス
http://localhost:8080

PostgreSQL は localhost:5432
PHPアプリは http://localhost:8080 でアクセス可能です。

s16as16a

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.ymlvolumes 設定と整合しており、開発中にホストのコードを即反映できます。


🧠 まとめ

セクション 内容 意味
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 と組み合わせて動かすと:

  1. docker compose build
    → この Dockerfile を元に PHP+Apache+PostgreSQL対応のイメージを作成

  2. docker compose up -d
    → appコンテナ(PHPサーバー)と dbコンテナ(PostgreSQL)が起動

  3. ブラウザでアクセス:

    http://localhost:8080
    

    /var/www/html 以下のファイル(例:index.php)が実行される
    → PHPスクリプトから pdo_pgsql 経由で DB に接続可能

s16as16a

起動したコンテナを終了させる方法

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

を使うのが安全なリセット方法です。

s16as16a

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などで直接編集可)