Raspberry Pi デプロイ5方式を7軸比較

Raspberry Pi やエッジデバイスにコードを配る方法は、意外と多いです。SSH で入る、機械側に取りに来させる、deb にする、コンテナごと置き換える、A/B パーティションで焼く。目的は同じでも、到達性・権限・ロールバック・帯域・観測性を並べると性格が割れます。5方式を7軸で比較して、自分の環境ならどれを選ぶかまで絞ります。実機で確認済みなのは現時点で1方式で、残りは一次資料からの評価です。

読み終えるとできること

• 自分の状況から第一候補を選べます。1〜数台に設定ファイルを配るだけなら push 型か pull 型、現地に人が行けないなら A/B パーティション型、機械ごとに何が入っているか問い合わせたいならパッケージ型です
• CI に NOPASSWD: ALL を渡さずに push 型を組めます。sudoers に実行できる引数のパスまで書いて権限を削ります
• 「配ったつもり」で届いていない状態を、webhook が使えない場所でも検知できるように設計できます
• 署名を足すときに、鍵をどこに置くかと、古い正規の版を配り直す攻撃をどう止めるかまで含めて決められます

シリーズ目次全 7 章

1. 0 Raspberry Pi デプロイ5方式を7軸比較 Pillar (現在のページ)
2. 1 実測: CI から SSH で配る権限の削り方 CI から SSH で入って配る方式。5方式で唯一の実測済みです。NAT の内側へは VPN に一時参加、NOPASSWD: ALL は sudoers に引数のパスまで書いて避けます。
3. 2 pull 型: 外から入れない機械と3つの通知 機械側が S3 などから引く方式。どこに居ても届く代わりに、取りに来なかった機械に配る側から気づけません。webhook が使えない場所の通知3手も。
4. 3 deb 配布: 200台の状態を数える apt リポジトリを立てて deb で配る方式。5方式で唯一「何が入っているか」を機械に問い合わせられます。設定ファイルでは conffile が最初の壁。
5. 4 コンテナと A/B: 2面で置き換える コンテナごと、またはシステム領域ごと置き換える方式。壊れたら機械が単独で前の面に戻ります。代わりに常駐物と帯域が5方式で最大になります。
6. 5 コード署名と鍵の置き場所: 5方式に共通する穴 署名を足すのは簡単で、難しいのは鍵の置き場所と、古い正規版を配り直す攻撃です。5方式に共通する穴を apt の Valid-Until まで見ます。
7. 6 デプロイ方式の選定: 4つの質問で候補を2つに絞る 7軸の表を自分の状況に当てる手順。入れるか・行けるか・何台あるか・状態を問うかの4つで候補は2つに落ち、最後は常駐物を増やせるかで決まります。

Raspberry Pi の上で動いている何かの設定を書き換えたい。手元のリポジトリに push したら、それが機械に届いてほしい。

やりたいことは1行で書けるのに、配り方は5つあります。SSH で入る、機械側に取りに来させる、deb にする、コンテナごと置き換える、A/B パーティションで焼く。結局どれを選べばいいのか。ここで決まるのは配り方だけではありません。壊れたときに戻せるか、配る側にどこまでの権限を渡すことになるか、機械が数日オフラインでも追いつけるか。全部これに引きずられます。

このシリーズでは、その5つを同じ課題に対して並べて読みます。同じ設定ファイルを同じ機械に届ける、という条件を揃えて比べると、教科書の「メリット・デメリット」より役に立つものが出てきます。5方式が同じ性格を示す軸と、真っ二つに割れる軸です。後者のほうが判断材料になるので、このシリーズは割れる軸を先に見つけて、そこから方式を選び直す順番で組んであります。

1台から数台の Raspberry Pi に、週に数回、設定ファイルを配るだけなら、候補は push 型と pull 型の2つです。機械側に置くものが、公開鍵1行か小さなプログラム1つで済みます。

残りの3方式に進む理由は3つです。現地に人が行けない（壊れても取りに行けないので、機械が自分で前の状態に戻れることが必須になります）、台数が数十を超える（何台が新しい版になったかを数える手段が別に要ります）、機械ごとに何が入っているかを問い合わせたい。どれか1つでも当てはまるなら、パッケージ型・イメージ型・A/B パーティション型を見ることになります。

この判断を7つの軸に分解して、最後に4つの質問へ落とすのがこのシリーズです。

揃える課題

比較が意味を持つのは、5方式に同じ仕事をさせたときだけです。方式ごとに違う題材を持ってくると、方式の差なのか題材の差なのか分からなくなります。

このシリーズの共通課題はこれです。

• 配るもの: 設定ファイル数枚（YAML 3〜4個と、それを参照するルールファイル群）。合計で数十 KB
• 配る先: Raspberry Pi 1台。家庭またはオフィスの LAN の内側、グローバル IP なし
• 反映条件: 置いたあとプロセスに読み直させる（再起動ではなく reload で済ませたい）
• 失敗条件: 壊れた設定を置くとプロセスが起動しなくなる。戻せないと監視が止まります
• 頻度: 週に数回。人間が git に push したとき

意図的に小さい題材を選んでいます。数十 KB の設定ファイルなら5方式のどれでも配れますが、これがコンパイル済みバイナリ 200MB になると、その時点でパッケージ型とイメージ型しか現実的でなくなって比較そのものが成立しません。

小さい題材で軸を出してから、「これがバイナリだったら」「これが100台だったら」と条件を動かして考えます。そういう読み方をしてもらう前提で組んでいます。

5つの方法

名前だけ先に置きます。詳細はそれぞれの章で。

A から E に向かって、機械側に置くものが増えていきます。そのぶん配る側は楽になり、失敗したときに機械が自力で立ち直る能力が上がります。この交換が、このシリーズで一番大きな軸です。

マトリクス

表を見ると、A と E が両端にいます。A（push 型）は機械にほぼ何も置かない代わりに配る側が機械の中まで手を伸ばし、E（A/B パーティション型）は機械に更新エージェントと2つ目の領域を持たせる代わりに、失敗したら配る側が何もしなくても機械が勝手に元の面へ戻ります。

真ん中の B・C・D は、どちらに寄せるかの度合い違いです。C（パッケージ型）だけは少し性格が違って、状態をパッケージという単位で持つぶん、何が入っているかを機械に問い合わせられます。これは他の4方式には無い性質です。

7つの軸

表の列に並べた7つが、その物差しです。ここが曖昧だと、5つの記事が5つの感想文になります。

7つのうち到達性・常駐コスト・ロールバックの3つで方式がはっきり割れます。残り4つは、方式そのものより実装の仕方で決まる部分が大きくなります。

自分ならどれか

4つの質問（機械に入れるか / 現地に行けるか / 何台あるか / 状態を問い合わせる必要があるか）を通すと、候補は2つまで絞れます。結果だけ先に置きます。

2つ残ったあとは、常駐プロセスを1つ増やせるかで決まります。増やせるなら機械側に判断を持たせる方式、増やしたくないなら push 型です。技術の優劣ではなく、運用に人手をどれだけ割けるかの話になります。質問の順番と、決めたあとに何を補強するかは6章にあります。

このシリーズの検証状態

2026-09-01 の時点で、実機で動いているのは A（push 型）だけです。

マトリクスの ◎○△✗ は、一次資料と設計上の性質から書いたものです。実機で測った値は1つも入っていません。ここを区別せずに数字や体感を混ぜると、表全体が「並べて動かしてみた」という嘘になるので、一次資料から言えることには URL を添え、言えないことは書かずに空けてあります。

実測済みの A がどういう構成かというと、GitHub Actions から Tailscale 越しに Raspberry Pi へ入り、CI には root を渡さず sudoers に引数のパスまで書く形です。この1方式だけはTailscaleでPiにCIデプロイ:権限3層に組んだ当時のログが残っています。

検証は公開リポジトリで進めます。同じ設定ファイルを同じ機械に5通りで配る、という共通の課題を置いて、動いたものから表を更新します。更新のたびにセルが「一次資料」から「実測済み」へ上がっていく構造にしてあるので、いまどこまで確かめたかが外から見えます。

読む順

1から4は独立しているので、気になる方式から読んで構いません。5だけは全部読んだ後に読むほうが効きます。1から4を読んで「この方式なら安全そうだ」と思ったものが、署名の章に来ると全部同じ穴を持っていることが分かる作りになっているからです。