対象：共有ビルド機の小チーム・技術責任者。キーワード：共有リモートマック・rsync・NFS・ビルド成果物・権限隔離。並行でも配布先を壊さないよう、直列／増分同期とNFSキャッシュの場面分け、ロック・umask・ロール別SSH証明書・rsync競合パラメータを表とFAQにまとめます。マルチノード協調・デプロイ同期・権限隔離と併読を。
つまずきの整理
同一成果物パスへの同時書き込みは半端配布と権限ずれを招きます。原則は「局所ビルド→公開は原子的入替え」。共有プールFAQのキューとも揃えてください。
rsync直結・増分同期・NFSローカルキャッシュの適用場面
| 方式 |
向く場面 |
注意 |
| rsync直結（単発フル） |
リリース単位でスナップショットを丸ごと複製、監査ログを残したいとき |
帯域・時間は増えやすい。直列ジョブかオフピーク推奨 |
| rsync増分 |
日次・コミットごとの差分配布、キャッシュ再利用でビルド時間を削りたいとき |
削除同期ポリシー（--delete系）を誤ると他ジョブ成果を消すリスク |
| NFSマウント＋ローカルキャッシュ |
開発検証で同一ツリーを低遅延参照、複数ノードが読み取り中心のとき |
ロック意味が弱く、同時書き込みは設計が要る。オフライン耐性はrsync側 |
判断マトリクス（並行・権限・競合）
| 状況 |
推奨 |
補足 |
| 同時ビルドが多い |
ジョブ別出力→配布だけ直列または原子的リネーム |
キュー深度はプールFAQの目安と連動 |
| 読み取り主体・低遅延 |
NFS読み取り＋ローカルビルドキャッシュ |
書き込みは専用ボリュームかrsyncワンショット |
| 監査・再現性最優先 |
rsync増分＋manifestハッシュ記録 |
OpenClaw連携はWebhook通知参照 |
| 権限トラブル多発 |
ビルド／配布／閲覧のOSユーザ分離＋umask027 |
SSHは下記ロール別証明書 |
並行ビルド：ディレクトリロックとumask
- ディレクトリロック：配布先ルートに対し
flockや専用ロックファイルで「publish」ステップを同時一にする。ビルド自体はワークスペース別で並列化。
- 一時領域：
.tmp-<job-id>/へrsyncし、成功後にmvで公開名へ入替え。読取側は常にシンボリックリンクまたは固定エイリアスを参照。
- umask：共有グループ運用なら027（ディレクトリ750・ファイル640目安）、個人のみ077。成果物を権限隔離したい場合はビルドユーザと配布ユーザを分け、配布側のみ書込可能ディレクトリへ限定。
SSHユーザー証明書のロール分離（推奨）
SSH証明書と揃えた最小例です。
| ロール |
許可の目安 |
目的 |
| builder |
ワークツリーとローカル成果ディレクトリのみ書込 |
コンパイル・テストの爆発半径を限定 |
| publisher |
公開ストアとロックスクリプトのみ |
rsync入替えと権限修正に限定し誤削除を防ぐ |
| reader |
読取と検証コマンドのみ |
QA・ダウンロード用。秘密鍵を広げない |
競合処理のrsyncパラメータ提案
- 原子性：一時ディレクトリへ同期後リネーム。
--inplaceは公開パスでは慎重に。
- 削除：
--deleteはジョブ専用宛先に限定し、共有親には--excludeで保護。
- 退避・帯域：
--backup-dirと--bwlimit。増分は--link-destも検討。
よくある質問
- NFS上で直接ビルドしてよいか
- 検証は可も、ロック遅延で不安定になりやすい。本番系はローカルビルド、NFSは読み取りキャッシュ寄りが安全。
- 増分で古いファイルが残る
- 削除ポリシーを固定し
--dry-run必須。共有親への--deleteは二重確認。
- 権限が崩れる
- umaskかACLか
--chmodを一本化し、publisherのみ最終調整。
まとめ
局所生成と公開配布を分離し、届け手はrsync、低遅延読取はNFS。並行はロック＋入替え、権限隔離はumaskとSSHロールで。
ホーム・ブログ一覧・ヘルプ。購入・ノード選定はログイン不要。
共有ビルド
成果物配布を安定運用
購入・ノード選定はログイン不要。ヘルプで接続・購入ページで構成を。
rsync
NFS
権限隔離