システムをメンテナンスしてますか?
この記事は「レバテック開発部 Advent Calendar 2024 」の23日目の記事です!
昨日の記事は、 HY さんでした。
レバテック開発部の松浪です。
突然ですが、利用しているライブラリを定期的にバージョンアップしてますか?
LTSのnodeを使っていますか?
バージョンアップを怠っていると以下のような問題が発生する可能性があります。
- セキュリティ上の脆弱性を突かれて攻撃される
- バグによりシステムの動作が不安定になる
- 新しいバージョンで追加された便利な機能やパフォーマンス改善が利用できない
- 新しく導入したいライブラリやツールとの互換性がなく導入できない
- コミュニティからのサポートが得られない
たとえ面倒でも定期的にバージョンアップすることで、これらの問題を回避することができます。
私が所属しているチームでは月に1回、システムメンテナンスとしてバージョンアップ作業を実施しています。
今回はどのようなメンテナンス作業を実施しているか紹介したいと思います。
システムのメンテナンスでやること
大きくは以下の4つです。
- ライブラリを(極力)最新にバージョンアップする
- nodeのバージョンを最新のLTSに合わせる
- yarnのバージョンを最新のLTSに合わせる
- Dockerイメージに脆弱性がないか確認する
1. ライブラリを(極力)最新にバージョンアップする
yarn upgrade-interactive
を実行して、バージョンアップされたライブラリがあるか確認します。
yarnはバージョン4になってからとても直感的に対象を選択できるようになりました
パッチバージョン・マイナーバージョンのアップデート内容は基本的に取り込みます。
メジャーバージョンの場合、アップデート内容に破壊的変更が入っている可能性があるので、リリースノートを確認したりビルドできるか試したりして、取り込めるか確認します。
破壊的変更によって簡単には取り込めないのであれば、タスクとして起票して別の機会にアップデートを実施します。
次に、 yarn npm audit
を実行して脆弱性の確認を行います。
結果が No audit suggestions
であれば問題ありません。
逆に↓のような結果が出た場合、脆弱性が含まれることを示唆しているので、できる限りバージョンアップしましょう。
├─ axios
│ ├─ ID: 1097680
│ ├─ Issue: Axios Cross-Site Request Forgery Vulnerability
│ ├─ URL: https://github.com/advisories/GHSA-wf5p-g6vw-rhxx
│ ├─ Severity: moderate
│ ├─ Vulnerable Versions: >=1.0.0 <1.6.0
│ │
│ ├─ Tree Versions
│ │ └─ 1.4.0
│ │
│ └─ Dependents
│ └─ (リポジトリ)@workspace:.
2. nodeのバージョンを最新のLTSに合わせる
nodeの公式サイトのリリースを見て、最新のLTSのバージョンを確認します。
nodeはメジャーバージョンが偶数であるものの最新を取り込みます。
奇数であるものは実験的なバージョンに該当するのでスルーします。
.node-version
や GitHubのワークフローのyml、package.json の engines
など、nodeのバージョンを指定している箇所を更新します。
3. yarnのバージョンを最新のLTSに合わせる
パッケージマネージャとしてyarnを利用しているので、公式サイトを訪れて、最新のstableのバージョンを確認します。
CLIで yarn set version stable
コマンドを実行して、 .yarnrc.yml
や package.json
など、yarnのバージョンを指定している箇所を更新します。
4. Dockerイメージに脆弱性がないか確認する
利用しているライブラリに脆弱性がなくても、作成したDockerイメージ内に脆弱性が潜んでいる可能性があります。
なのでECRに脆弱性スキャンを実施し、結果を確認します。
ECRのスキャンの方法は公式のユーザガイドを参照してみてください。
スキャンの結果は、AWSコンソール上から「 Amazon ECR > プライベートリポジトリ > (対象のリポジトリ) > イメージ」を選択すると確認できます。
警告レベルが重要(CRITICAL)または高(HIGH)で、かつ、Statusが「Active」であれば、基本的には対応することにしています。
脆弱性IDがリンクになっているので確認すると対処方法が掲載されています。
↑こちらの場合だと、fast-xml-parserを4.4.1以上にバージョンアップすることで脆弱性を取り除けそうです。
↑こちらはOS自体に脆弱性が含まれるので、Dockerの最新のベースイメージを利用したりslim版を利用することで解消できる可能性があります。
Tips: ベースイメージはslim版を利用した方が良い
例として、node:22.11.0-slimとnode:22.11を比べてみます。
slim版は含まれる脆弱性が少なくイメージサイズも小さいことがわかります。
これはnode.jsの実行に必要なコアなパッケージしかslim版には含まれていないためです。
イメージサイズが小さく脆弱性も少なければ、セキュリティリスクを軽減できるので、本番環境ではslim版を利用することを推奨します。
1〜4まで済んだらステージング環境でテストおよび動作検証を行い、問題がなければリリースします。お疲れ様でした。
メンテナンスを継続するために重要なことは?
十分な開発工数?徹底した履行管理?気合いと根性?
いずれも重要だと思います。
が、個人的には気楽にメンテナンス対応できる状態にするための「自動化されたテスト」があることが、継続する上で最も重要かなと考えています。
自チームでは単体テストの他にPlaywrightによるE2EテストとAutifyによるE2Eテストを実施しています。
(Autifyを利用した取り組みについては、別の記事で詳しく記載しています。)
Autifyを利用した取り組み
単体テストやE2Eテストが実施され、正常に通ることである程度は安心してリリースすることができます。
おわりに
定期的にメンテナンスすれば、1リポジトリのメンテナンス作業は1時間もかからないですし、手順も同じなのでほぼルーチンワークになります。
ちょっとした手間で脆弱性の少ない安全なシステムを維持できるので、これから新しくシステムを作る方はぜひメンテナンス作業を定期的に実施する運用を検討してみてください。
明日は sotaro8181 さんが投稿します〜
「レバテック開発部 Advent Calendar 2024」をぜひご購読ください!
レバテック開発部の公式テックブログです! レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech
Discussion