Dockerを知る_その２

Date2026/08/22 Last Modified2026/08/22

いい加減、Dockerをやらないとなぁと思いつつも必要に迫られなかったり、やるメリットが思いつかないので野放しになっていた。
けれど一つ、「EC2のインスタンス内でもDockerで動かせばクリーンな環境になるよ」というアドバイスをもらって以来、ずっと試したかった。

ということで、次の案件をDockerベースで立ち上げるべく、疑問点を整理していきたい。まいど初歩の初歩から。

そもそもどこに配置するの？

使い慣れたxamppは、C:\xampp\htdocsの中に配置しよう、という明確な置き場所があった。
けれど、Dockerのプロジェクトってどこに置いたらいいんだろうか。
Dockerはそれ自体が仮想環境を持つから、場所さえ指定すればそのプロジェクトを読みに行くということはわかっている。

どこでもいいよ！

どこでもいいらしい。xamppというのは、xamppという環境下で実行するので、その中にいないといけなかった。
もうちょっと具体的に言えば、xamppという仕組みが/htdocsを参照するように色んな設定が組んであって、いわば「初期位置はここ！」というのが決まっていた。
なので場所が半ば固定されたようなものだったけれど、Dockerは違う。Dockerは、初期位置が無いのが特徴。
どういうわけかというと、

services:
  app:
    volumes:
      - C:/projects/my-app:/var/www/html

こうやって書けばいいから、本当にどこにおいてもいい。
DドライブにDocker Desktopを入れたからDドライブでやらなきゃいけないとか、そういう縛りも全然ない。

EC2にDockerだけ入れればいいって本当？

今まで環境構築するときはPHPとかをせっせこ入れていたけれど、本当にDockerだけでいいのだろうか。不思議な感覚。

OSさえ入っていればいいよ！

実際のアプリケーションを例に考えてみる。
例えば、こんな感じになりそう。

EC2
└─ Amazon Linux
   ├─ Docker Engine
   └─ Docker Compose
        │
        ├─ PHPコンテナ
        │   ├─ PHP 8.4
        │   ├─ Composer
        │   └─ Laravel
        │
        ├─ MySQLコンテナ
        │
        └─ Apacheコンテナ

驚くことに、シンプルなプロジェクトであればすっぽり入ってしまう。
Vhostsなどのドメインの設定さえも、すべてDocker内で完結してしまう。なんということ！原始人の驚き。

その昔、初めてEC2にプロジェクトを一人で立ち上げたとき、AWSに詳しい人もいなければインスタンスの環境構築などもってのほかだった。
１週間くらいかけて、わからないなりにごちゃごちゃのアーキテクチャで組み立ててリリースへ持って行き、その手順をマニュアル化した。
OSを立ち上げて、そこから実行するコマンドもぜーんぶマニュアルに書き起こして、便利にはなった。
そうしてもう１年経ったころ……もはや色々な案件を手垢まみれにしてしまったが、こんなシンプルな解決策があるとは。
いまからでも引き返せるだろうか。このクリーンな環境へ。

Dockerが常駐しているってどういうこと？落ちたらどうする

実際にDockerのプロセスというのがわかっていなくて、Docker Desktopを立ち上げてdocker compose up -dをやる……という表面だけ知っている。
今まではこう、OSにぴったりくっついているから動く、というイメージがあった分、OS -> docker -> アプリとなると、なんか不安。

実は同じ。OSが全部やってるわけじゃない

アプリが動くには、例えばApacheはphp-fomだったり、httpdだったりが必要になる。
これを明示的にsystemctlで再起動したりしていたわけだけども、dockerが代わりにそれをやってくれるようになるだけ。
つまり、アプリの本質はOSが色々やってるんじゃなくて、結局そのエンジンとかが立ち上がっているかどうかなのである。

そう考えてみると、dockerはちょっと間に入って色々やってくれているだけで、別に本質はエンジンと変わらない。dockerだって落ちるし。

そしたら、dockerを起動したり、常駐させたり、落ちたときの復帰だったりはどうするのだろうか？

restart policyという自律機能がある

Dockerは落ちたときのために、自動で再起動するような指示をあらかじめ埋め込んでおける。
例えばrestart: unless-stoppedのような指示があり、「明示的に止めていない限り、自動で復活してください」という状態にできる。

さて、ここまでくれば簡単で、初回のアプリ起動時は普段と同じようにcompose up -dを行う。
そしてsystemdにdockerを入れて、restart policyを定義する。
これだけで、もうdockerは動き続ける。簡単！

ちなみに新しいアプリをまた追加するときは、個別にcompose upする必要があるけれど、dockerプロセス自体はもう常駐化しているので、もっと楽ちん。
言ってみれば、Windowsで普段使いしているのはDocker DesktopというGUIアプリ。Linuxで使うのは、Docker Engineそのもの。

実際にEC2に配置するときどんな手順？

具体的な手順をしればもっと理解は深まるはず。ということで、実際にdocker engineを入れた後どうやってアプリを設置するのかを聞いてみた。

sudo mkdir -p /opt/your-project
cd /opt/your-project

git clone <repository-url> .
cp .env.docker.example .env.docker
vi .env.docker

docker compose config
docker compose up -d --build

docker compose exec app php artisan migrate --force
docker compose exec app php artisan config:cache
docker compose exec app php artisan route:cache
docker compose exec app php artisan view:cache

curl http://127.0.0.1:8080/up
docker compose ps
docker compose logs -f queue scheduler

え、これだけ？
いつもEC2にアプリ起動するまで本３ページ分くらいのコマンド実行してるんだけど……。

超シンプル！

過程を簡単にまとめると、まず/opt（optional）という場所にdocker用のディレクトリを作成。
/var/wwwは公開ディレクトリなので、今回はちょっと扱いが違う。ただしそこにおいても一応動きはするので、ただの基準みたいなものではある。

次にgitからcloneしてきて、dockerをビルド。Laravelの設定をする。
なんとこれだけ。あとは疎通確認とか。

これまではphp入れて、mysql入れて、node入れて、git入れて、あああああ～
ってやってたのにこれだけ。

実際にもっと本番運用に適した形にするのであれば、もう少しディレクトリの権限設定などをする必要がある。
けれども、それにしたって手順が少ない。早くやりたくなってきた。

まとめ

dockerからは逃れられない、という先人からのありがたいアドバイスは、「必要に迫られて仕方なく使う」だと思っていたけれど……。
実は、dockerを使わない手はなくない！？と気付くことだったのかもしれない。全部dockerにしたくなってきた。
なんでphp8.2をずっと使って縛られてたんだろう。mysqlサーバーが毎回ぶっ壊れてちまちま直してたのが、なんだか悲しく思えてきた。
ということで、また実作業ができるようになったら続きを更新していきたい。(このラフな形式で書くのはすごく楽しかった)