パソコンが重くなるけど、Dockerが手放せない、ユゲタです。
webサービス系開発で、その開発環境をDockerで作るって、もはや定石ですね。
すぐに複製できるし、環境依存になる事が少ないので、macでもwinでもlinuxでも、同じ挙動で動作できるので、とてもありがたいシステムです。
でも、そんなDockerで1日ぐらいの時間を費やしてしまった、初期構築トラブルがあったので、備忘録として残しておこうと思います。
何が起こったのか？
現在行っている、「SEOに強いWEBフレームワークOSSプロジェクト」で、node環境をmacのbrew環境で作って、まあまあ安定したα版が出来上がったので、
サーバーモジュール連動を行う機能を追加しようとして、dockerで環境構築をしようとしたんですが、nodeとphpとnginxを立ち上げて、nginxでアクセスURLの拡張子で、phpアクセスを振り分ける処理をしようと考えました。
実はこのプロジェクトの初期にもDockerでやろうと思って少し作業をしていたのですが、スピード優先でmac-brewに切り替えて作業をしていたのを思い出し、その作業の続きを行っていました。
とりあえず、node立ち上げと、nginx連動はうまく動作できたのですが、phpコンテナだけがどうしてもうまく立ち上がってくれません。
何度やっても意味不明なエラーが出て、行き詰まってしまいました。
ちなみに、その時に表示されていたエラーは次のモノです。
[emerg] 79#79: io_setup() failed (38: Function not implemented)
原因究明
このエラーを調べても、nginxがphpにアクセスできていないというもので、「phpコンテナのエラーでなんでnginxのエラーが出とんねん！」と、半ばイラ立ち始めていました。
とりあえず、docker logsでエラーログを調べつつ、docker execで、phpコンテナに入って、色々調べていたところ、/etcを覗いてみたら、/etc/phpフォルダが存在しない事に気が付きました。
そして、何故か、nginxフォルダが存在していたんですね・・・
あれ？？？？
なんじゃこりゃ・・・
Dockerfileにそんな記述はしていないし、コンテナも、"php:8.0-fpm"を指定しているのに・・・なじぇ？？？
ふと思い出したのが、このプロジェクト初期の頃に、nginx+phpのコンテナを作っていて、phpコンテナという名前を付けていたのを思い出しました。
そして、macのdockerアプリのダッシュボードを立ち上げてみたところ、その中の「images」で、これまで作られているイメージ一覧を眺めていたら、
今回作ったはずのphpイメージが「18 days ago」って書かれているではないですか・・・
1日ぐらい作業しているので、「1 days ago」って書かれていなければいけないのが、
18日前・・・プロジェクトの開始ぐらいのタイミング・・・
ということで、一旦このイメージをremoveしてみました。（GUI便利！）
そして、再ビルド（単にupしただけ）してみると、時間はかかりましたが、無事に立ち上げ成功！
phpアクセスもnginxから問題なくできました。
オーイェ！
グレート！
このトラブルから得られた教訓
どうりでDockerfileを修正しても更新されなかったはずだが、docker-imageを削除しながら作業をすれば、こうした古い履歴に引きづられなくてスムーズに作業出来るということを理解できました。
そして、それをしないまま、本番デプロイすると、新規ビルドした時に、想定したイメージが作られないという不手際も生まれてしまうという事も同時に悟りました。
便利なようで、こうした事をしっかりと抑えていないと、とんでもないしっぺ返しをくらってしまう可能性があることを、同時に感じて学習することができましたね。
とりあえず、一度作ったイメージは、定期的に削除してみると、いろいろなことに気がつけるかもよ。
0 件のコメント:
コメントを投稿