l

o

a

d

i

n

g

.

.

.

dockerで意味のわからない不具合事象が発生した話

2026/05/25

Docker

t f B! P L
eyecatch 先日仕事でとあるプロジェクトのオレオレフレームワークを、Laravelフレームワークにコンバートする作業で発生した不具合が少し不思議な状態だったので、ブログに備忘録しておきます。 エンジニアじゃない人は、今回のブログの意味もわからないし、内容も全く興味がないと思いますので、読み飛ばしていただいて構いません。

発生事象

今回の事象は、ローカル開発環境で発生しました。 作業中にとあるJavascriptのモジュールで不具合を見つけて修正しようと思い、まずはコンソールに変数の値を表示しようと、ファイル内に console.log(data) とdataに入っている値を確認しようとしたんです。 そうすると、何故か、 "syntax error" が表示されました。 最初は、タイポかと思っていたんですが、何も間違っていない。 付け加えた命令を元に戻すと、エラーは無くなります。 試しに、改行を入れてみると、それでもエラー・・・ そこでエラー内容を見に行くと、なんと、プログラムが中途半端な形になっているのを発見してしまいました。 なんじゃこりゃあ!!

推測

ここで重要なのが、エンジニアとしての推測です。 一体どういう原因でこんな事象が起きているのか?という推測をすることで、 それが当たっていれば、問題は無事に解決します。 でも、当たっていなければ、ひたすら推測を繰り返す・・・ ただ、やみくもに推測するのではなく、コンソールコードを入れたり、少しプログラムを変更したり、色々なテストを行いながら原因を追求するというのが重要なんです。 この作業は、エンジニアの経験から推測の質も量も変わってきますが、最近ではAIに原因推測を行わせるというのも悪くはないでしょう。 ということで、AIに原因を考えさせてみると、「そんなことはありえない」と言ってきました・・・ でも、実際のエラーコードを与えて、プログラムコードの問題があるかどうか原因を考えさせてみたところ、「ブラウザキャッシュではないか?」と推測してきました。 「プログラム文字列と、それをキャッシュするstring.lengthに乖離があるのではないか?」と詳しく原因を言ってきたんです。 そもそも、ブラウザキャッシュで、文字列と、文字数が乖離するなんて、これまでみたことも聞いたこともないので、それを突っ込んでみると、 「それもそうですね・・・」とAIは返してきたので、なかなか可愛いそぶりをしてくれるじゃないか、と思ってしまいました。 本番にアップされている同じモジュールで確認してみたら、本番ではそんなことは起きてはいないという事も併せて確認できました。 でも、それが少しヒントにはなって、これは、ローカル環境でしか起きていないという確信に変わりました。 さらに、AIは、「Nginxの設定を疑え」とずっと言い続けていましたが、個人的には、dockerが原因なのではないかと考えてその1点で調査を進めてみたところ・・・

原因

原因がわかりました。 dockerのvolumeマウントの箇所で、publicフォルダ(app/や、src/の場合もあります)に、":consistent"というオプションを指定することで、今回の事象はスッキリと解決しました。 Docker for Macは、元々、「ボリュームマウントの精度が低い」と言われていて、今回もそれが不具合に繋がったわけです。 これまでのオレオレフレームワークは、シンプルなHTMLファイルをマウントする極めてストレートであまり負荷のかからない構成だったのですが、 avelは、とにかくファイル数も多くなるし、構成が複雑になったため、dockerのキャッシュによって、ファイルのlengthが固定化されてしまって、ファイルを修正した際に、元のファイル文字数をキープした状態になっていたんですね。 dockerのvolume:マウントは、デフォルト(何も書かない状態)では、":cached" となっていて、ファイルのオーバーヘッドをキャッシュする仕様になっているのだそうです。 この":consistent"というオプションは、それを「完全同期」する仕組みにするオプションで、Mac版のdockerでは、これをつけた方が今回のような不具合は無くなります。 ただ、volume全体につけるのは、dockerの負荷が高くなるだけなので、今回のようなコンテンツ部分で、修正変更が多い箇所にオプションをつけるのがいいようです。

あとがき

そもそも、Laravelフレームワークへの変更は、今回作業をしている会社からの意向で行っているんですが、 オレオレフレームワークの方がなんだか性能がいいようにも思いました。 そのサービスに最適化された状態になっているし、そもそも、フレームワークは、オーバースペックな状態で、無駄な機能もてんこ盛りなので、今時とか普通は・・・というだけの理由でフレームワークを変更すると、その後に痛い目を見ることになるということを、改めて感じた開発依頼の作業でした。 まあ、正直、自分がそこの社員だったら、もっと徹底的にエンジニア視点の意見をぶつけるんですが、委託なので、言われたままの作業をまずはしてあげて、その後問題が起きた時に、また作業依頼をしてくれるだろうという程度の従順な対応を取ることにしました。 でも、作業内容で手を抜くわけではないですよ。 やるからには全力でエンジニアリングを行いますけど、本心は別のところにあるのが人の通常の心理ですよね。

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ