#!/bin/bash


# スクリプト名: process_api_data.sh

# 厳格なエラーハンドリング設定:


# -e: コマンドが失敗した場合、即座にスクリプトを終了する


# -u: 未定義の変数を使用しようとした場合、エラーを出力してスクリプトを終了する


# -o pipefail: パイプライン内でコマンドが失敗した場合、パイプライン全体の終了ステータスをその失敗したコマンドのステータスにする

set -euo pipefail

# 一時ディレクトリの作成とクリーンアップ関数


# スクリプト実行ユーザーのホームディレクトリに一時ファイルを保存し、権限分離を意識する。

cleanup() {
    echo "Cleaning up temporary directory: ${TMP_DIR}"

    # TMP_DIRが存在し、かつディレクトリであることを確認してから削除

    if [[ -d "${TMP_DIR}" ]]; then
        rm -rf "${TMP_DIR}"
    fi
}

# Ctrl+C (INT)、スクリプト終了 (EXIT)、ターミナル終了 (TERM) 時にcleanup関数を呼び出す

trap cleanup EXIT INT TERM

# スクリプト実行ユーザー名を取得

CURRENT_USER=$(whoami)

# 一時ディレクトリをユーザーのホームディレクトリ内に作成


# rootで実行される場合は /var/tmp など、適切なシステム一時ディレクトリを利用すべき

if [[ "${CURRENT_USER}" == "root" ]]; then
    TMP_DIR=$(mktemp -d "/var/tmp/${0##*/}.XXXXXXXXXX")
    OUTPUT_DIR="/var/lib/api_data" # rootで書き込み可能なシステム上の場所
else
    TMP_DIR=$(mktemp -d "${HOME}/.tmp/${0##*/}.XXXXXXXXXX")
    OUTPUT_DIR="${HOME}/api_data" # ユーザーのホームディレクトリ内の場所
fi

# 出力ディレクトリが存在しない場合は作成

mkdir -p "${OUTPUT_DIR}"

echo "Temporary directory: ${TMP_DIR}"
echo "Output directory: ${OUTPUT_DIR}"

# 実行ユーザーの権限確認と警告


# root権限での実行は可能な限り避けるべき。必要な場合にのみ使用し、権限を厳しく管理する。

if [[ "${EUID}" -eq 0 ]]; then
    echo "WARNING: This script is running as root. Ensure necessary precautions are taken for root operations." >&2
    echo "Consider running this script as a less privileged user if possible." >&2

    # rootでしか実行できない場合はここで処理を継続するが、そうでなければexitしても良い

fi

# ここから主要処理


# ...

# ... (前述のスクリプトフレームワークの続き)

API_ENDPOINT="https://api.example.com/v1/data"

# 出力ファイル名にJSTの現在日時を含める

OUTPUT_FILE="${OUTPUT_DIR}/api_data_$(date +%Y%m%d%H%M%S).json"
CURL_LOG="${TMP_DIR}/curl.log"

# CA証明書のパス (多くのLinuxディストリビューションで標準)


# 環境に合わせて調整してください (例: Ubuntu/Debian: /etc/ssl/certs/ca-certificates.crt, RHEL/CentOS: /etc/pki/tls/certs/ca-bundle.crt)

CA_CERT_PATH="/etc/ssl/certs/ca-certificates.crt"

echo "Fetching data from ${API_ENDPOINT}..."

# curlコマンドのオプション:


# -sS: サイレントモード (-s) かつエラー表示 (-S)


# --retry 5: 最大5回再試行する


# --retry-delay 5: 最初の再試行まで5秒待機し、以降は指数バックオフ (5s, 10s, 20s...)


# --retry-max-time 60: 再試行を含めた最大実行時間60秒


# --cacert: CA証明書を指定してTLS検証を行う。サーバ証明書の検証に利用。


# --output: ダウンロードしたデータを指定した一時ファイルに出力


# --fail: HTTPエラー (4xx/5xx) があった場合、終了ステータスを非ゼロにする


# --show-error: エラー発生時にエラーメッセージを表示

if ! curl -sS \
    --retry 5 \
    --retry-delay 5 \
    --retry-max-time 60 \
    --cacert "${CA_CERT_PATH}" \
    --output "${TMP_DIR}/raw_data.json" \
    --fail \
    --show-error \
    "${API_ENDPOINT}" 2> "${CURL_LOG}"; then
    echo "ERROR: Failed to fetch data from API. See ${CURL_LOG} for details." >&2
    cat "${CURL_LOG}" >&2 # エラーログの内容を標準エラー出力にも表示
    exit 1
fi

echo "Raw data saved to ${TMP_DIR}/raw_data.json"

# ... (jqでの処理に続く)

# ... (curlでのデータ取得の続き)

FILTERED_DATA_FILE="${TMP_DIR}/filtered_data.json"

echo "Filtering and transforming data with jq..."

# jqコマンドのオプションとフィルタリングロジック:


# -c: 圧縮出力 (各JSONオブジェクトが1行に出力される)


# .items[]: トップレベルの`items`配列を展開し、個別の要素をストリームとして扱う


# select(.status == "active"): 各要素の中から`status`フィールドが"active"であるオブジェクトを選択


# {id, value}: 選択されたオブジェクトから`id`と`value`のフィールドを持つ新しいオブジェクトを作成


# [ ... ] は配列としてまとめるが、ここではパイプで個別のオブジェクトを流しているため、結果は行区切りのJSONオブジェクトのストリームとなる。


# 配列として出力する場合は `[ .items[] | select(.status == "active") | {id, value} ]` と記述する。

if ! jq -c '.items[] | select(.status == "active") | {id, value}' "${TMP_DIR}/raw_data.json" > "${FILTERED_DATA_FILE}"; then
    echo "ERROR: jq processing failed. Check JSON format or jq filter syntax." >&2
    exit 1
fi

echo "Filtered data saved to ${FILTERED_DATA_FILE}"

# 最終的な出力ファイルを一時ディレクトリから永続的な出力ディレクトリへ移動


# mvコマンドはアトミックな操作であり、ファイルの上書き中に読み取り側で不完全なファイルが見えるリスクを軽減する

mv "${FILTERED_DATA_FILE}" "${OUTPUT_FILE}"
echo "Final processed data moved to ${OUTPUT_FILE}"

# ... (スクリプトの終わり)

[Unit]
Description=API Data Processor Service
After=network-online.target # ネットワークが利用可能になってから起動を試みる

[Service]
Type=oneshot # 一度実行して終了するサービスタイプ
User=appuser # スクリプトを実行する非特権ユーザー
Group=appuser # スクリプトを実行する非特権グループ
WorkingDirectory=/opt/api-processor # スクリプトの作業ディレクトリ (例: スクリプト本体が配置される場所)
ExecStart=/opt/api-processor/process_api_data.sh # スクリプトのフルパス
StandardOutput=journal # 標準出力をsystemdジャーナルに記録
StandardError=journal # 標準エラー出力をsystemdジャーナルに記録
Restart=on-failure # サービスが失敗した場合でも再起動しない (oneshotのため)

# 環境変数が必要な場合は Environment=KEY=VALUE の形式で指定。機密情報は環境変数ではなく、Secrets Managerなどを利用すべき。

[Install]
WantedBy=multi-user.target

[Unit]
Description=Run API Data Processor daily at 3 AM
RefuseManualStart=no # systemctl start コマンドでの手動起動を許可
RefuseManualStop=no  # systemctl stop コマンドでの手動停止を許可

[Timer]
OnCalendar=*-*-* 03:00:00 # 毎日午前3時00分00秒に起動
Persistent=true # タイマーが非アクティブな間に発生したイベントも、次にアクティブになったときに実行する
Unit=api-data-processor.service # このタイマーが起動するサービスユニットの名前

[Install]
WantedBy=timers.target

# スクリプトを適切なディレクトリに配置 (例: /opt/api-processor/)


# スクリプトに実行権限を付与

sudo chmod +x /opt/api-processor/process_api_data.sh

# 非特権ユーザー (例: appuser) でテスト実行


# appuserユーザーが事前に作成され、/opt/api-processor/ ディレクトリへの読み取り・実行権限を持っていること

sudo -u appuser /opt/api-processor/process_api_data.sh

# スクリプト実行後、出力ファイルの確認


# appuserのホームディレクトリ下のapi_dataディレクトリにファイルが生成される想定

ls -l /home/appuser/api_data/
cat /home/appuser/api_data/api_data_*.json

# systemd設定をリロードして新しいユニットファイルを認識させる

sudo systemctl daemon-reload

# タイマーユニットを有効化し、起動

sudo systemctl enable api-data-processor.timer
sudo systemctl start api-data-processor.timer

# タイマーの状態を確認: 次の実行時刻などが表示される

sudo systemctl list-timers | grep api-data-processor

# サービスユニットの手動起動（テスト目的。タイマーが動作する前に実行確認）

sudo systemctl start api-data-processor.service

# ログの確認: サービスユニットの標準出力/エラー出力がジャーナルに記録されている


# --sinceオプションには、JSTの具体日付と時刻を指定

sudo journalctl -u api-data-processor.service --since "{{jst_today}} 00:00:00" -f