章: 第3章: PHP/Laravel運用連携

「とりあえず動いた」で本番に出すと何が起きるか

開発環境で動いたDocker構成をそのまま本番に持っていくと、深刻なトラブルが起きることがあります。「イメージタグが latest のまま」「パスワードが secret」「ヘルスチェックなし」——どれか1つでも本番環境で放置すると、障害や情報漏洩につながるリスクがあります。

このチェックリストを使えば、リリース前に抜け漏れなく確認できます。

なぜ本番前チェックが重要か

本番障害の多くは「確認不足」ではなく「確認項目を決めていなかった」ことが原因です。毎回同じ観点でチェックすることで、属人的なミスを組織的に防げます。

開発環境と本番環境の設定比較

チェックポイント: イメージタグに latest を使うと、気づかないうちに破壊的変更が入ったバージョンが起動する危険があります。本番では必ず固定タグを使いましょう。

本番リリース前チェックリスト

# Docker本番チェック
# - [ ] イメージタグが固定されている
# - [ ] .envの秘密情報が安全に管理されている
# - [ ] ヘルスチェックが設定済み
# - [ ] ボリュームのバックアップ手順がある
# - [ ] ログ収集先が定義されている

このチェックリストを CI/CD パイプラインに組み込むか、リリース手順書の冒頭に貼り付けて毎回確認する習慣をつけましょう。

まとめ & 次のステップ

• 本番では latest タグを使わず、固定タグでイメージを管理する
• 秘密情報は .env に書き、シークレット管理ツールの導入を検討する
• ヘルスチェック・restart ポリシー・ログ設定を必ず確認する
• ボリュームのバックアップ手順とスケジュールを事前に確立する

これで Docker Advanced シリーズ全12回が完了です。イメージ・Compose・ネットワーク・永続化・本番運用まで、実務で必要なDockerの基礎を一通り学びました。次は「PHP+Laravel Advanced」シリーズで、アプリケーションレイヤーの設計をさらに深掘りしていきましょう。

The post 第12回: 本番運用チェックリスト（Docker版） — リリース前に必ず確認すべき10の観点 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第3章: PHP/Laravel運用連携

「環境構築で1日潰した」をなくすために

Laravelプロジェクトに新メンバーが参加するとき、環境構築だけで1日以上かかることは珍しくありません。PHPのバージョン、Composerのバージョン、MySQL設定……手順書が古くなっていることも多く、試行錯誤が続きます。

DockerでLaravel環境をCompose化することで、docker compose up -d 1コマンドで誰でも同じ環境を立ち上げられるようになります。

Laravelに必要なサービス構成を整理する

Laravelを動かすには最低限以下が必要です。

チェックポイント: 最初はnginxなしで php artisan serve を使う構成から始めましょう。シンプルな構成で動作を確認してから、本番に近い nginx+PHP-FPM 構成に移行するのがつまずきにくい順番です。

実際のCompose構成サンプル

services:
  app:
    build: .
    volumes:
      - ./:/var/www/html
    command: php artisan serve --host=0.0.0.0 --port=8000
    ports:
      - "8000:8000"
  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: laravel
      MYSQL_ROOT_PASSWORD: secret

LaravelのDockerfileには pdo_mysql のインストールと composer install の実行を含めます。.env の DB_HOST は db（サービス名）に設定します。

まとめ & 次のステップ

• まずは php artisan serve + MySQL のシンプル構成から始める
• DB_HOST=db など Laravelの .env 設定をComposeのサービス名に合わせる
• Dockerfileに composer install を含めてビルド時に依存関係を解決する
• 動作確認後、nginx+PHP-FPM+Redis の本番近似構成に段階的に移行する

次回は「本番運用チェックリスト（Docker版）」を学びます。Docker環境で本番リリースする前に確認すべき観点を整理し、事故を未然に防ぎます。

The post 第11回: DockerでLaravelを動かす基礎 — 新メンバーが即日開発参加できる環境を作る first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第3章: PHP/Laravel運用連携

「私のマシンでは動く」を卒業しよう

PHPとMySQLの開発環境をローカルに手動インストールすると、バージョンの違い・設定の差異・パスの問題など、環境固有のトラブルが絶えません。チームで開発するならなおさらです。

DockerとComposeを使えば、誰の環境でもコマンド1つで同じPHP+MySQL環境が起動します。この記事ではその最小構成を作り上げます。

PHP+MySQL環境で押さえるべきポイント

PHPとMySQLを連携させるには次の3点が重要です。

1. PDOドライバ: PHPからMySQLに接続するには pdo_mysql 拡張が必要

2. サービス名でDB接続: DB_HOST にはサービス名（mysql など）を指定する

3. 起動順の制御: MySQLが準備完了してからPHPを起動する

構成パターンの比較

チェックポイント: まずはPHP内蔵サーバで動かして動作確認し、必要に応じてnginx+PHP-FPM構成に移行するのが段階的に理解しやすい進め方です。

実際のCompose構成サンプル

services:
  php:
    build: .
    volumes:
      - ./:/app
    working_dir: /app
    command: php -S 0.0.0.0:8080 -t public
    ports:
      - "8080:8080"
  mysql:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_ROOT_PASSWORD: secret

php サービスのDockerfileには docker-php-ext-install pdo pdo_mysql を含めることを忘れずに。アプリ側の DB_HOST は mysql（サービス名）を指定します。

まとめ & 次のステップ

• Dockerfileに pdo_mysql 拡張のインストールを含める
• DB_HOST にはサービス名を指定する（localhost は不可）
• まずCLI実行で動作確認し、次にWebサーバ設定を加える段階的アプローチを取る
• ボリュームでMySQLデータを永続化する（第04回の知識を活用）

次回は「DockerでLaravelを動かす基礎」を学びます。LaravelプロジェクトをComposeで起動し、新メンバーが即日開発に参加できる環境を作ります。

The post 第10回: DockerでPHP+MySQL環境を作る — ゼロから再現性100%の開発環境を構築する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第2章: Docker Compose実践

「開発と本番で同じ compose.yml を使えばいい」は危険な考え方

開発環境には「デバッグツール」「ソースコードのバインドマウント」「パスワードの簡略化」など、本番に含めてはいけない設定が多く含まれます。同じファイルを使い回すと、デバッグ機能が本番に混入したり、ソースコードが誤った場所からロードされるリスクがあります。

Composeのファイル分割機能を使うと、共通設定は一か所に持ちつつ、環境ごとの差分だけを別ファイルで管理できます。

なぜ設定を分離するべきか

開発と本番では必要な設定が大きく異なります。

チェックポイント: compose.override.yml はデフォルトで自動読み込みされます。このファイルを開発用の差分定義として使うと、docker compose up だけで開発設定が適用され、本番では明示的に -f で指定する運用が整います。

実際のコマンドサンプル

# 開発
docker compose up -d

# 本番向け（例）
docker compose -f compose.yml -f compose.prod.yml up -d --build

compose.yml に共通設定を置き、compose.prod.yml に本番差分を書きます。開発時は up -d だけで compose.override.yml が自動適用されます。

まとめ & 次のステップ

• 開発と本番を同じ compose.yml で管理するのはリスクがある
• compose.override.yml を開発用差分ファイルとして活用する
• 本番は -f compose.yml -f compose.prod.yml で明示的にファイルを指定する
• 本番ファイルにはデバッグ設定・Bind Mount・簡易パスワードを含めない

次回は「DockerでPHP+MySQL環境を作る」を学びます。ここまでの知識を組み合わせて、PHPアプリが動く実践的な開発環境を構築します。

The post 第09回: 開発用と本番用の分離 — 同じ設定ファイルを使い回すと危険な理由 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第2章: Docker Compose実践

docker compose up したら「DB接続失敗」でアプリがクラッシュした経験はありませんか?

これはよくあるトラブルです。depends_on: db を設定していても、DBのプロセスが起動しただけで「接続を受け付けられる状態」にはなっていない、という状況で起きます。

ヘルスチェックと condition: service_healthy を使うことで、DBが本当に接続を受け付けられる状態になってからアプリを起動できるようになります。

depends_onだけでは足りない理由

depends_on はコンテナの「起動順序」を制御しますが、「サービスが準備完了かどうか」は判定しません。MySQLはプロセスが起動してから実際に接続できるまでに数秒かかります。

ヘルスチェックを定義すると、Dockerがそのサービスの「健全性」を定期的に確認します。condition: service_healthy を組み合わせると、ヘルスチェックが成功してから依存サービスを起動できます。

depends_on の condition の違い

チェックポイント: DBへの接続が必要なサービスには condition: service_healthy を使いましょう。service_started だけでは接続タイミングの問題は解決しません。

実際の設定サンプル

services:
  db:
    image: mysql:8.4
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
  app:
    depends_on:
      db:
        condition: service_healthy

interval: 10s で10秒ごとに確認し、retries: 5 で5回失敗するまで待機します。docker compose ps でヘルスチェックの状態（healthy/unhealthy/starting）を確認できます。

まとめ & 次のステップ

• depends_on だけでは「サービスが準備完了か」は判定できない
• healthcheck でサービスの準備状態を定期確認する
• condition: service_healthy で健全性が確認できてから起動順を制御する
• docker compose ps でヘルスチェック状態を確認する

次回は「開発用と本番用の分離」を学びます。同じCompose設定を開発と本番で使い回すリスクと、安全に分離する方法を整理します。

The post 第08回: ヘルスチェックと起動順制御 — 「DBが起動していない」エラーを根絶する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第2章: Docker Compose実践

パスワードをcompose.ymlにベタ書きしていませんか?

MYSQL_ROOT_PASSWORD: secret をそのまま compose.yml に書いてGitにコミットすると、リポジトリに秘密情報が残り続けます。これはセキュリティ上の深刻なリスクです。

.env ファイルと環境変数の仕組みを正しく使うことで、秘密情報をコードから分離し、環境ごとの差分を安全に管理できるようになります。

.envを使うと何が変わるか

.env ファイルに設定値を書き、compose.yml では変数参照（${VAR_NAME}）を使います。こうすることで次が実現します。

• .env を .gitignore に追加し、Gitに秘密情報を含めない
• 開発・ステージング・本番で異なる .env を差し替えるだけで切り替えできる
• compose.yml 自体はどの環境でも同じファイルを使える

.envとenv_fileの使い分け

チェックポイント: パスワードやAPIキーは environment: に直書きしない。.env に書いて .gitignore に追加し、リポジトリに含めないのが鉄則です。

実際の設定サンプル

# .env
APP_PORT=8080
MYSQL_DATABASE=blog
MYSQL_ROOT_PASSWORD=secret

# compose.yml
services:
  app:
    ports:
      - "${APP_PORT}:8080"

${APP_PORT} が .env の APP_PORT=8080 で展開されます。docker compose config を実行すると、変数展開後の最終的なYAMLを確認できます。

まとめ & 次のステップ

• パスワードなどの秘密情報は compose.yml に直書きしない
• .env ファイルに値を書き、.gitignore でGitから除外する
• .env.example を用意してチームと共有できる雛形を残す
• docker compose config で変数展開後の設定を確認する習慣をつける

次回は「ヘルスチェックと起動順制御」を学びます。DBが起動する前にアプリが接続しようとして失敗する問題を、Composeの機能で解決します。

The post 第07回: 環境変数と.env管理 — 秘密情報をyamlに書かないための正しい設計 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第2章: Docker Compose実践

毎回 docker run を3回叩くのは終わりにしよう

アプリ・DB・キャッシュを別々に docker run で起動し、毎回コマンドを打つのは非効率です。コマンドが長くなるほど間違いも増えます。

Docker Composeを使えば、複数サービスの定義を1つのYAMLファイルにまとめ、docker compose up 1コマンドで全サービスを起動できます。停止も docker compose down の1コマンドです。

Composeを使うと何が変わるか

Composeは「サービスの構成をコードで管理する」ツールです。YAMLに定義を書くことで次が実現します。

• チーム全員が同じ構成で起動できる（環境差異の排除）
• ビルド・起動・停止・ログ確認がすべて docker compose サブコマンドで完結
• サービス間の依存関係（起動順）も定義できる

よく使うComposeコマンドの比較

チェックポイント: 開発中は docker compose up -d で起動し、docker compose logs -f でログを確認する流れが基本です。down -v はボリュームも消えるので本番環境では慎重に使いましょう。

最小構成のサンプル

services:
  app:
    build: .
    ports:
      - "8080:8080"
  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: blog
      MYSQL_ROOT_PASSWORD: secret

app と db の2サービス構成です。まずこの最小構成を動かして、起動・停止・ログ確認を一通り試してみましょう。

まとめ & 次のステップ

• Composeは複数サービスを1つのYAMLで管理し、1コマンドで起動・停止できる
• まず app + db の2サービス構成から始めるのがコツ
• docker compose logs -f でトラブル時のログ確認を習慣にする
• down -v はボリュームも削除されるため意図的に使う

次回は「環境変数と.env管理」を学びます。パスワードや設定値をYAMLに直書きしない、安全な環境変数管理の方法を整理します。

The post 第06回: Docker Composeの基本 — 複数サービスを1コマンドで起動する first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第1章: Docker基礎と環境理解

PHPからMySQLに接続しようとしたら繋がらない、なぜ?

DockerでPHPとMySQLを別々のコンテナで動かし、PHPから localhost でMySQLに接続しようとすると失敗します。「同じマシンで動いているのになぜ?」——これはDockerネットワークの仕組みを知ると一瞬で解決します。

この記事では、コンテナ間通信の仕組みとサービス名による名前解決を整理します。

Dockerネットワークを理解すると設定がシンプルになる

各コンテナは独立したネットワーク空間を持っています。localhost はそのコンテナ自身を指すため、別コンテナには届きません。

Docker Composeを使うと、同じ compose.yml 内のサービスは自動的に同じネットワークに配置され、サービス名でお互いにアクセスできるようになります。DNSのように名前解決が行われます。

localhost vs サービス名 の比較

チェックポイント: DB_HOST には必ずサービス名（db など）を指定しましょう。コンテナ間通信では localhost は絶対に使えません。

実際の設定サンプル

services:
  app:
    environment:
      DB_HOST: db
  db:
    image: mysql:8.4

# app から db:3306 へ接続できる

app コンテナから db:3306 へアクセスできます。ポートは内部ポート（3306）を使い、ホストへの公開ポートとは別物です。

まとめ & 次のステップ

• コンテナ間では localhost は使えない、サービス名で接続する
• Docker Compose は同一 compose.yml 内のサービスを自動的に同じネットワークに配置する
• 接続先ポートは「内部ポート」を使う（ports: で公開したポートとは別）
• docker compose exec app ping db でコンテナ間疎通を確認できる

次回は「Docker Composeの基本」を学びます。複数サービスを1つのファイルで管理し、1コマンドで起動・停止する方法を体系的に理解します。

The post 第05回: ネットワークとサービス間通信 — コンテナはなぜ「localhost」で繋がらないのか? first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第1章: Docker基礎と環境理解

コンテナを再作成したらDBが空になった — あなたも経験しましたか?

Dockerを使い始めて最初に驚くのが「コンテナを削除したら、入力していたデータが全部消えた」という体験です。これはDockerの仕様通りの動作ですが、知らないとひどく焦ります。

ボリュームを正しく使うことで、コンテナの外にデータを永続化し、コンテナを何度作り直してもデータを保持できるようになります。

なぜデータが消えるのか、なぜボリュームで解決するのか

コンテナのファイルシステムは「コンテナ自身」に属しています。コンテナが削除されると、その中のデータも一緒に消えます。これはコンテナの「使い捨て可能性」という特性から来ています。

ボリュームはDockerが管理するホスト上の記憶領域で、コンテナのライフサイクルとは独立しています。DBデータやアップロードファイルなど「消えてはいけないデータ」はボリュームに置きます。

バインドマウントとNamed Volumeの違い

チェックポイント: DBデータには必ず Named Volume を使いましょう。Bind Mount はホストのパスに依存するため、DBデータに使うと環境差異でトラブルが起きやすくなります。

最小構成のサンプル

services:
  db:
    image: mysql:8.4
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

db_data という名前のボリュームを定義し、MySQLのデータディレクトリをそこにマウントしています。docker compose down してもこのボリュームは残り、次回 up したときにデータが復元されます。

まとめ & 次のステップ

• コンテナのデータはデフォルトでコンテナと一緒に消える
• Named Volume を使えばコンテナを削除してもデータが残る
• DBデータは Named Volume、ソースコードは Bind Mount が基本パターン
• docker volume ls で現在のボリューム一覧を確認できる

次回は「ネットワークとサービス間通信」を学びます。なぜコンテナ間で localhost が使えないのか、サービス名で解決する仕組みを理解します。

The post 第04回: ボリュームと永続化 — コンテナを消してもデータが消えない仕組み first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第1章: Docker基礎と環境理解

「ビルドしたのに動かない」はどこで起きているのか?

Dockerを使い始めた多くの人が経験するのが「ビルドは成功したのにコンテナが起動しない」「停止したはずのコンテナがまだ残っている」というトラブルです。これらの多くは、ビルド・起動・停止という3つの操作の関係が曖昧なことで起きます。

この記事では、イメージのビルドからコンテナの実行・確認までを、実際のコマンドと合わせて整理します。

ビルドと実行を繰り返す作業を効率化する

開発中はDockerfileを修正するたびにビルドして動作確認します。このサイクルが遅いと開発体験が大きく損なわれます。また、タグを適切に管理しないと「どのイメージが最新か」がわからなくなります。Dockerの基本操作を体に染み込ませることで、こうした問題を素早く解決できるようになります。

よく使うコマンドの比較

チェックポイント: --rm オプションをつけると、コンテナ停止時に自動で削除されます。使い捨て確認用のコンテナには --rm をつけておくとゴミが溜まりません。

実際のコマンドで確認する

# イメージ作成
docker build -t blog-php:dev .

# コンテナ起動
docker run --rm -it blog-php:dev

# 実行中コンテナ確認
docker ps

まず docker build でイメージを作り、docker run で起動してみましょう。docker ps で「STATUS」が Up になっていれば正常です。

まとめ & 次のステップ

• docker build でイメージ作成、docker run でコンテナ起動が基本の流れ
• タグ（name:tag）を使ってイメージを管理すると混乱が減る
• --rm オプションで使い捨てコンテナを自動削除する習慣をつける
• docker ps -a で停止済みコンテナも確認できる

次回は「ボリュームと永続化」を学びます。コンテナを削除してもデータを失わないための仕組みを理解します。

The post 第03回: イメージビルドと実行 — ビルドからコンテナ起動まで迷わないための基本操作 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.