​【技術解説】WordPress構築のいま：Docker Compose（コンテナ） vs 従来のLAMP環境

従来のLAMP環境とDockerコンテナ環境のWordPressサイトの管理方法の比較 インフラ・サーバー
2026.07.12

Webサイトやブログを構築する際、最も選ばれているCMSがWordPressです。しかし、その「開発環境の作り方」は時代とともに大きく変化しています。

前回の記事でDocker Composeを使ってWordPress環境をコンテナとして構築する方法を紹介しました。

エックスサーバー無料VPSの構成と特徴
エックスサーバーの無料VPSでWordPressサイト構築
月額無料のハイスペック環境！エックスサーバーの無料VPS（Ubuntu 24.04）にDockerをインストールし、WordPressを立ち上げる全手順を詳しく紹介します。Web開発の勉強や副業の実験場として、自分だけの最強のサーバー環境を構築しましょう！
go-pro-world.net
2026.07.11

今回は、昔ながらの「LAMP（Linux/Apache/MySQL/PHP）環境をパソコンに直接（またはVPSに）構築する方法」と、現在のモダンな開発のデファクトスタンダードである「Docker Composeを使ってコンテナとして構築する方法」の違いを、メリット・デメリットを交えて分かりやすく解説します。

自分も最初は、VPSに直接ApacheやPHPを入れてLAMP環境を構築しようとしていました。しかし、PHPの拡張モジュール（php-gdやmbstring）を1つずつ入れて設定を書き換える手順の煩雑さや、失敗したときにサーバーを最初から作り直す（OSの再インストール）手間にストレスを感じていました。

そこでDocker Composeに移行したところ、コマンド一発で立ち上がり、環境を汚さず何度でもやり直せる快適さに驚き、現在は完全にDocker一筋になっています。

そもそも何が違うのか？

一言で言うと、「システムに直接インストールするか、独立した『箱（コンテナ）』を並べるか」の違いです。

従来のLAMP環境とDockerコンテナ環境の違い
  • 従来のLAMP環境：自分のパソコン（OS）の上に、Apache、MySQL、PHPを直接インストールします。すべてのソフトウェアが同じOSのスペースを共有して動きます。
  • Docker Compose環境：「Docker」という仮想化技術を使い、WordPress用、データベース（MySQL/MariaDB）用の独立したコンテナ（箱）を別々に立ち上げ、それらを「Docker Compose」という設計図（yaml ファイル）で1つにまとめて連携させます。

徹底比較！Docker Compose vs LAMP

2つの環境の違いを、開発や運用の現場で重要になる5つの視点で比較してみましょう。

比較項目Docker Compose（コンテナ）従来のLAMP環境
環境の汚染全く汚れない（コンテナを消せば元通り）汚れやすい（古い設定やファイルが残りやすい）
複数サイトの管理非常に得意（ポートやコンテナを分けるだけ）苦手（PHPのバージョン競合などが起きやすい）
チーム間での共有抜群に簡単（設定ファイルを渡すだけ）難しい（「手順書」を見ながら各自が手動構築）
学習コストやや高い（Dockerのコマンドや概念の理解が必要）低い〜中程度（昔ながらの情報がネットに豊富）
動作の軽さ軽量（OSを丸ごと立ち上げるわけではない）最も軽量（ネイティブに動くためオーバーヘッドがない）

それぞれのメリット・デメリット

Docker Compose の場合

  • メリット：
    • 一瞬でスクラップ＆ビルドができる： 実験に失敗しても、コンテナを破棄して docker compose up -d を叩けば、すぐに初期状態に戻せます。
    • 環境の「引っ越し」が超簡単： 設定ファイル（docker-compose.yml）さえあれば、WindowsでもMacでも、あるいは本番のUbuntuサーバーでも、全く同じ環境が数コマンドで再現できます。
  • デメリット：
    • Dockerそのものの概念を少し勉強する必要があります。

従来のLAMP環境 の場合

  • メリット：
    • インターネット上に以前からの膨大な情報があるため、エラーに遭遇したときに自己解決しやすいです。
  • デメリット：
    • 「AというサイトはPHP 7.4で動かしたいが、BというサイトはPHP 8.2にしたい」となった場合、1台のPC内でバージョンを切り替える設定が非常に煩雑になります。
    • 設定ファイルをひとつひとつ書いていく必要があります。

【具体例】Docker Composeだとどれくらい手軽か？

DockerComposeによるコンテナ化のメリット

従来のLAMP環境だと、Apacheの設定ファイルを書き換え、MySQLのユーザー権限を設定して、と多くの手順が必要でしたが、Docker Composeなら、以下のような 1つの設定ファイル（docker-compose.yml）を用意するだけ で環境が完成します。

services:
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root_password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_password
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_password
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./wp-content:/var/www/html/wp-content

volumes:
  db_data:

💡 公式の image: wordpress:latestに入っているもの

ベースOS（Debian Linux）

  • Debian（安定版：現在は主に bookworm など）
    • Ubuntuの親戚にあたるLinux OSです。余計なデスクトップ画面やゲームなどは一切削ぎ落とされ、コマンドだけで動く「超軽量・最小構成」のLinuxが入っています。

Webサーバー（Apache）

  • Apache HTTP Server（最新の2.4系）
    • 最初からインストールされており、コンテナが起動すると自動で立ち上がります。
    • WordPressで必須となる mod_rewrite（パーマリンク設定を綺麗にするための機能）などの設定が、最初からすべて有効化されています。

PHP本体と「厳選された」拡張モジュール

  • PHP（最新の8.2〜8.3系など、時期に応じた推奨バージョン）
    • ただPHPが入っているだけでなく、従来のLAMP構築で最も面倒だった「WordPressが公式に推奨する拡張モジュール」が全て最初からコンパイル（インストール）されています。

📦 中に入っている主なPHP拡張モジュール：

  • mysqli：データベース（MySQL）と通信するための必須モジュール。
  • gd / imagick：管理画面にアップロードした画像を自動でリサイズ（サムネイル生成）したり、最新の画像形式（WebP、AVIFなど）を処理するための画像システム。
  • exif：スマホで撮った写真の回転情報（縦横）を正しく読み取るためのモジュール。
  • zip：管理画面からプラグインやテーマを「zip形式」のままアップロードして、自動解凍・インストールするためのモジュール。
  • opcache：PHPのプログラムを一度キャッシュして、2回目以降のアクセスを爆速にするための機能。
  • mbstring：日本語などのマルチバイト文字が文字化けしないように処理するモジュール。

WordPressの本体ファイル一式

  • WordPress最新版のソースコード
    • コンテナ内の /var/www/html/ というディレクトリに、公式サイト（ja.wordpress.org）からダウンロードしてきた時と同じファイル群（wp-admin, wp-content, wp-includes, index.php など）が最初から丸ごと配置されています。

Docker専用の「仲介スクリプト」

  • docker-entrypoint.sh（起動時に走る自動スクリプト）
    • コンテナが起動した瞬間に、docker-compose.yml に書かれた環境変数（WORDPRESS_DB_HOST や WORDPRESS_DB_PASSWORD など）を読み取り、自動でデータベースへ接続するための設定ファイル（wp-config.php）をコンテナ内部で自動生成します。

💡 まとめると

従来のLAMP環境なら、何ページもあるマニュアルを見ながら「apt install php-gd して…」「Apacheの設定ファイルを書き換えて…」「WordPressをダウンロードして展開して…」と1時間以上かけてやっていた作業が、このイメージの中にすべて完璧な設定でパッケージングされている状態です。

だからこそ、私たちは image: wordpress:latest と1行書くだけで、プロがチューニングした頑強なWordPress環境を一瞬で手に入れることができます。

DockerでWordPressを動かして最初に「不便」だと感じたポイント

初めてDocker ComposeでWordPressを構築した際、wp-config.php などの設定ファイルがコンテナ内部に隠れてしまい、ホスト（VPS）側から直接見たり編集したりできないことに不便さを感じました。

最初はコンテナ内部にアクセスするコマンドを打って確認していました。

docker exec -it [コンテナ名] bash

# ファイル一覧を確認（wp-config.phpがあることを確認）
ls -la

# wp-config.php の中身を見る
cat wp-config.php

# コンテナから抜ける
exit

最終的には docker-compose.yml の volumes 設定を ./html:/var/www/html のようにディレクトリモウントに変更することで、VPS側から直接ファイルを触れるように改善しました。 このような試行錯誤を通じて、Dockerのデータ永続化（マウント）の仕組みを深く理解することができました。

コンテナで動かした場合の消費メモリは？

1台のVPS（メモリ4GB）でDockerコンテナを動かした場合、直接LAMPを立てるよりわずかにメモリ消費の初期値が高くなります。とはいえ、個人開発やブログ運営レベルであれば体感できるほどの差はなく、メリットの方が遥かに上回ります。

実際に WordPress + MySQL 8.0 + Nginx Proxy Manager の3コンテナ構成を立ち上げて docker stats でリアルタイムのメモリ消費量を計測してみました。

# コンテナの現在のメモリ消費量を表示するコマンド
docker stats --no-stream

CONTAINER ID   NAME                    CPU %     MEM USAGE / LIMIT     MEM %
61bd299837d8   wordpress               0.00%     209.4MiB / 11.65GiB   1.76%
8e3d82052d32   db                      0.20%     441.9MiB / 11.65GiB   3.71%
a9d9d01490f0   npm-app                 0.01%     108.7MiB / 11.65GiB   0.91%

結果として、3つのコンテナを合計しても約760MB程度しか消費していません。 データベース（MySQL）が約440MBと最もリソースを使っていますが、WordPress本体やプロキシサーバーは非常に軽量です。一般的な1GB〜2GBメモリの小型VPSでも十分に余裕を持って運用できるレベルであることが分かります。

まとめ：どちらを選ぶべき？

今これから環境を作るならどちらが良いかの指針です。

  • Docker Composeを選ぶべき人：
    • これからモダンな開発スキル（インフラのコード化）を身に付けたい
    • 複数のWordPressサイト（プラグインのテスト用、クライアント用など）を並行して開発したい
    • PCのローカル環境をインストール済みのソフトで汚したくない
  • 従来のLAMP環境を選ぶべき人：
    • レンタルサーバー（一般的な共有ホスティング）と全く同じ古典的な環境の構造を、まずは手動でひとつひとつ設定ファイルを触って理解したい

現在のWeb開発では、「開発環境はDocker、本番はVPSやクラウド（またはコンテナ対応ホスティング）」 という組み合わせが圧倒的に主流です。最初は少し難しく感じるかもしれませんが、一度Docker Composeの便利さを知ると、もう元のLAMP環境構築には戻れなくなるはずです。

コメント