脱Node.jsに着手したのは3年前。多くのプロセスをdenoに移行したが、最終的にrollupとsassが残っていた。
開発プロセスに支障が出たため、これらもnodeを使わない方式に変更することとした。
コンテナが再起不能になる
不可解なことに、npm installやrollupを実行するとハングアップし、それ以後kubernetesのコンテナを再作成できない事象に遭遇した。
nodeのプロセスはkill -9コマンドを使用しても操作できない。そして、このプロセスを実行しているコンテナはkubectl deleteが完了しない。--forceオプションで強制終了すると、最終的に次のコンテナが作成できない状態に陥る。仮想ネットワークを割当てるフェーズのエラーで停止する。
コンテナの再作成は一晩たっても復旧することはなく、最終的に該当ノードを削除したうえで新規ノードを追加しなければ戻らない。要するに直す方法がない。
kubernetesでは多種多様なワークロードを実行しているが、コンテナ内のプロセスがコンテナ制御を破壊するようなケースにはこれまで遭遇したことがない。
いかなる場合にも、クラスタはコンテナの制御を失うべきでない。おそらくnodeの挙動が、何らかの脆弱性をついているのだと思う。
このケースでも他のコンテナに影響が波及していないため最低限の隔離はできているように見える。しかしそれもコンテナ機能による隔離ではなく、単に基礎的なLinuxのプロセス管理の効果なのではないか。
denoのnpm互換の進展
根本的にはクラスタの問題ではあるが、クラスタが修正された場合にはnodeが動作しなくなる。よって実務上は、nodeを使わないことで最終解決を図れる。
kubernetesホストの問題は、クラウドプロバイダがOSビルドにカジュアルに失敗しているケースに遭遇したことがあり、品質を過信できない。年々改善してきているとすら言えないと考えており、使い方を制約することが動作のポイントとなる。
幸いdenoのnpm互換性が向上したことで、nodeのCLIとして実装されているrollupと、nodeのJavascriptコードとして呼び出すsassライブラリのいずれもdeno上で動作する状況になった。
npmのCLIについては、代替ツールである
pnpmが安定動作している。ただしpnpmはnodeを内包しているように見えるため、最終解ではないような気がしている。
denoの実行時キャッシュに頼っていくのが適切な可能性がある。
ひと通りnode依存を除去できたため、次の段階では実行環境からnodeを除去して経過を観察する。
基本的に各種CLIはdeno run npm:<npm-package>を用いて動作する。いまのところCloudFlare公式のwranglerがnodeの拡張オプションを使用している影響で動作していない。このように特殊なオプションに依存しているものは、可能な限りツールの使用を廃止すべきなのだろう。
