こんにちは、代表の片ケ瀬です。
インフラ歴25年、
今回は、「やってはいけないけど、みんなやったことある」アレです。
インフラ歴25年、
/etc/crontabと戦って四半世紀。今回は、「やってはいけないけど、みんなやったことある」アレです。
😈 cronに全部書いた、その瞬間に未来が死ぬ
0 2 * * * /usr/bin/mysql -uadmin -pp@ssw0rd -e "DELETE FROM logs WHERE timestamp < NOW() - INTERVAL 30 DAY" && systemctl restart nginx💀 RIP：将来の保守担当者（おそらく自分）
- 一行で完結しててパッと見わかりやすい風
- でも失敗しても何も記録されない
- 右端で何やってるか読めない
- 再利用もデバッグも地獄
🔍 どこがそんなに罪なのか？
| 問題 | なぜダメ？ |
|---|---|
| コマンドが長い | パース不能。壊すのも一瞬。 |
| ログを吐かない | 成功か失敗か誰も気づかない。 |
| 並列タスクが怖い | &&で片方だけ失敗しても気づけない。 |
| 保守性ゼロ | 自分ですら半年後に読めない。 |
🛠 令和のインフラは“責任を分ける”のが基本
cronは「起動する人」くらいにとどめましょう。
✅ 正しいcron構成
0 2 * * * /opt/scripts/clean_and_restart.sh >> /var/log/cron/clean.log 2>&1🧾 /opt/scripts/clean_and_restart.sh
#!/bin/bash
LOG=/var/log/cron/clean_and_restart.log
echo "=== START $(date) ===" >> $LOG
mysql --defaults-extra-file=/etc/mysql/secure.cnf <> $LOG
ポイント：
- cronは「いつ・何を起動するか」だけを記述
- 処理ロジックは別スクリプトで保守性UP
- ログ出力で障害検知が容易に
✨ cronを卒業する道もある
- systemd timer → journalctlでログ管理・依存関係制御OK
- CI/CD系ツール（Jenkins / GitHub Actions） → ステップ化・通知・再実行可
- AWS EventBridge + Lambda → サーバレス化して軽量運用
🎭 cronに全部書いてた頃の自分へ
「これでいいや」は、
「後で死ね」の略じゃないか？
📌 まとめ：cronは“起動ボタン”、ロジックは外に
| 原則 | 理由 |
|---|---|
| cronに処理は書かない | 見えない、読めない、壊れやすい |
| スクリプトでロジック管理 | ログとエラー制御ができる |
| 複雑ならsystemdやCI/CDへ | 再現性・保守性・透明性が向上 |
🗃 おまけ：昔の俺が書いたcronワースト3（実話）
- 1行だけ改行忘れて2ジョブが混ざる地獄
/tmp/hoge.shが消えてて実行0バイト（半年）- 平文パスワード付きmysqlコマンドをgitにコミット
🔮 次回予告：「レガシー＝悪」って誰が言った？
次回は、若手に「古くさい」と言われがちな構成の中にある、“設計思想”と“技術の魂”について語ります。
- 「やばい」と言われるレガシー構成にも意味がある
- 止まらないことは、設計の美学
- Terraformもいずれレガシーになる
お楽しみに！
👋 最後にひとこと
「cronに処理を全部書く」それは未来の自分への暗殺未遂です。
スクリプトに逃がし、ログを残し、手順を残そう。それがレガシー・サバイバル術。
コメント