1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
use-cases / cron-that-expires-itself / hero
HOODY CRON / 自動失効エントリ
完了したら自分で消える cron ジョブ
不安定なバグを追跡していますか? 48 時間プロセスツリーを毎分ダンプし、その後二度と実行しません。expires_at を設定したマネージド cron エントリを POST すれば、スケジュールには半減期があります — リマインダーも、クリーンアップ PR も、6 か月後に残った古いエントリもありません。
cron.containers.hoody.com
https://cron.containers.hoody.com/api/v1/cron/users/me/entriesライブ
idスケジュールコマンド失効ステータス
- a1f2*/5 * * * *curl -fsS http://prod/healthなし恒久
- c4b90 3 * * */usr/local/bin/backup.shなし恒久
- e7d3* * * * *pgrep auth | tee -a tree.log2026-05-06T11:14:00Z失効予定
- 9b21@hourlypsql -c 'VACUUM ANALYZE'なし恒久
- f0a80 9 * * 1-5/srv/cron/digest.sh2026-05-31T09:00:00Zアクティブ
エントリ e7d3残り 02:14:37
POST/users/me/entriesリクエストボディ
{ "schedule": "* * * * *", "command": "pgrep auth | tee -a tree.log", "expires_at": "2026-05-06T11:14:00Z" }
expires_at 付きで POST /users/me/entries — エントリは毎分実行され、期限になると自分自身を削除します
use-cases / cron-that-expires-itself / lifecycle
半減期を持つスケジュール
3 つの瞬間。期限付きでエントリを作成。スケジュールは自動的に実行。expires_at に到達したら、エントリは自分自身を削除 — そして crontab はデバッグを始める前の状態に戻ります。
自動失効エントリのライフサイクル作成 → 実行 → 失効
01 / 作成
expires_at 付きで POST
schedule、command、48 時間後の expires_at タイムスタンプを含むマネージド cron エントリを API に送信します。id とエントリが有効化された確認が返されます。
02 / 実行
スケジュール通り実行
エントリは cron 式の各ティックで実行されます — 毎分、毎時、設定した通りに。恒久エントリと同じ動作ですが、1 つだけ静かな違いがあります。
03 / 失効
期限になると自分で削除
壁時計が expires_at を超えると、エントリは削除されます。最終実行なし、ゾンビ行なし、手動クリーンアップなし。GET /entries は、あなたがいなかった場合と同じリストを返します。
クリーンアップスクリプトなし。カレンダーリマインダーなし。6 か月後に「これ誰の担当?」というチーム全体のスレッドもありません。エントリはいつ消えるべきかを知っており、その通りに消えました。
use-cases / cron-that-expires-itself / mechanism
2 つの curl と 1 つの時計
POST でエントリを作成。49 時間後に GET で消えたことを確認。仕組み全体は 2 つの HTTP コールとタイムスタンプだけ — SSH する cron デーモンも、編集する /etc/crontab もありません。
create.sh
POST# create a self-deleting cron entry curl -X POST \ https://cron.containers.hoody.com/api/v1/cron/users/me/entries \ -H "Content-Type: application/json" \ -d '["schedule":"* * * * *","command":"pgrep auth | tee -a tree.log","expires_at":"2026-05-06T11:14:00Z"]' # response HTTP/1.1 201 Created { "id":"e7d3", "expires_at":"2026-05-06T11:14:00Z", "enabled":true }
verify.sh
GET# 49 hours later — list is back to normal curl GET https://cron.containers.hoody.com/api/v1/cron/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "expires_at":null, ... }, { "id":"c4b9", "expires_at":null, ... }, { "id":"9b21", "expires_at":null, ... } ] # e7d3 was here. e7d3 deleted itself.
expires_at フィールドが契約です。クリーンアップを覚えておく必要はありません。覚えておくことはプロトコルの一部ではないからです — 期限こそがプロトコルです。
use-cases / cron-that-expires-itself / powers
半減期が解き放つもの
スケジュールに失効日が付くと、3 つの問題が消えます: ドリフト、見落とし、監査疲れ。crontab はデフォルトでクリーンに保たれます。
ドリフトなし
crontab が肥大化しない
「ちょっとだけ一時的に…」という全エントリに期限が組み込まれています。crontab は自動で剪定されます — 四半期ごとのクリーンアップスイープなし、誰も削除したがらない (誰も何をしたか知らないので) 古い行もありません。
見落としなし
忘れても大丈夫
エントリの削除を覚えておく必要はありません。カレンダーにリマインダーを設定する必要もありません。クリーンアップ PR を提出する必要もありません。期限こそがリマインダーであり — 必ず発火します。
監査可能
ログはエントリより長く残る
エントリは消えますが、実行履歴は残ります。各実行にはログ行、終了コード、タイムスタンプがあります — 「これは 48 時間動いて止まった」という記録は、後から完全に再構築できます。
use-cases / cron-that-expires-itself / capacity
安く、速く、複数
自動失効エントリのコストは恒久エントリと同じです。必要なだけ積み重ねてください — チーム内のすべてのデバッガが同時に 3〜4 個の一時ジョブを実行するケースを想定して API は設計されています。
- 最小粒度1 分
標準の cron 式、最小 1 分の解像度。expires_at フィールドは任意の RFC 3339 タイムスタンプを受け付けます。
- アカウントあたり数百
デバッガのチームが恒久ジョブと並行して数個の一時プローブを実行するのに十分な容量。
- 手動ステップ0 クリーンアップ
DELETE コールを覚えておく必要なし。バックログに「古い cron をクリーンアップ」というチケットなし。エントリは自分自身の終わりを処理します。
上限はアカウントの cron サービスティアに応じてスケールします。エントリ自体が失効した後も、ログは標準の Hoody Cron 保持期間に従って保持されます。
use-cases / cron-that-expires-itself / punchline
一時的な作業が恒久的な crontab エントリを残してはいけません。
従来の方法半減期方式
expires_at なしecho '* * * * * pgrep auth …' >> /etc/crontabそして無視するカレンダーリマインダー
expires_at ありPOST /entries [ expires_at: "+48h" ]スケジュールが期限に自分自身を削除します
use-cases / cron-that-expires-itself / replaces
これが置き換えるもの
ワンショットの cron 行が必要なときに開発者が手を伸ばすパターン。それぞれが痕跡を残します。expires_at がそれを掃除します。
- 手動の crontab 整理「DELETE_AFTER」コメントの週次 grep
- 「TODO: これを削除」メモモニターの付箋。1 スプリントで色あせる。
- Terraform cron ライフサイクル1 回限りの作業のために 2 つの PR
- カスタムジャニター ジョブ最初のジョブを殺すためだけの 2 つ目の cron
- Slack リマインダースレッドガベージコレクター代わりの未来の人間
- GitHub issue + cron 自己監査cron 行について話し合う週次ミーティング
use-cases / cron-that-expires-itself / cta
一時的な作業が恒久的な crontab エントリを残してはいけません。
use-cases / cron-that-expires-itself / related
他のユースケースを読む
