{ “status”: “stable”, “task”: “robust_shell_scripting”, “tools”: [“bash”, “systemd”, “jq”, “curl”], “design_patterns”: [“fail-fast”, “defensive-programming”, “RAII-like-cleanup”], “sre_focus”: [“reliability”, “idempotency”, “observability”] }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
堅牢なシェルスクリプト設計：set -euo pipefailとtrapによる副作用の最小化
【導入と前提】
本稿では、APIからのデータ取得と加工を伴うシステム運用において、異常発生時に不完全な状態を残さない「堅牢なシェルスクリプト」の設計手法を解説します。
自動化対象: 外部API（JSON）の定期取得とローカル設定ファイルの安全な更新
前提環境: Bash 4.4+, jq 1.6+, curl 7.x, systemd 232+ (GNU/Linux環境)
【処理フローと設計】
graph TD
A["開始: set -euo pipefail"] --> B{"一時ファイル作成"}
B -->|mktemp| C["APIデータ取得: curl"]
C -->|pipe| D["データ加工: jq"]
D --> E{"バリデーション"}
E -->|成功| F["本番反映: atomic mv"]
E -->|失敗| G["EXIT Trap発動"]
G --> H["一時ファイル削除"]
F --> H
H --> I["終了"]
シェルスクリプトのデフォルト挙動は「エラーが起きても続行」ですが、本設計ではset -eによる即時停止とtrapによる確実なクリーンアップを組み合わせています。また、中間ファイルをmktempで作成し、最後にmv（アトミックな移動）を行うことで、処理途中の破損ファイルが参照されるリスクを排除します。
【実装：堅牢な自動化スクリプト】
1. 堅牢なBashスクリプト例 (update_config.sh)
#!/usr/bin/env bash
# -e: エラー発生時に即座に終了
# -u: 未定義変数の参照時にエラー
# -o pipefail: パイプ途中のコマンド失敗を拾う
set -euo pipefail
# ログ出力用関数
log() { echo "[$(date +'%Y-%m-%dT%H:%M:%S%z')] $*"; }
# クリーンアップ関数（終了時に必ず実行）
cleanup() {
local exit_status=$?
if [[ -f "${TMP_FILE:-}" ]]; then
rm -f "$TMP_FILE"
log "Cleanup: Temporary file removed."
fi
if [[ $exit_status -ne 0 ]]; then
log "Error: Script failed with status $exit_status"
fi
}
# EXITシグナルを捕捉してクリーンアップを実行
trap cleanup EXIT
# 変数定義
API_URL="https://api.example.com/v1/config"
DEST_CONF="/etc/app/config.json"
TMP_FILE=$(mktemp /tmp/config_update.XXXXXX)
log "Starting configuration update..."
# APIからJSON取得。curlのオプション:
# -s: 進捗非表示, -S: エラー表示, -f: HTTPエラー(4xx/5xx)で失敗扱い
# jqのオプション:
# -e: 結果がnullやfalseの場合に終了ステータスを1にする
curl -sSfL "$API_URL" | \
jq -e '.settings' > "$TMP_FILE"
# 内容の整合性チェック（例：空でないか）
if [[ ! -s "$TMP_FILE" ]]; then
log "Error: Fetched configuration is empty."
exit 1
fi
# アトミックなファイル置換
# 同一ファイルシステム内であれば、書き込み途中のファイルを読み取られる心配がない
chmod 644 "$TMP_FILE"
mv "$TMP_FILE" "$DEST_CONF"
log "Update completed successfully."
2. systemdによる定期実行設定
スクリプトを安全に自動実行するため、systemdのTimerユニットを活用します。
Serviceファイル (/etc/systemd/system/config-updater.service)
[Unit] Description=Robust Config Updater After=network-online.target [Service] Type=oneshot ExecStart=/usr/local/bin/update_config.sh # 実行ユーザーの制限（最小権限の原則） User=appuser Group=appgroup # 環境変数の保護 Environment="API_TOKEN_FILE=/etc/app/token" [Install] WantedBy=multi-user.target
【検証と運用】
正常系の確認
# スクリプトの手動実行 sudo -u appuser /usr/local/bin/update_config.sh echo $? # 0が返ることを確認 # 反映されたファイルの確認 jq . /etc/app/config.json
異常系の確認（ログ確認）
APIのURLをわざと無効なものに変えるなどしてエラーを誘発させます。
# systemd経由のログ確認 journalctl -u config-updater.service -f
set -o pipefailが効いていれば、curlが404を返した時点でパイプライン全体が失敗し、trapによって一時ファイルが削除される様子がログで確認できます。
【トラブルシューティングと落とし穴】
set -eの過信:if文の条件式やcommand1 || command2のような評価式では-eによる停止が働きません。論理演算を多用する場合は、個別にステータスチェックが必要です。一時ファイルのパーミッション:
mktempで作成されるファイルは通常600です。mvで既存ファイルを上書きする際、読み取り権限（644など）が必要なアプリケーションが参照する場合は、chmodを忘れないようにしてください。環境変数のパス:
systemdやcronで実行する場合、PATHが限定的です。コマンドはフルパスで記述するか、冒頭で明示的にPATHを定義することを推奨します。
【まとめ】
運用の冪等性と堅牢性を維持するための3つのポイント：
Fail-Fast:
set -euo pipefailにより、予期せぬ挙動が発生した瞬間に処理を止める。Atomic Operation: 処理途中のファイルで上書きせず、
mktempとmvを組み合わせて「完全か無か（All or Nothing）」を実現する。Visibility:
trapを利用して終了ステータスやクリーンアップ状況をログに残し、オブザーバビリティを確保する。
