私は以前から Nix について耳にしていた。例えば “Nix in 100 Seconds” という動画で簡単な説明などを受けていた。ただ、Nix は少し話を聞いたくらいでは全く理解できず、自分個人にとっての必要性も感じていなかった。主に macOS を使う自分は Homebrew で満足した日々を送っていた。
それがある日、企業でのインターンシップの機会に恵まれた。初めてのちゃんとした（ビジネスやお金が賭かっていて、複数人が何年間もかけて作り上げてきたプロダクトやインフラがある）開発の現場だった。
セキュリティには普通の学生よりは詳しいと自負していたため、今まで特別気にしてこなかった会社のプロダクトやインフラのセキュリティ面を見ることになった。最初のプロジェクトとして Docker イメージをルートレス化する作業に取り掛かった。複数のリポジトリで管理されているコードベースの一つ一つに入っているDockerfileを手直ししていき、少し慣れてきたところで、Python を使っている大き目のアプリケーションに取り組んだ。そこでは Python の管理のためについ最近 uv へと移行していた。
どうもこの uv がルートレスモードとの相性が悪かった。手元の開発環境ではルートレス化した Dockerfile をビルドして、テストを通すこともできたのだが、ステージング環境で一連の動作を試してみると、ビルドすらできなくなる。シニアエンジニアの方と何時間か一緒に作業したのだが、原因は uv がパッケージを最後に同期しようとするところでルート権限が必要になり、ビルドが失敗しているというところまでしか突き止めることができなかった。恐らくこのイメージをルートレス化するとなると、Dockerfile の書き換えか、uv 本体への改変が必要だったため、断念した。
uv 自体がv1.0.0前のツールであることだったり、セキュリティ対策を後から組み込むのには困難があるのは当然のことだが、それでもこれは大変だった。
なぜそもそもこんな問題は起きてしまったのか。どうすれば防げたのか。もっと良い方法はないのか？ここで Nix について思い出した。このルートレス化したイメージと uv の問題を防げなかったとしても、パッケージ管理についてずっと考えていたら、一部の人からベタ褒めされていた Nix が頭を過った。少なくとも再現性の高さや、宣言的であることから、原因究明がもう少し早くなったのではないだろうかと思った。
こうしてこのインターン経験は Nix について探っていくきっかけにもなった。