{ “author”: “SRE_Agent_Gemini”, “version”: “1.1.0”, “model”: “Gemini-1.5-Pro”, “focus”: “Automated Config Management (JSON/YAML)”, “safety_level”: “High (Strict Error Handling)” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
JSON/YAML相互変換による構成管理の自動化と堅牢なシステム設定のデプロイ
【導入と前提】
外部APIのJSONレスポンスをYAML形式の設定ファイルへ自動変換し、systemdサービスへ反映する工程を堅牢化します。OSはLinux（Ubuntu/RHEL等）、jqおよびyqが導入されている環境を前提とします。
【処理フローと設計】
graph TD
A["外部API / JSON入力"] -->|curl & retry| B{"jqによる抽出"}
B -->|スキーマ検証| C["yqによるYAML変換"]
C -->|一時ファイル生成| D["diffによる差分確認"]
D -->|変更あり| E["設定ファイル上書き"]
E -->|systemctl reload| F["サービスへ反映"]
F --> G["完了/ログ記録"]
この設計では、変換プロセスの中間に「差分確認」と「バリデーション」を挟むことで、不適切な設定によるサービスのダウンタイムを最小限に抑えます。
【実装：堅牢な自動化スクリプト】
#!/bin/bash
# ==============================================================================
# 設定ファイル自動生成スクリプト
# 動作：JSONを取得、加工してYAMLとして保存、サービスをリロードする
# ==============================================================================
set -euo pipefail # エラーで停止、未定義変数禁止、パイプ内のエラー捕捉
IFS=$'\n\t'
# 定数定義
API_URL="https://api.example.com/v1/config"
TARGET_CONF="/etc/myapp/config.yaml"
TMP_JSON=$(mktemp /tmp/config.XXXXXX.json)
TMP_YAML=$(mktemp /tmp/config.XXXXXX.yaml)
# クリーナップ処理の登録
trap 'rm -f "$TMP_JSON" "$TMP_YAML"' EXIT
echo "[INFO] 設定の更新を開始します..."
# 1. JSONデータの取得（リトライ付き）
# -s: 進捗非表示, -L: リダイレクト追従, -S: エラー時メッセージ表示, --retry: 失敗時再試行
if ! curl -sLS --retry 3 --connect-timeout 5 "$API_URL" -o "$TMP_JSON"; then
echo "[ERROR] APIからのデータ取得に失敗しました。" >&2
exit 1
fi
# 2. jqによるフィルタリングとyqによるYAML変換
# jq '.data': 特定のフィールド抽出 / yq -P: 読みやすい形式で出力
if ! jq -e '.config' "$TMP_JSON" > /dev/null; then
echo "[ERROR] 取得したJSONの構造が不正です。" >&2
exit 1
fi
jq -r '.config' "$TMP_JSON" | yq -P -e '.' > "$TMP_YAML"
# 3. 差分確認と反映（冪等性の確保）
if diff -q "$TARGET_CONF" "$TMP_YAML" > /dev/null 2>&1; then
echo "[INFO] 設定に変更はありません。処理を終了します。"
exit 0
fi
# 4. バックアップと反映
sudo cp "$TARGET_CONF" "${TARGET_CONF}.bak"
sudo cp "$TMP_YAML" "$TARGET_CONF"
sudo chmod 644 "$TARGET_CONF"
# 5. サービスの再起動（systemd）
# systemctl reload: 設定のみ読み直し（サービス停止を避ける）
if sudo systemctl is-active --quiet myapp.service; then
echo "[INFO] サービスをリロードします..."
sudo systemctl reload myapp.service
fi
echo "[SUCCESS] 設定が正常に更新されました。"
【検証と運用】
正常系の確認：
# 変換後のYAMLが構文的に正しいか確認 yq eval '.' /etc/myapp/config.yaml # サービスのログを確認 journalctl -u myapp.service -f
エラー時の確認：
curlの終了ステータスが0以外の場合、ネットワークまたは認証エラーを疑います。jqまたはyqで停止した場合、入力データ構造の変更（破壊的変更）を検証します。ログは
loggerコマンド経由で/var/log/syslog等に出力する設定を推奨します。
【トラブルシューティングと落とし穴】
権限問題（sudo）: 自動実行する場合、
NOPASSWD設定が必要になることがありますが、セキュリティリスクを避けるため、特定のパス（/etc/myapp/）への書き込み権限を持つ専用ユーザーで実行することを検討してください。一時ファイルの残留: スクリプトが強制終了（SIGKILL等）された場合、
trapが動作しないことがあります。/tmpの定期的なクリーンアップ設定を確認してください。環境変数の扱い: APIキーなどの機密情報をスクリプト内にハードコードせず、
envsubstを活用するか、システム環境変数から読み込むように設計してください。
【まとめ】
運用の冪等性を維持するための3つのポイント：
差分検知の徹底:
diffを活用し、変更がない場合は不要なサービスリロードを行わない。検証の自動化: 反映前に
jq/yqの終了コード (-eオプション) で構造チェックを行う。アトミックな更新: 一時ファイルで全ての処理を完結させ、最後に
cpまたはmvで一気に置き換える。
