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

移行が大変だもん

Transcript

1. Node.js v12 を使い続けていたのなぁぜなぁぜ Yuta Ide (@sadnessOjisan)
2. アップデートが大変だからです。
3. 自己紹介 { “名前”: “Yuta Ide”, “ソーシャル”: “@sadnessOjisan”, “所属”: “Nikkei”, “好きな絵文字”: “🍜” }
4. 日経電子版の Node.js 利用状況について
5. の前に、アーキテクチャーについて
6. User → CDN → オリジンサーバー
7. 垂直分割のマイクロフロントエンド構成 CDN (Fastly) Node.js Article Detail Search Market Article Index connect by anchor tags … handlebars handlebars VCL + handlebars react この発表における、垂直分割・水平分割の定義 ※垂直分割: ページごとに独立したアプリケーション ※水平分割: 1ページの中に複数アプリケーションが存 在。React, Vue 混在など。よくあるのは共通グローバル ナビヘッダーだけ独立 aggregate
8. 改めて、 日経電子版の Node.js 利用状況について
9. 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 で稼働😇
10. v12 であることで困ること • そもそもEOLなのだから上げないといけない • Lambda を更新できなくなる ◦ バグ対応を入れられなくて本当に困った！ • ライブラリのアップデートができなくなる • 機能に制限がある ◦ Error.prototype.cause ◦ TCP dump
11. 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に上げて行くも、 すでに１年が経過😇
12. なぜ 1 年もかかっているのか
13. リポジトリ数が多いから
14. 日経に存在する４の世代 • haishin: JSPで書かれた初期の世代。 • rnikkei: “R”esponsive 対応のときに刷新された実装。爆速の日経と評された世代。 • k2: React とモノレポを取り入れた世代 • web: デプロイサイクルや言語選定の都合上、 k2のモノレポで管理していない世代。
15. 日経に存在する４の世代 • haishin: JSPで書かれた本当の最初期の世代。 • rnikkei: “R”esponsive 対応のときに刷新された実装。爆速の日経と評された世代。 • k2: React とモノレポを取り入れた世代 • web: デプロイサイクルや言語選定の都合上、 k2のモノレポで管理していない世代。 リポジトリ数が最多 アクセス数が最多 rnikkei を置き換える
16. 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
17. Let's try…
18. $ node -v 12 $ nvm use v16
19. $ yarn install
20. gyp-error
21. 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 を利用
22. $ yarn upgrade @nikkei/rnikkei-build-tools@11
23. not found
24. 2つの npm registry • AWS で動かしてるVerdaccioが不安定 • package群はnpmjs.com に移行中 • 新しめのpackageのversionがVerdaccioの方には存在しない • Verdaccioの方は不安定でpublishもままならない サービスのリポジトリで利用しているregistryを npmjs.comに切り替える
25. //registry.npmjs.org/:_authToken=${NPM_TOKEN} registry = "https://registry.npmjs.org/" Local, CIに NPM_TOKEN をセットするのを忘れずに .npmrc
26. $ yarn upgrade @nikkei/rnikkei-build-tools@11
27. 👍
28. $ yarn lint on CI workflow
29. stylelint error
30. rnikkei-build-tools のバージョンを上げると lint rule が変わる • ビルドツール自体が stylelint のルールを持っている • ビルドツールのバージョンを上げるとそのルールが変わり、現行のコードが lint で弾かれる 明らかに治せるところ以外全て ignore
31. “engines”: { “node”: “^16.20.0” } package.json
32. … CMD ["yarn", "start"] Dockerfile
33. NPM TOKEN not found on runtime 😇
34. .npmrc と yarn • yarn は engines の指定と異なる環境で cli を実行するとエラーで落としてくれる。 Node バージョ ン切り替えが local, ci, container で達成されていることを担保するために yarn に切り替えたい。 • yarn に切り替えると、その環境変数を使わないスクリプトの実行を yarn run するだけで も、.npmrc の中の環境変数を参照しようとする。 • 環境変数を実行環境にセットするか、 .npmrc を省く必要がある .npmrc をコンテナに含めない
35. .npmrc .dockerignore
36. ここまでの処理で Node.js v16 が動く準備が整ったので、各種設 定ファイルを v16 へと引き上げる
37. v16 .node-version
38. ln -s .node-version .nvmrc
39. FROM node:16.20.0-bullseye-slim Dockerfile
40. definitions: workspace: &workspace working_directory: ~/workspace docker: - image: cimg/node:16.20.0 environment: CIRCLE_ARTIFACTS: "./tmp/artifact" .circleci/config.yaml
41. v18 に上げよう
42. v18 .node-version
43. yarn build
44. 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
45. 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 以降も使える保証は？😇
46. yarn build
47. 👍
48. ここまでくると v20 へのアップデートは 詰まらない
49. v20 .node-version
50. yarn build
51. 👍
52. デプロイ？
53. 動作確認
54. 目grep ドライアイが悪化した気がする
55. playwright 途中で日経IDの認証方法が変わって大変 だった よく壊れる
56. Autify GUIで作れるE2Eテストツール。 良い。
57. これで終わり？
58. １年かからなくね？
59. これを24レポジトリでやります！！！！！！！ （ツール含めたら 40 レポジトリ！！！）
60. どのように進めたか？
61. v16移行開始 reg test 整備 アップデートマニュア ル整備 v16移行実施 マニュアルやテスト の修正 v18移行実施 マニュアルやテスト の修正 v20移行開始 2022/12- 2023/4- 2023/7- 2023/10- Aさん Bさん Cさん Dさん
62. と、これ通りには行かず、 移行して失敗して移行手順書作り直しての繰り返し
63. 大変でした！！！！！！！！！！！
64. お疲れ様です！！！！！
65. 勝利！完！
66. 🤔
67. Node.js は半年ごとにバージョン上がっていくけど、 EOLのたびに毎回この儀式するのですか？
68. 😵
69. はい（やりたいとは言っていない）
70. 未来のことを考えよう
71. 辛さの根源は過剰なマイクロサービスにある • 前提: 私たちのチームは20人前後の体制 • 1, 2 個の Node バージョンをあげるくらいなら辛くない • マイクロフロントエンドという構成の都合上、サービス数が多い • サービスごとに、他のサービスに影響を与えることなく実装を変えれるのは嬉しい一方で、 20個以 上のサービスを１チームで運用するのは大変 • rnikkei 構想時は問題なかったかもしれないが、リリースから７年が経ち、サービスもビジネスも拡 大していくに連れて、１チームでマイクロサービス全てを管理するのが難しくなっている
72. メンテナンスコストを下げよう • 動作確認のコストをもっと下げる。 Playwright 改善、Autify をもっと拡充させる。 • 別々になっているレポジトリを統合してモノレポ化、可能ならモノサービス化までしたい。 （rnikkei-build-tools の要求する規約に耐えれるかが争点） • JSON API など、Node.js以外の選択肢を取れるものに限っては、可能なタイミングでメンテナン スしやすい別言語で置き換える。コンパイルでバグの有無をある程度担保できる Rust、標準ライ ブラリが大きな力を持つ Go で置き換えた実績も有る。
73. We are hiring.