Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Node.js v12 を使い続けていたのはなぁぜなぁぜ?

Node.js v12 を使い続けていたのはなぁぜなぁぜ?

移行が大変だもん

sadnessOjisan

December 12, 2023
Tweet

More Decks by sadnessOjisan

Other Decks in Programming

Transcript

  1. 垂直分割のマイクロフロントエンド構成 CDN (Fastly) Node.js Article Detail Search Market Article Index

    connect by anchor tags … handlebars handlebars VCL + handlebars react この発表における、垂直分割・水平分割の定義 ※垂直分割: ページごとに独立したアプリケーション ※水平分割: 1ページの中に複数アプリケーションが存 在。React, Vue 混在など。よくあるのは共通グローバル ナビヘッダーだけ独立 aggregate
  2. We adopt micro frontend architecture CDN (Fastly) Node.js Article Detail

    Topic Index Search Market Article Index connect by anchor tags We love HTTP and HTML handlebars handlebars handlebars VCL + handlebars オリジンサーバーに関係する 24レポジトリがNode.js v12 で稼働😇
  3. We adopt micro frontend architecture CDN (Fastly) Node.js Article Detail

    Topic Index Search Market Article Index connect by anchor tags We love HTTP and HTML handlebars handlebars handlebars VCL + handlebars v12 → v16 → v18→ v20に上げて行くも、 すでに1年が経過😇
  4. 日経に存在する4の世代 • haishin: JSPで書かれた初期の世代。 • rnikkei: “R”esponsive 対応のときに刷新された実装。爆速の日経と評された世代。 • k2:

    React とモノレポを取り入れた世代 • web: デプロイサイクルや言語選定の都合上、 k2のモノレポで管理していない世代。
  5. 日経に存在する4の世代 • haishin: JSPで書かれた本当の最初期の世代。 • rnikkei: “R”esponsive 対応のときに刷新された実装。爆速の日経と評された世代。 • k2:

    React とモノレポを取り入れた世代 • web: デプロイサイクルや言語選定の都合上、 k2のモノレポで管理していない世代。 リポジトリ数が最多 アクセス数が最多 rnikkei を置き換える
  6. rnikkei の構成技術 • rnikkei は汎用ビルドツールと汎用 Express Middleware、 汎用UIライブラリ、proxyサーバーから成り立つ、「設定よ り規約」なフレームワーク •

    rnikkei-build-tools: クライアントスクリプトのビルド、 lint, format, デプロイなどのスクリプトの集合体。 webpack や babel の設定を持つ。 • rnikkei-express: 日経電子版開発の決まり事を守るため のmiddlewareやテンプレートやcilent scriptの集合体。 APIへのアクセス、Varyヘッダーの操作関数、グローバル ナビの埋め込み、オンメモリキャッシュなどなど rnikkei-build-tootls rnikkei-express rnikkei-xxx (service) rnikkei-xxx-proxy rnikkei-ui, … (parts) APIGW
  7. rnikkei-build-tools の node-sass • rnikkei-build-tools はクライアントサイドビル ドツールも含む • Sass のビルドも担当する

    • node-sass は node のバージョン次第で gyp-error を引き起こす rnikkei-build-tools の最新版は dart-sass に 切り替わっている (dart)node-sass webpack babel /client/*js /client/*sass /server/*.js /views/*.html pkg.json rnikkei-build-tools 各サービス rnikkei-build-tools は 長く使われ ていたv9 が node-sass, v11 が dart-sass を利用
  8. 2つの npm registry • AWS で動かしてるVerdaccioが不安定 • package群はnpmjs.com に移行中 •

    新しめのpackageのversionがVerdaccioの方には存在しない • Verdaccioの方は不安定でpublishもままならない サービスのリポジトリで利用しているregistryを npmjs.comに切り替える
  9. rnikkei-build-tools のバージョンを上げると lint rule が変わる • ビルドツール自体が stylelint のルールを持っている •

    ビルドツールのバージョンを上げるとそのルールが変わり、現行のコードが lint で弾かれる 明らかに治せるところ以外全て ignore
  10. .npmrc と yarn • yarn は engines の指定と異なる環境で cli を実行するとエラーで落としてくれる。

    Node バージョ ン切り替えが local, ci, container で達成されていることを担保するために yarn に切り替えたい。 • yarn に切り替えると、その環境変数を使わないスクリプトの実行を yarn run するだけで も、.npmrc の中の環境変数を参照しようとする。 • 環境変数を実行環境にセットするか、 .npmrc を省く必要がある .npmrc をコンテナに含めない
  11. node:internal/crypto/hash:69 this[kHandle] = new _Hash(algorithm, xofLen); ^ Error: error:0308010C:digital envelope

    routines::unsupported at new Hash (node:internal/crypto/hash:69:19) at Object.createHash (node:crypto:133:10) at module.exports Node.js v18.17.1 error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. Exited with code exit status 1 CircleCI received exit code 1
  12. v16->v18におけるcryptoモジュールの変更 • webpack が内部で呼び出す Hash 関数のアルゴリズムが Node 本体のアップデートによる OpenSSL の更新によって使えなくなった

    • nodejs 17: digital envelope routines::unsupported webpack/webpack#14532 (comment) やその前後の会話から Webpack4 での正攻法の解決はできないことが分かった ◦ webpack の設定でハッシュ関数を選択できるようになるのは v5 以降 ◦ このあたりの設定をwebpack側が面倒を見てくれるのは v6 以降 • OpenSSL のモジュールを content hash の生成くらいにしか使っておらず、ビルドスクリプトは開 発時にしか使っておらず、ユーザーがセキュリティ的な脅威を受けるわけではないので、 NODE_OPTIONS=--openssl-legacy-provider を使って誤魔化す Node v20 以降も使える保証は?😇
  13. v16移行開始 reg test 整備 アップデートマニュア ル整備 v16移行実施 マニュアルやテスト の修正 v18移行実施

    マニュアルやテスト の修正 v20移行開始 2022/12- 2023/4- 2023/7- 2023/10- Aさん Bさん Cさん Dさん
  14. 辛さの根源は過剰なマイクロサービスにある • 前提: 私たちのチームは20人前後の体制 • 1, 2 個の Node バージョンをあげるくらいなら辛くない

    • マイクロフロントエンドという構成の都合上、サービス数が多い • サービスごとに、他のサービスに影響を与えることなく実装を変えれるのは嬉しい一方で、 20個以 上のサービスを1チームで運用するのは大変 • rnikkei 構想時は問題なかったかもしれないが、リリースから7年が経ち、サービスもビジネスも拡 大していくに連れて、1チームでマイクロサービス全てを管理するのが難しくなっている
  15. メンテナンスコストを下げよう • 動作確認のコストをもっと下げる。 Playwright 改善、Autify をもっと拡充させる。 • 別々になっているレポジトリを統合してモノレポ化、可能ならモノサービス化までしたい。 (rnikkei-build-tools の要求する規約に耐えれるかが争点)

    • JSON API など、Node.js以外の選択肢を取れるものに限っては、可能なタイミングでメンテナン スしやすい別言語で置き換える。コンパイルでバグの有無をある程度担保できる Rust、標準ライ ブラリが大きな力を持つ Go で置き換えた実績も有る。