HN 日本語サマリー

← 一覧へ戻る
インフラ・DevOps

NixOS が私を臆病でなくさせている

NixOS is making me less afraid (entropicthoughts.com)

137 pointsby ibobev91 コメント

要約

著者は、NixOS を導入したことで、新しいソフトウェアの導入やサーバーの管理に対する不安が軽減されたと述べています。NixOS の宣言的な設定により、デプロイメントや復旧が容易になり、メンテナンスの手間が大幅に削減された経験を共有しています。これにより、以前は敬遠していた自己ホスト型サービスへの挑戦が容易になったと語っています。

全文翻訳

NixOS が私を楽にしてくれている

[画像: nixos-is-making-me-less-afraid.jpg]

少し面白いことが起こりました。FreshRSS というものについて読み、良さそうだと思ったので、サーバーにインストールして使い始めたのです。これは1年前ならありえなかったことですが、1年前はまだNixOSサーバーを持っていませんでした。


過去数年間、私のRSSフィードはローカルのスマートフォンにのみ保存されていました。それには良い考えがありました¹。私はほとんどの場合、コンピューターから離れているときに読む時間を作ることができます。しかし、実際にはうまくいきませんでした。まず、多くのことはより大きな画面で読む方が簡単です。しかし、100ものフィードにわたる何千もの記事の既読/未読ステータスを管理するために電話アプリを信頼するのは脆いものでもありました²。特に、別のスマートフォンに切り替えたとき、すべてのフィードを移行することはできましたが、既読/未読ステータスは失われてしまいました。私が本当に欲しかったのは、サーバーサイドのフィードアグリゲーターでした。これはサーバー上で実行され、RSSフィードを管理し、その後、Webインターフェースまたはクライアントアプリケーションを通じてRSSフィードを読むことができるソフトウェアです。私はそれをしばらく欲していましたが、デプロイメントの維持という別のサイドプロジェクトになるため、これまで一歩を踏み出すことができませんでした。

しかし今、NixOS の経験を積んだことで、動作するFreshRSSの設定(バックアップを含む)を追加するのに、わずか9行のNixコード³しかかかりませんでした。これに加えて、nginxのリバースプロキシ設定にさらに十数行追加されました。特定のlocationブロックから proxy_pass を行いたかったため、Cookieパスの書き換えが必要になり、少し複雑になりました。しかし、それは私の問題であり、NixOSの問題ではありません。

このインストールは、過去数ヶ月間、手をかけずに機能しています。もしそのサーバーが壊れた場合、おそらく15分程度で、全く同じ設定を実行する新しいサーバーを起動できます。このようなことができるようになると、新しいソフトウェアを試さない理由が文字通りなくなります。

NixOS 以外で FreshRSS をインストールする場合と比較してみてください。その場合、私たちは

  1. アーカイブをダウンロードして適切な場所に展開する。
  2. 指示に従って権限を設定する。
  3. サーバーに必要な追加依存関係とともに nginx と php-fpm をインストールする。
  4. php-fpm プールを設定し、nginx がリクエストを php-fpm に渡すようにする。
  5. Let's Encrypt 証明書を設定する。
  6. バックアップを設定する。
  7. そして、後で新しいサーバーまたはアップグレードされたサーバーに FreshRSS を再インストールする必要が生じた場合に、上記すべてを実行する方法を覚えておくことを願う。

もちろん、FreshRSS プロジェクトはコンテナイメージを提供しており、これによりプロセスが少し短縮されます。これは Apache と mod_php を設定し、それらを正しく構成すると主張しています。その後、バックアップを設定し、コンテナを実行する systemd サービスを作成し、コンテナイメージには TLS サポートが含まれていないため、その前面で TLS 終端リバースプロキシとして nginx を管理するだけで済みます。これらは依然として覚えておくべきことですが、同じコンテナイメージをダウンロードしたことを記録しておかない限り、6ヶ月後に再インストールするときに同じものが機能するという保証はありません⁴。ソースからコンテナイメージをビルドしても役立ちません。なぜなら、時間差で分離された同じ Dockerfile からの2つのビルドでも、かなり異なるコンテナイメージが生成される可能性があるからです。


私は以前、サイドプロジェクトのメンテナンスをどれほど嫌うかについて言及しました。それには自分のコードだけでなく、他人が開発したセルフホスト型サービスも含まれます。時折数分間のメンテナンスは許容できますが、何かをアップグレードするために中断のない作業時間を数時間確保したり、緊急メンテナンスにいかなる時間も費やしたりすることは、コンピューターで作業したいという私の意欲を完全に殺いでしまいます。

私の性向であれば、構成管理やコンテナオーケストレーション、あるいはその両方に深く没頭しているだろうと思うかもしれませんが、そうではありません。CFEngine、Ansible、podman、k3s で真剣な試みをしてきましたが、どれも私のインストール/設定/デプロイメント体験を、(a)注意深く書き留めること、そして時には(b)それらの注意深いメモを ssh コマンドのシーケンスを実行するシェルスクリプトに変えることよりも、著しく改善しませんでした⁵。はい、これは本質的に Ansible を再発明しているようなものですが、より壊れにくいです。誰かが pip を横目で見ても壊れることはありません。シェルスクリプトの欠点は、時間が経つと無効になる前提条件に依存したり、異なる環境で使用されたりすることがよくあることです。NixOS の設定は、私自身への注意深い指示のように読めますが、それらは実行可能であり、毎回同じ結果を生み出します。