npm で作られたプロジェクトの依存モジュールを更新する npm-check-updates

npm で作ったパッケージのnode_module の更新をしたい

npm でインストールしたパッケージはどうも使い捨ての傾向があり、アップデートを継続するにはちょっと手間が必要で。

更新可能なパッケージをを見つけるには

npm のサブコマンドを使えばできる

npm update 
npm outdated

これらのコマンドを実行して更新可能な最新版にアップデート可能なモジュールを見つけて更新していくわけだが。

めんどくさい。

npm-check-updates

npm-check-updates 略して、 ncu というパッケージがある。

これを使うと package.json の中身を更新してくれるわけで、便利そうである。

アップデート手順

npm install npm-check-updates
npx ncu -u 
npm update 
npm install 

これで、一通りのアップデートが可能になる。思ってたより楽である。

開発者が想定したpackage.json を更新するのである。当然であるが、依存モジュールをアップデートすると、decrepcated なメソッドやバージョン差異による動作不良に悩まされることもあるので注意が必要である。

参考資料

• https://dackdive.hateblo.jp/entry/2016/10/10/095800
• https://flaviocopes.com/update-npm-dependencies/
• https://docs.npmjs.com/updating-packages-downloaded-from-the-registry

which コマンドでPATHにある同名のコマンドを全部列挙する

PATH の優先順位に悩まされるたときに which

which コマンドを使うと 環境変数 PATH にあるコマンドのうち、最初に見つかったもの（実行されるもの）を表示してくれます。

which python 

どのコマンドが実行されるのか調べるのに便利ですし、よく使ってると思います。

同名のコマンドで上書きされてないか？

pyenv や nvm や rbenv などを使っていると、あれ？バージョンが合わない？パスがおかしい？？？？

などという事がよくあります。

こういうときにPATHに含まれる全てのもの列挙できたらと思いませんか

すべてを表示する which -a / --all

コマンドがいくつも同じ名前で入っている場合に、全てを表示してくれます。

表示順は、PATHの優先順位が高い順に表示してくれます。

takuya@nissan-enter-api$ which -a grep
/Users/takuya/.bin/grep
/usr/bin/grep

takuya@nissan-enter-api$ which -a java
/usr/bin/java

takuya@nissan-enter-api$ which -a python
/Users/takuya/.pyenv/shims/python
/usr/local/bin/python
/usr/bin/python

これをすることで、 python が同名でいくつもあることがわかったり、＄PATHに同じパスが重複していたり、bashrc や pipenv shell などで .bashrc の意図した動作にならない。 順序がおかしくなっていることに気づくことができます。

関連資料

https://takuya-1st.hatenablog.jp/entry/2017/04/06/153337

参考資料

• which -h

systemd のdaemon のサービスを定期的に再起動する unit ファイルの書き方

systemd のサービスを定期的に再起動する

systemd で作ったサービスを定期的に再起動したい。

定期的に再起動する必要があるのか。と問われれば、私自身も答えに窮するのだけれど。

今回は pip install しているpython パッケージや npm run で起動している元になっている npm/node_moduleを、定期的更新して再起動をしたいなと思ったんですよ。

systemd の書き方

[Service]
Restart=always
RuntimeMaxSec=864000

unit ファイルに上記のように書くと定期的に再起動がかかる。

仕組みの説明

RuntimeMaxSec による実行時間の制限

RuntimeMaxSec=60

RuntimeMaxSec をつけることで、サービスのプロセスの継続実行時間を秒単位で指定できる。今回は　60*60*24*10 = 864,000 を指定した。

Restart による再起動の設定

Restart=always

Restart　の設定を alwaysにしておくと、サービスに定義したプロセスが異常終了など、終了したときに自動再実行によりプロセスが起動している状態を維持してくれる。

組合わたら、定期的に再起動

これらを組合わたら、定期的に再起動のコマンドが実現する

[Service]
Restart=always
RuntimeMaxSec=864000

組み合わせてしまうと、指定時間経過後にプロセスが終了して、always により再度サーバーが実行される。

検討したその他の手法との比較など

crontab に書いてしまうと、管理がsystemd と分かれてしまうのであまり好ましくないし。

サーバーが自分を自分で再起動するように sleep を使った定期的に再起動が仕込まれた起動用python スクリプトを書くのは煩雑すぎるし。

systemd の timer を使っても、設定が２つに別れてしまって面倒だ。

今回採用した方法だと、設定ファイルが１つにまとまるので書き捨てて仕様書を残さなくても気付けるメリットが有る。

systemd の設計者は、こういう利用は想定外なんだろうと思うんだけど、１箇所に必要な設定が集まるのは嬉しい

pip や npm の更新が辛い

npm でパッケージをいれて、npm run で動かせるサーバーアプリケーションがおおいけど、パッケージはlock されて基本的には更新を考慮してない。

debian の apt などは セキュリティ・パッチが含まれた deb などをaptの設定自動的にダウンロードして再実行してくれる。ほんとうにこの差は大きいと思う。

gitlab とは自動的に自分で自分を更新してくれるし、そういう意味で node のnpm で作られたサーバーって今後危ういなぁなどと思う。

関連資料

• systemdのジョブの起動前、起動後に処理を記述する preExec / PostExec - それマグで！

参考資料

• systemd.service