Linux上でWSL体験を再現!開発環境を隔離するツール「NSL」を公開
Show HN: NSL – WSL for Linux
Show HN: NSL – WSL for Linux
WindowsのWSL2は、開発者にとって本当に素晴らしい機能ですよね。私は普段使いのOSとしてAtomic Linux系(immutableなLinuxディストリビューション)を利用していますが、WSL2と同じような感覚で複数のディストリビューションを使い分けたいと常々考えていました。そこで自作したのが「NSL」です。これは、systemd-nspawnコンテナを活用して、WSLのような開発体験を再現するツールです。単一のVM上で複数のコンテナを動かす仕組みで、WSLと同様にホストファイルの編集やポート共有もスムーズに行えます。数ヶ月おきに開発環境を壊して再インストールする…という負の連鎖を断ち切り、ホスト環境をクリーンに保つための試みでもあります。ぜひ試してみて、感想を聞かせてください!
distroboxと比べるとどう違うの?
LinuxをメインOSとして使ってる人にとって一番役に立ちそうだけど、WSLみたいだと言うんじゃなくて、既存のLinuxコンテナと何が違うのか教えてくれる?あと、WSLはコンテナじゃなくてVMだと思ってたから、それとも違うものに聞こえるな。> 開発用依存関係を入れ替えて壊しちゃうせいで数ヶ月おきに再インストールする羽目になる、それをホストOSに入れないための長い旅路の新たな一歩だ。これについてももう少し説明が必要かな。何をしてたらそんなに頻繁に問題が起きるのか気になるよ。
それって結局、LXCを再実装したってことじゃないの?
これはいいパッケージングだね。デスクトップの中に別の「マシン」をクリーンに使うのがどれだけ快適か、意外と気づきにくいんだよね。リモートサーバーや開発作業に関しては、自分のMacBookよりWSLを好むようになるなんて思ってもみなかったけど、なぜかそうなってる。自分で同じような環境を作る方法はいくらでも知ってるし、dev containersが多くの面で優れているのもわかるけど、WSLみたいなコンテナの使い勝手の良さはなんだか不思議だよ。
なんでVMとsystemd-nspawnを組み合わせるのかよくわからないんだけど。自分の理解では、WSL 2はVMを1つ立ち上げて、その中で「Linuxインストール」ごとにsystemd-nspawnみたいなのを動かしてる感じだよね。でもそれってLinuxカーネルが必要だからVMを使ってるんでしょ?すでにLinuxの上で動かしてるなら、なんで普通にsystemd-nspawnを使わないの?
WSLのアイデアを逆方向にうまくひっくり返してるね。こういうシンプルな相互運用性があれば、個人レベルのスタックがVMの動物園みたいにならずに済むよ。
試してみるよ、共有ありがとう!ちなみに今のところはmkosi(https://github.com/systemd/mkosi )経由でsystemd-nspawnを使ってる。これはイメージを作って別の名前空間で動かすものなんだけど、bashかinitで起動できてすごく速い。ただ、Debian上でUbuntuのイメージを作ったり、その逆をやったりすると問題が起きるみたい。
ホームページにDockerコンテナとnslの違いを書いておくといいと思うよ。
VMレイヤーを入れるのは主にホスト環境を汚さないため?それとも、信頼できないもの(依存関係やエージェントが生成したコードなど)を中で実行する際に、実際のセキュリティ境界としても使ってるのかな?
toolbx(あと少しニュアンスは違うけどFlatpakやsnapなんかも)みたいに、同じようなことをする既存のツールと何が違うの?それに、ツールのエコシステムをこれ以上断片化させずに、既存のプロジェクトを採用したりサポートしたりできなかった理由は何なんだろう?(上の質問と似てるけど、言い方を変えてみた)