Mshaleが報じた『Scaling Your Continuous Deployment Using Docker And Containers By Sean & Chris @AgileIndia2017…』と、TechRepublicの『How to share data between a Docker container and host』——コンテナ運用を巡るこの二本を、今夜のうちに並べてみましょう。私たちのような個人開発でLaravelをDocker化している環境にとっては、デプロイの自動化と永続データの扱いが、まさに"つまずきやすい二大ポイント"。両方が同じ夕暮れに並んで目に入るのは、なんだか不思議な縁を感じてしまいます。
"スケール"の話を、個人開発の再現性に翻訳してみる
個人開発では「自分がデプロイするだけ」と、ついrsyncやFTP、ときにはSSHログインしてgit pullする手順で済ませてしまう方も多いと思います。しかし、Laravelの.envやstorage配下、NuxtやViteで固めたフロントエンドのアーティファクト、WordPressでいうwp-content/uploads配下のメディア、こうした"アプリが正しさを保つために必要なもの"は、サーバー側に確実に届けたいですよね。
そのとき、GitHub ActionsやCircleCI、Docker Hubからの自動デプロイを一本のパイプラインにしておくと、再現性が担保されるだけでなく、「昨夜3時に書いたあの修正が、今朝の本番にきちんと反映されている」という安心感が得られます。万一サーバーが壊れても、新しいインスタンスを立ち上げて同じパイプラインを走らせれば、30分後には元通りの環境に戻る——それも、立派な"スケール"のかたちです。
つまり私たちの現場に翻訳すると、スケールの話とは「デプロイ手順を、自分の記憶の中ではなくdocker-compose.ymlとCIの設定ファイルに書き出しておくこと」。今夜、もしあなたのデプロイ手順が頭の記憶の中だけに存在しているとしたら、それが一番のボトルネック、と一度書き留めておいてください。
データ共有は、"コンテナが消える前提"で考えるとちょうどいい
TechRepublicの記事は、ホストとコンテナの間でデータを共有する方法を扱った解説です。Dockerを使っていると、docker run -v /host/path:/container/pathや、docker-compose.ymlのvolumes:指定を、なんとなく雰囲気で書いてしまいがちです。ただ、コンテナは設計上"使い捨てられる前提"で動く仕組みですから、データベースの中身、ユーザーがアップロードした画像、ログ、SSL証明書、SSH鍵、こうした"消えてほしくないもの"は明示的にホスト側へ出し、永続化しておく必要があります。
特にLaravelでは、storage/app配下のユーザーファイルと、MySQLやPostgreSQLのデータボリュームを、しっかり分離しておかないと、docker-compose down && upした瞬間に画像もユーザーアカウントもまとめて消える、という本当にありがちな事故が待っています。私自身、最初にこの罠にハマったときは、深夜に「なんで全部消えたんだ…」と頭を抱えた経験があります。WordPressを同じDockerで運用する場合も、wp-content/uploadsとデータベースの両方をボリューム化しておかないと、テーマを更新した拍子にメディアが全部消えた、ということにもなりかねません。
よくある落とし穴は、./src:/var/www/htmlのようにソースコードをそのままマウントしているのに、その上にcomposer installやnpm run buildの結果物を"コンテナ内にだけ"置いているケースです。コンテナを作り直した瞬間にビルド成果物も消えて、本番だけ表示が崩れる、という本当に嫌な症状が出ます。
もうひとつの落とし穴は、コンテナの中で作ったSSH鍵や.envをそのままコンテナ内に残してしまうパターンです。docker compose exec app bashで中に入って鍵を作り、それでCIも回していると、コンテナを作り直した途端にデプロイが通らなくなります。鍵も.envも、ホスト側のディレクトリにマウントして、コンテナは"設定を持たない"くらいに割り切るのが、後で楽になります。
今夜のうちにご自身のdocker-compose.ymlを開いて、永続化したいパスとエフェメラル(使い捨て)でよいパスを、コメントでもいいので書き分けておくことをおすすめします。.env、DBデータ、storage/app、wp-content/uploads——この四つだけでも線を引いておけば、後で泣きを見る確率がぐっと下がります。ボリューム指定が一段落したら、次はバックアップ戦略というテーマが、自然と立ち上がってきます。
compose.yamlを開く、夜の五分間
「とりあえず動いたからOK」「コピペで動いたからヨシ」ではなく、"なぜこのボリューム指定が必要か"まで手を動かして確かめてみると、後で困ることがぐっと減ります。MshaleとTechRepublicの二本、それぞれ短い記事ですが、コンテナ運用でよく詰まる二つの論点をちょうど補完し合うラインナップになっています。
夜の一時間があったら、まず片方の記事(お好みで)を読みながら、ご自身のdocker-compose.ymlを開いてみてください。永続化したいパスが一目で分かる状態になっているか、CIの設定ファイルがgitリポジトリの直下にあるか、その二点だけでもチェックできれば、今夜の時間は十分すぎるほど有意義です。
そして最後に、もう少しだけ自問してみてください。「明日、このサーバーが急に消えても、同じ環境を別の場所で30分以内に再現できるか」——この問いに"たぶんYES"と答えられるなら、もうあなたは個人開発のDevOpsの基礎を超えています。逆に"うーん…"と詰まったら、その"うーん"こそが今夜読むべき二本の価値です。次回は、docker-composeのネットワークとサービス間通信について、一緒に整理していきましょう。