Blog
ブログ
Dockerの基礎をLocalと比べて理解する
Docker版のWordPress環境を作ろうとして、講座動画を2本見た。今までLocalしか使ってこなかったので、Localと比べながら整理しておく。
🐳 Dockerとは
WordPressを動かすのに必要なもの(PHP・Webサーバー・DB・WordPress本体)を、Macに直接入れずに「Dockerの中」にまとめて作る仕組み。
| Local | Docker | |
|---|---|---|
| 環境の置き場所 | Macの上に直接セットアップ | Macの中の「Docker」という箱の中 |
| 作り方 | アプリの画面でポチポチ | 設定ファイル+コマンド |
| 同じ環境を他の人と共有 | 各自が画面で同じ設定を選ぶしかない | 設定ファイルを渡せば全員同じになる |
| テーマの編集 | VS Codeで普通に編集 | VS Codeで普通に編集(ここは同じ) |
一番のメリットは「チームで同じ環境を作れる」こと。制作会社によっては、Dockerで環境を用意して渡してくる場合がある。
📦 覚える用語は3つ
| 用語 | 意味 | たとえ |
|---|---|---|
| イメージ | 環境の元データ。公式が配っている | 設計図 |
| コンテナ | イメージから作った、実際に動いている環境 | 設計図から建てた家 |
| Compose(compose.yaml) | 複数のコンテナをまとめて定義するファイル | 家を何軒建てるかの配置図 |
WordPressなら、コンテナは基本2つ。WordPress本体用(PHP・Webサーバー込み)と、DB用。
📝 compose.yamlは「注文書」
compose.yamlに「こういう環境にして」と書いて、コマンドを打つと、その通りに組み立てて起動する。
services:
wordpress:
image: wordpress:php8.3-apache
ports:
- "8080:80"
volumes:
- ./wordpress:/var/www/html
db:
image: mariadb:10.6
- image … 使うイメージ。ここでPHPやDBの種類・バージョンが決まる
- ports … 「Mac側:コンテナ側」。ブラウザで開くのは localhost:8080
- volumes … Macのフォルダとコンテナをつなぐ。Macで編集すると即反映される
Localで localhost:10043 のようなURLになっていたのも、同じポートの仕組み。サイトごとに番号がかぶらないように、Localが勝手に割り当てていた。
⌨️ 基本のコマンド
compose.yamlがあるフォルダで打つ。
| コマンド | やること |
|---|---|
| docker compose config | 書き方のチェック |
| docker compose up -d | 組み立てて起動(-dはバックグラウンドで動かす指定) |
| docker compose ps | 動いているコンテナの一覧 |
Localでいう「サイトを作る」「Start site」を、コマンドでやっているイメージ。
🧩 compose.yamlで決まるもの・決まらないもの
ここを勘違いしていた。compose.yamlが用意するのは「WordPressが動ける状態」まで。
| compose.yamlで決まる(環境) | 決まらない(中身) |
|---|---|
| PHPのバージョン | WordPressの初期インストール |
| Webサーバー | 日本語化・プラグイン・固定ページ |
| DBの種類とバージョン | 投稿や固定ページの中身 |
| ポート番号 | 作っているテーマのコード |
中身の方は、WP-CLI(WordPressをコマンドで操作するツール)で設定する。Localだと、Site ShellからWP-CLIを使っていたのと同じ。
🤖 AIとの組み合わせ方は2通り
| やり方 | 流れ | 特徴 |
|---|---|---|
| CLAUDE.mdに書いてAIに任せる | 指示書をAIが読む → AIがその場でコマンドを考えて打つ | 手軽。ただAIの解釈で毎回少しぶれる |
| スクリプトに書いて実行する | コマンドを並べたファイルを実行する | 毎回まったく同じ結果になる |
組み合わせるなら、CLAUDE.mdには「新しいサイトを作るときはこのスクリプトを実行する」とだけ書いておく。入口はAIに頼めて、中身はぶれない。今のnew-projectスキルも、この形になっている。
📁 データはどこに溜まるか
Localは、~/Local Sites/案件名/app/public にWordPressのファイルが溜まっていく。Finderで見えるので、イメージしやすかった。
Dockerは、compose.yamlの volumes: の書き方で置き場所が変わる。
| 書き方 | 置き場所 | Finderで見える? |
|---|---|---|
| ./wordpress:/var/www/html | compose.yamlと同じフォルダの中 | 見える |
| db_data:/var/lib/mysql(名前付きボリューム) | Dockerの中 | 見えない |
講座2はこの形だった。起動した瞬間に、compose.yamlの横に wordpress/ フォルダが自動でできていた。
案件フォルダ/
├── compose.yaml
└── wordpress/ ← WordPress本体・テーマ(見える)
Dockerの中(見えない)
├── db_data ← DBの中身
└── イメージ ← ダウンロードした設計図
講座1では、AIに作らせたらWordPress本体もDBも名前付きボリュームになっていた。Finderから見えないので、テーマを編集するには向かない。AIに任せるときは、マウント先を指定しておいた方がいい。
- 案件フォルダを消しても、名前付きボリュームのDBは残る。ゴミが溜まっていく
- 一覧は docker volume ls(DB)、docker images(イメージ)で見られる。Docker Desktopの画面にもタブがある
- イメージは1つ数百MBある。気づくと数GB単位になる
🗂 Dockerでも共有できないもの
compose.yamlをGitHubに置けば環境は共有できるし、テーマのコードもGitHubで共有できる。でもDBの中身(投稿・固定ページ)は共有できない。
ここは、ステージングを基準にする、エクスポートする、WP-CLIで作り直す、などで補う。
💡 気付き・補足メモ
- LocalもDockerも「Macの中にWordPressの環境を作る」のは同じ。違うのは、画面で作るか、設定ファイルで作るか
- Localは画面でポチポチなのでAIが操作しにくい。Dockerはコマンドで全部できるので、AIに任せやすい
- 設定ファイルで作れるということは、本番サーバーとバージョンをそろえられるということ。DBの話はMySQLとMariaDBの記事にまとめた
- Dockerは重い。講座中も管理画面の表示がかなり遅くなっていた
- VS Codeで編集できない、ターミナルで Operation not permitted が出る、というつまずきが講座中に起きていた。VS Codeを開き直したら直っていた