Raspberry PiへのFedora IoTインストール：OSTreeでエッジシステムに「不死身」の安定性を – ITFROMZERO

Table of Contents

午前2時の悪夢：アップデートがエッジステーションをダウンさせるとき

IoTに携わる多くのエンジニアが、次のような光景に遭遇したことがあるはずです。中心部から50km離れた倉庫で、ゲートウェイとして動作しているRaspberry Pi群を運用しているとします。午前2時ちょうど, システムから接続断の通知が届きます。電圧降下やネットワーク切断により<a href="https://itfromzero.com/ja/fedora-vi-ja/dnf-automatic%e3%82%92%e4%bd%bf%e3%81%84%e3%81%93%e3%81%aa%e3%81%99%ef%bc%9afedora%e3%81%ae%e3%82%a2%e3%83%83%e3%83%97%e3%83%87%e3%83%bc%e3%83%88%e3%82%92%e5%ae%89%e5%85%a8%e3%81%8b%e3%81%a4%e3%83%97.html">dnf upgrade</a>が途中で失敗し、オペレーティングシステムが完全に破損（corruption）してしまったのです。

従来のディストリビューションでは、唯一の解決策は現地まで車を走らせ、SDカードを抜き取り、最初からフラッシュし直すことでした。これは多大な時間と労力を要します。私がFedora IoTに切り替えた理由はそこにあります。2年間使用してみて、その真の強みはアップデートの速さだけでなく、技術の「鍵」であるOSTreeにあると確信しました。

なぜ一般的なエッジシステムは「突然死」しやすいのか？

問題は、Raspberry Pi OSやFedora Serverのファイルシステム管理方法にあります。パッケージをインストールする際、パッケージマネージャーは/usrや/binを直接上書きします。

システムの不整合： ファイルの書き込みが中断されると、OSは「半分古く、半分新しい」状態に陥ります。カーネルパニックは避けられません。
ロールバックは贅沢品： 数GBもある重いイメージのバックアップがない限り、以前の安定した状態に戻すことはほぼ不可能です。
セキュリティリスク： root権限があればいつでもシステムファイルを変更できてしまい、マルウェアがOSのカーネル深くに侵入する隙を与えてしまいます。

Fedora IoTとOSTree：OSに対する「Gitライク」なアプローチ

ファイルを上書きする代わりに、OSTreeはGitのように動作します。システムファイル全体は読み取り専用（Read-only）モードで配置されます。アップデートのたびに、新しい「コミット」が作成されます。

アップデートが失敗した場合は？ブートメニューで古いコミットを選択するだけで、システムを即座に正常な状態に戻せます。これは、ブートローダーの設定が非常に複雑なスナップショット（Btrfs）を使用する手法に比べて、大きな進歩です。

Raspberry Piへの実践的な導入ガイド

1. 専用ツールによるイメージの書き込み

Raspberry Pi用のFedora IoT (aarch64) イメージをダウンロードしてください。BalenaEtcherを使う代わりに、互換性を最適化するためにarm-image-installerを使用することをお勧めします。

# Fedoraマシンにインストーラーをインストールする
sudo dnf install arm-image-installer

# イメージを書き込み、SDカードのパーティションを自動的に拡張する
sudo arm-image-installer --image=Fedora-IoT-40.raw.xz --target=rpi4 --media=/dev/sda --resizefs --addkey=~/.ssh/id_rsa.pub

Tips： --addkeyフラグは非常に重要です。Fedora IoTはセキュリティを高めるため、デフォルトでSSH経由のパスワードログインをブロックしています。

2. rpm-ostreeによるシステム管理

dnfコマンドのことは忘れてください。Fedora IoTでは、rpm-ostreeを使用します。htopのようなツールを追加インストールすると、システムは元のOSを直接修正するのではなく、新しいレイヤーを作成します。

# マシン上のOSバージョンを確認する
rpm-ostree status

# 新しいパッケージをインストールする
sudo rpm-ostree install htop
sudo reboot

再起動が必要なことは、最初は煩わしく感じるかもしれません。しかし、これはシステムを常にクリーンで予測可能（predictable）な状態に保つための、価値ある代償です。

3. Podmanによるアプリケーションの実行

Fedora IoTの哲学は、「ホストOSを極限までシンプル（minimal）に保ち、すべてのアプリケーションをコンテナ化する」ことです。Podmanが標準搭載されており、root権限なし（rootless）でコンテナを実行できるため、権限昇格攻撃のリスクを最小限に抑えられます。

# IoTプロジェクト用にMQTTブローカーを実行する
podman run -d --name mosquitto -p 1883:1883 eclipse-mosquitto

# コンテナをPiの起動時に自動開始させるためのsystemdファイルを作成する
podman generate systemd --name mosquitto --files --new

「命の恩人」的機能：ロールバックとGreenboot

アップグレード後にシステムに不具合が生じた場合、コマンドを1つ打つだけです：

sudo rpm-ostree rollback

即座にデバイスはブートデプロイメントを入れ替え、以前の安定したバージョンに戻ります。

さらに特筆すべきは、Fedora IoTにはGreenbootが搭載されていることです。このツールは、起動後にヘルスチェック用スクリプトを自動実行します。再起動を3回試みてもアプリケーションが応答しない場合、Greenbootは人間の介入なしに自動的にロールバックを実行します。これこそが、私が毎晩安心して眠れる理由です。

現場への導入から得られたアドバイス

現場へのデバイス設置プロジェクトを数多く経験し、3つの重要な教訓を得ました：

高耐久（High Endurance）SDカードへの投資： OSは読み取り専用ですが、ログやコンテナのデータは常に書き込まれます。6〜12ヶ月後のハードウェア故障を避けるため、専用のカード（Samsung Pro Enduranceなど）を使用してください。
Cockpitの活用： コマンド入力が苦手な場合は、cockpitをインストールしましょう。ブラウザ上でCPUやRAMの監視、コンテナ管理ができる洗練されたウェブインターフェースが手に入ります。
Zezereの活用： 数百台規模のノードをデプロイする場合は、モニターを接続せずにリモートでデバイスを構成できるZezereによるプロビジョニングメカニズムを調べてみてください。

Fedora IoTのようなイミュータブル（不変）OSへの移行は、サーバー管理の習慣を変える必要があります。しかし、夜中にシステムが勝手に自己修復し、ベッドから出る必要がなくなったとき、この変化が完全に価値のあるものだったと実感できるはずです。