CMD について語りたい : その Dockerfile、30 秒無駄にしてるかも？

このスライドはYouTubeムーザルちゃんねる動画の資料です。
動画はこちらから見れます。
https://youtu.be/zbyMdaSGctg

Dockerで「CMD node server.js って普通に動くし、問題ないでしょ？」…そう思っていた時期が、僕にもありました。実はこの書き方、コンテナがうまく終了しない原因になっているかもしれません。

この動画では、
・CMD の シェル形式 vs exec形式 の違い
・SIGTERM が届かない・反応しないコンテナの仕組み
・PID 1 問題とその対処法
・npm run の罠と OS によるシグナル伝搬の違い
などについて解説します！

Transcript

1. CMD について語りたい その Dockerfile、 30 秒無駄にしてるかも？
2. ある日の午後
3. 「zaru さんの書いた Dockerfile 間違ってるのでプルリク送ります」
4. 届いたプルリク - CMD node server.js + CMD ["node", "server.js"]
5. Oh...
6. ということで、 なんとなく理解したつもりだった CMD を調べました
7. CMD の書き方、 解説
8. CMD の書き方は 2 種類ある シェル形式と exec 形式 # シェル形式 CMD node idle.js # exec形式 CMD ["node", "idle.js"] exec形式ではなくJSON形式とも呼ぶことがありますが、 ここではexec形式で統一します
9. 同じくコマンド実行するが プロセスの作られ方が違う シェル形式は sh が PID 1 で、 指定コマンドは子プロセスの親子関係 /bin/sh -c "指定コマンド" が実行される exec 形式は指定コマンドが PID 1 の単体プロセス PID 1 とは、 OS が最初に起動するプロセスのこと(SystemInit) 何が違うのか？
10. /bin/sh -c "node idle.js" ってなに？ -c オプションは引数の文字列をコマンドとして実行する この例では "node idle.js" を実行 eval() に近いノリという理解で、 だいたいあってる
11. シェル形式は 1 個プロセスが増える （親子になる）
12. 動くけど CMD は exec 形式で必ず書いて！ # シェル形式 CMD node idle.js # exec形式 CMD ["node", "idle.js"] 今日はこれだけ覚えて帰ってもらえたら OK です 違いはあれど、 どちらも動く
13. 次の問題に正解したら、 この先は見なくても あなたは十分 CMD を理解しています
14. Node.js が動く Docker コンテナ、 シェル形式と exec 形式の 2 つある。 SIGTERM で、 それぞれのコンテナを 終了させることはできる？ SIGTERMとは終了してね、 という依頼を送ること （要は、 コンテナを止めること） 問題 問題
15. // idle.js ずっとスリープして待機するだけのコード setInterval(() => {}, 1 << 30); # シェル形式 CMD node idle.js # exec形式 CMD ["node", "idle.js"] 2 つのコンテナを終了させてみる （docker kill --signal SIGTERM ） その結果は？
16. exec 形式が推奨で、 シェル形式は非推奨 → 次は解答スライド / みんなも考えてね ヒント
17. 解答 どちらも終了しない
18. よくある解答例 「シェル形式は終了しないが、 exec 形式は終了する」 僕もそう思ってました 一般的には合っているが、完全ではない
19. ではここから、 深堀りしていきます
20. なぜシェル形式で書かないほうが良いのか そもそもの疑問 そもそもの疑問
21. 結論 コンテナを終了できないことがあるから
24. 問題が意地悪すぎた
25. シェル形式だと終了できない exec 形式だと終了できる というのが、 一般的なケースでは正しい理解です 問題については後ほど、 詳しく解説します シェル形式だと、 実行時に引数を渡せなくて困る事もあるが今回は省く
26. で、 コンテナを終了できなくて何が困るの？
27. 1. デプロイ時間が無駄に長くなる 2. 処理中のものが強制終了される AWS ECS 環境を前提に話します 終了できないと、 これが困る
28. 困りごと 1 デプロイ時間が無駄に長くなる 終了したいけど、 終了できないコンテナが ある場合の AWS ECS の挙動を確認してみる
29. AWS ECS コンテナ終了の流れ
30. AWS ECS コンテナ終了の流れ
31. AWS ECS コンテナ終了の流れ
32. 終了依頼し、 少し待っ て終わらなかったら 強制終了する
33. ECS でデプロイした時、 新しいコンテナを起動させつつ、 古いコンテナ を SIGTERM で終了させるが、SIGTERM に反応しないと一定時間待 機してから SIGKILL で強制終了させる デフォルトだと、 30 秒間待機するので無駄、 嬉しくない / ECS Fargatgeだと秒単位で課金 ローカルのDocker終了も10秒待機するので、 やはり嬉しくはない デプロイ時間が無駄に長くなる
34. 困りごと 2 処理中のものが強制終了される 処理が終わってないのに強制終了される流れを確認してみる
35. 処理中のものが強制終了される流れ
36. 処理中のものが強制終了される流れ
37. 処理中のものが強制終了される流れ
38. SIGKILL で強制終了されるということは、処理中だったとしても問答 無用で終了させられる → 結果、 ユーザ体験が悪いのに加え、 データ 不整合も起こり得る ALB使ったWebアプリの場合、 先にALBのドレインが実行されるので、 強制終了されても処理 は終わっている状況がほとんど。 だがWorkerやドレイン時間を超える処理がある場合は危険 処理中のものが強制終了される
39. ということで、 ちゃんと終了させたいですよね
40. シェル形式が終了しない理由を探る
41. 復習：CMD の書き方でプロセスが変わる
42. 実際にプロセスを確認してみよう
43. ps -ef コマンドでプロセスを確認する
44. pstree -p コマンドで視覚的な関係も見れる
45. プロセスの違いは分かった これが終了にどういう影響が？
46. 前提知識：プロセス終了の流れ プロセスを終了するには、 終了してねとシグナル SIGTERM を送る プロセスはシグナルを受け取ったら自身を終了処理する、 という流れ
47. CMD の書き方で、 シグナルの受け手が変わる
48. PID 1 で動く sh が何もしないから シェル形式で終了しない理由
49. PID 1 で動いている sh はシグナルを受け取っても 何もせずに無視 する。 結果、 終了の要請をしても終 了されない PID 1以外であれば終了します
50. はい、 これでシェル形式よりも exec 形式が良い理由が分かりましたね
51. コマンドが直接シグナルを 受け取れるので安全に終了できる exec 形式が推奨される理由
52. ここで改めて最初の問題 exec 形式でも終了しない疑問に戻る
53. なぜ PID 1 で node が動き 直接シグナルを受け取れるのに終了しないの？
54. 実は Node.js も、PID 1 で動く場合に限り、 デフォ ルトではシグナルを受け取っても何もしないから 正確には Node.js が内部で依存しているイベントループライブラリの libuv の挙動。 つまり 実質的にはNode.jsはshと同じ挙動になる。 ちなみにNode.js以外のRubyなどではデフォル トでも終了するので、 ランタイムによって挙動は違う ただ、 libuvに依存してないDenoやBunも同様にPID 1だとシグナルを無視する挙動。 これが 意図的かどうかは不明
55. じゃあ、 どっちにしても駄目じゃん
56. PID 1 でも、 スクリプト側でシグナルを受け取る処理を書けばプロセ スを終了させることができる process.on("SIGTERM", () => { // SIGTERMが来たら、 自分自身を終了させる console.log("SIGTERM received, exiting..."); process.exit(0); }); 大丈夫、 対応方法はあります
57. 参考：Node.js の Web サーバで Graceful Shutdown // 必要な箇所だけ抜粋 import http from "http"; function shutdown() { // 新しい接続を受け付けず、 処理中の接続が終わったら実行される server.close((error) => { if (error) { process.exit(1); } process.exit(0); }); } process.on("SIGTERM", shutdown);
58. フレームワークによって対応しているものもあれ ば、 自分で書く必要があるものもあるので 「フレームワーク名 Graceful Shutdown」 で検索してみるといいかも
59. docker run --init とオプションを指定すると、 docker-init が PID 1 で動き、 いい感じにシグナルをハンドリング(転送） してくれる。 こうすれば node は PID 1 ではないので普段通りの挙動になる docker-init は Tini というライブラリを内部で使っているので、 直接 Tini をインストールす ることでも対応が可能 別解 : --init を使う
60. まとめ
61. シェル形式は sh のプロセスが増える PID1 で動く sh と node は特殊 exec 形式にして、 安全に終了させる対応をしよう まとめ
62. ・ ・ ・
63. まだ、 深堀りたいですか？
64. CMD ["npm", "run", "start"] で 起動したコンテナ、SIGTERM で安全に終了できる？ 問題 問題
65. FROM node:22-slim # Debian CMD ["npm", "run", "start"] "scripts": { "start": "node idle.js" } // SIGTERM 対応コードを定義済み process.on("SIGTERM", () => { console.log("SIGTERM received, exiting..."); process.exit(0); });
66. 解答 終了するが、 SIGTERM 対応コードは実行されない
67. npm run start の動きを確認してみる
68. npm は別プロセスで動かしてくれる
69. npm はシグナルを子プロセスに渡してくれる
70. でも sh で死ぬ
71. OK,完全理解
72. まだ、 深堀りたいですか？
73. CMD ["npm", "run", "start"] で 起動したコンテナ、SIGTERM で安全に終了できる？ 問題 問題
74. え、 同じ問題？
75. 微妙に違います
76. FROM node:22-alipne # Alpine CMD ["npm", "run", "start"] "scripts": { "start": "node idle.js" } // SIGTERM 対応コードもちゃんと定義済み process.on("SIGTERM", () => { console.log("SIGTERM received, exiting..."); process.exit(0); });
77. 解答 SIGTERM 対応コードを実行して終了する
78. 比較してみよう 終了するが SIGTERM 対応は実行されない FROM node:22-slim # Debian CMD ["npm", "run", "start"] "scripts": { "start": "node idle.js" } // SIGTERM 対応コードもちゃんと定義済み process.on("SIGTERM", () => { console.log("SIGTERM received, exiting..."); process.exit(0); }); 終了し、 SIGTERM 対応も実行される FROM node:22-alipne # Alpine CMD ["npm", "run", "start"] "scripts": { "start": "node idle.js" } // SIGTERM 対応コードもちゃんと定義済み process.on("SIGTERM", () => { console.log("SIGTERM received, exiting..."); process.exit(0); });
79. 終了するが SIGTERM 対応は実行されない FROM node:22-slim # Debian 終了し、 SIGTERM 対応も実行される FROM node:22-alipne # Alpine 片方は Debian で、 もう片方は Alpine になっている OS が違う！
80. 実はOS （シェル） によって、 sh -c の挙動が違う
81. /bin/sh は他のシェルへのエイリアスになっている Debian 系は sh は dash のエイリアス Alpine は sh は busybox sh のエイリアス RHEL 系は sh は bash のエイリアス
82. dash は子プロセスを作る bash はプロセスを置換する busybox sh もそう
83. Docker のベースイメージで 良く使われる Debian 系だけ 動きが違う
84. あらためて Debian と Alpine の違いを見てみよう
85. sh -c のプロセスがシグナル処理するので Node.js の SIGTERM 対応コードが実行されない Debian(dash)
86. sh -c プロセスが置換され node がシグナル処理するので Node.js の SIGTERM 対応コードが実行される Alpine(busybox sh)
87. npm run xxx を使わず node xxx.js を使う もしくは、 自前で exec を使ってプロセス置換する… 環境依存になりやすいのでオススメはしない 対応方法
88. さいごのまとめ
89. CMD は exec 形式 ["node", "server.js"] で書こう OS(シェル)によって挙動が異なるので注意しよう ランタイムによって PID 1 の挙動が異なるので注意しよう もし SIGTERM 対応が必須なら npm run は避けよう 自分のコンテナが強制終了されたときのリスクを把握しよう まとめ