第05回: ネットワークとサービス間通信 — コンテナはなぜ「localhost」で繋がらないのか?
DockerでPHPとMySQLを別々のコンテナで動かし、PHPから localhost でMySQLに接続しようとすると失敗します。「同じマシンで動いているのになぜ?」——これはDockerネットワークの仕組みを知ると一瞬で解決します。
Month
DockerでPHPとMySQLを別々のコンテナで動かし、PHPから localhost でMySQLに接続しようとすると失敗します。「同じマシンで動いているのになぜ?」——これはDockerネットワークの仕組みを知ると一瞬で解決します。
Dockerを使い始めて最初に驚くのが「コンテナを削除したら、入力していたデータが全部消えた」という体験です。これはDockerの仕様通りの動作ですが、知らないとひどく焦ります。
Dockerを使い始めた多くの人が経験するのが「ビルドは成功したのにコンテナが起動しない」「停止したはずのコンテナがまだ残っている」というトラブルです。これらの多くは、ビルド・起動・停止という3つの操作の関係が曖昧なことで起きます。
「新しいメンバーが入るたびに環境構築で1日かかる」「自分のマシンでは動くのに本番で動かない」——こうした問題の多くは、環境をドキュメントで管理していることが原因です。
「Dockerを学ぼう」と決めた瞬間、多くの人が「イメージ」「コンテナ」「ボリューム」という3つの言葉に一度はつまずきます。これらの違いが曖昧なまま進むと、設定ファイルを読んでも何が起きているのかがわからなくなります。
障害の多くは、機能のバグよりも「バックアップが取れていなかった」「スロークエリの監視がなかった」「権限が過剰だった」といった設定漏れや運用の穴から発生します。本番に出す前にチェックリストを持っておくことで、こうした抜け漏れを事前に防ぐことができます。
単一のMySQLサーバーにすべての読み書きが集中している構成では、サーバー障害時にサービスが完全停止します。また、アクセスが増えるにつれて読み取りクエリの負荷が書き込みを圧迫し、全体のパフォーマンスが低下する問題も起きます。
本番でパフォーマンス問題が発生したとき、「たぶんこのクエリが重いはず」という勘で対応しても、インデックスを追加したのに改善しない・別のクエリが原因だったという事態になりがちです。
“SELECT FROM users WHERE email = ‘” . $email . “‘” のようにPHPで文字列連結してSQLを組み立てると、’ OR ‘1’=’1 といった入力を受けたとき全データが返る脆弱性になります。これがSQLインジェクション攻撃で、OWASP…
開発環境の便利さそのままに、本番でも root ユーザーをアプリに使わせているケースがあります。この状態では、SQLインジェクション攻撃を受けた場合やアプリのバグでDROPが実行された場合に、データベース全体が被害を受けるリスクがあります。