{ “style”: “SRE_standard”, “robustness_level”: “high”, “tools”: [“bash”, “curl”, “jq”, “systemd”] } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
運用事故を防ぐ堅牢なシェルスクリプト設計：setオプションとtrapによる例外処理の自動化
【導入と前提】
本稿では、外部APIからのデータ取得と加工を例に、異常終了時でもシステムへの副作用を最小限に抑える堅牢なシェルスクリプトの設計手法を解説します。
実行環境: Linux (Bash 4.4以降推奨)
必須ツール:
curl(API通信用),jq(JSON解析用)前提: インターネット接続および一時書き込み権限のあるディレクトリの存在。
【処理フローと設計】
graph TD
A["スクリプト開始"] --> B["シェルオプション設定: set -euo pipefail"]
B --> C["終了時処理の登録: trap"]
C --> D["一時ディレクトリ作成"]
D --> E["APIリクエスト: curl"]
E --> F{"レスポンス確認"}
F -->|成功| G["データ加工: jq"]
F -->|失敗| H["エラーログ出力"]
G --> I["最終成果物保存"]
H --> J["終了処理: trap実行"]
I --> J
J --> K["スクリプト終了"]
シェルスクリプトの「予期せぬ継続」を防ぐため、開始直後に厳格な実行モードを設定し、trap によって終了時の状態に関わらずクリーンアップを保証する設計をとります。
【実装：堅牢な自動化スクリプト】
#!/usr/bin/env bash
# --- 堅牢化設定 ---
# -e: コマンドが失敗した時点で中断
# -u: 未定義変数の参照時にエラー
# -o pipefail: パイプライン途中のエラーも検知
set -euo pipefail
# --- グローバル設定 ---
readonly API_URL="https://api.github.com/zen"
readonly WORK_DIR=$(mktemp -d)
readonly LOG_FILE="/tmp/operation.log"
# --- 終了処理 (trap) ---
# スクリプトが終了(EXIT)する際に、成功・失敗問わず実行される
cleanup() {
local exit_status=$?
echo "[INFO] Cleaning up temporary directory: ${WORK_DIR}"
rm -rf "${WORK_DIR}"
echo "[INFO] Process finished with status: ${exit_status}"
}
trap cleanup EXIT
# --- メイン処理 ---
log() {
echo "[$(date +'%Y-%m-%dT%H:%M:%S%z')] $1" | tee -a "${LOG_FILE}"
}
fetch_data() {
log "Starting API request..."
# curlオプション:
# -f: HTTPエラー(4xx/5xx)時に異常終了させる
# -s: 進捗を表示しない(静音)
# -S: -s使用時もエラーは表示する
# -L: リダイレクトを追跡する
# --retry: 通信失敗時のリトライ回数
local response
response=$(curl -fsSL --retry 3 "${API_URL}" -o "${WORK_DIR}/data.txt") || {
log "ERROR: API request failed."
return 1
}
log "Data saved to ${WORK_DIR}/data.txt"
}
process_data() {
log "Processing data with jq..."
# jq -e: 抽出結果がnullまたはfalseの場合に終了ステータス1を返す
# ここでは例としてダミーのJSON処理をシミュレート
echo '{"status": "ok", "value": "processed"}' | jq -e '.status' > /dev/null || {
log "ERROR: Invalid JSON structure."
return 1
}
log "Processing complete."
}
# 実行
fetch_data
process_data
log "All tasks completed successfully."
systemd ユニットファイル例（自動実行・再起動設定）
定期実行やサービス化が必要な場合は、systemd を活用してリソース制限とログ管理を行います。
[Unit] Description=Robust API Fetcher After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/fetch_script.sh User=op-user Group=op-group # 環境変数の漏洩防止 EnvironmentFile=-/etc/default/fetch_script # ログはjournaldで一元管理 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
【検証と運用】
正常系の確認:
./fetch_script.sh echo $? # 0が返ることを確認
異常系のシミュレーション:
URLを無効なものに変更し、
set -eにより即座に中断されるか確認。trapによりWORK_DIRが削除されているかlsで確認。
ログの確認:
# systemd経由の場合 journalctl -u fetch_script.service
【トラブルシューティングと落とし穴】
set -eの罠:if文の条件式や||で繋いだコマンドではset -eが効かないため、関数内では明示的なreturn 1が必要です。パイプラインの挙動:
pipefailが有効でないと、curl | jqのような処理でcurlが失敗してもjqが成功すれば全体が成功扱いになってしまいます。環境変数の扱い: スクリプト内に認証情報をハードコードせず、
EnvironmentFileやreadonlyを用いて、意図しない上書きや漏洩を防ぎます。権限の最小化:
sudoをスクリプト内で多用せず、実行ユーザーに必要なディレクトリ権限を事前に付与する設計を優先してください。
【まとめ】
運用の冪等性と堅牢性を維持するための3つのポイント：
失敗を隠さない:
set -euo pipefailで「エラーは即座に止める」を基本とする。後始末を自動化する:
trapを使い、どんな終了条件でも一時ファイルやロックファイルを確実に削除する。外部依存に備える:
curlのリトライ設定やjqの構造チェックにより、外部環境の不確実性をコードで吸収する。
