systemdユニットファイルによるサービス依存制御の強化

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

systemdユニットファイルによるサービス依存制御の強化

現代のLinuxシステムにおいて、サービス管理のデファクトスタンダードであるsystemdは、単にサービスを起動・停止するだけでなく、複雑なサービス間の依存関係を効果的に制御する強力な機能を提供します。本記事では、systemdユニットファイルを用いたサービス依存制御の基本から応用、堅牢なスクリプトの実装、そしてセキュリティ上の考慮事項まで、DevOpsエンジニアが知っておくべき実践的な知識を解説します。

要件と前提

このガイドを実践するための要件と前提は以下の通りです。

  • Linux環境: systemdが稼働しているLinuxディストリビューション（例: CentOS, Ubuntu, Debianなど）。

  • 権限: systemdユニットファイルの配置と管理にはroot権限が必要です。

  • コマンド: bash, systemctl, journalctl, curl, jqがインストールされていること。

  • 堅牢なスクリプト: 実行スクリプトは、エラー処理、一時ファイルの安全な管理、冪等性を考慮して記述します。

  • 具体的な日付表記: 記事内の日付はすべて日本標準時（JST）の具体的な日付（例: 2024年07月30日）で記述します。

実装

サービス依存制御の基本

systemdユニットファイルは、[Unit], [Service], [Install]の3つの主要なセクションで構成されます。サービス間の依存関係は主に[Unit]セクションで定義されます。

依存関係の種類

ディレクティブ 説明
Wants= ソフトな依存関係: 指定されたユニットを起動しようとしますが、そのユニットが失敗しても現在のユニットの起動には影響しません。
Requires= ハードな依存関係: 指定されたユニットが起動されることを要求します。依存先のユニットが失敗すると、現在のユニットも停止します。
After= 起動順序の依存関係: 現在のユニットは、指定されたユニットが起動した後でなければ起動しません。ただし、Wants=やRequires=がない場合、依存先のユニットが起動される保証はありません。
Before= 起動順序の依存関係: 現在のユニットは、指定されたユニットが起動する前に起動する必要があります。
PartOf= グループ化: 指定されたユニットの一部として扱われます。依存先のユニットが停止または再起動されると、現在のユニットも停止または再起動されます。
Conflicts= 排他性: 指定されたユニットと同時に実行できません。現在のユニットが起動されると、指定されたユニットは停止されます。逆もまた然りです。

これらのディレクティブは、複数のユニットをスペース区切りで指定できます。

実装例: 複数サービスの連携

ここでは、データ準備サービス、コアロジックサービス、外部API通知サービスの3つのサービスを連携させる例を示します。

graph TD
    subgraph サービス連携フロー
        A["データ準備サービス"] --> |Wants/After| B("コアビジネスロジックサービス");
        B --> |Requires/After| C("外部API連携サービス");
    end

1. データ準備サービス (/etc/systemd/system/example-data-prep.service)

このサービスは、コアロジックサービスが利用するデータを準備します。単独で起動可能ですが、コアロジックサービスに「希望される」存在として定義します。

[Unit]
Description=Example Data Preparation Service
Documentation=https://example.com/data-prep
After=network.target

[Service]
Type=simple
User=example_user
Group=example_user
ExecStart=/usr/local/bin/prepare_data.sh
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

/usr/local/bin/prepare_data.sh

#!/bin/bash


# systemdユニットファイルから実行されるデータ準備スクリプト

# 堅牢なシェルスクリプトの基本設定

set -euo pipefail

# スクリプト実行中にエラーが発生した場合、直ちに終了する


# 未定義の変数を使用した場合、エラーとして扱う


# パイプライン内で一つでも失敗したコマンドがあれば、パイプライン全体を失敗とする

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

tmpdir=$(mktemp -d -t data-prep-XXXXXXXX)
trap 'rm -rf "$tmpdir"' EXIT # スクリプト終了時に一時ディレクトリを削除

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): データ準備サービスを開始します..." >&2

# 模擬的なデータ準備処理


# 例えば、DBからデータを取得し、整形してファイルに保存

prepared_data_path="${tmpdir}/prepared_data.json"
echo '{"status": "prepared", "timestamp": "'$(date +%s)'", "data_count": 100}' > "$prepared_data_path"

if [ ! -f "$prepared_data_path" ]; then
    echo "エラー: データ準備ファイルが見つかりません。" >&2
    exit 1
fi

# 準備したデータを永続的な場所へコピー（例: /var/lib/example-app/data）

mkdir -p /var/lib/example-app/data
cp "$prepared_data_path" /var/lib/example-app/data/latest_data.json

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): データ準備が完了しました。ファイル: /var/lib/example-app/data/latest_data.json" >&2
exit 0

注意: /var/lib/example-app/data ディレクトリの作成と、example_user が書き込み可能であることを確認してください。

2. コアビジネスロジックサービス (/etc/systemd/system/example-core-logic.service)

このサービスは、データ準備サービスが提供するデータに依存します。データ準備サービスが正常に完了した後にのみ起動するようにAfter=とWants=を設定します。

[Unit]
Description=Example Core Business Logic Service
Documentation=https://example.com/core-logic
Wants=example-data-prep.service # データ準備サービスを希望する
After=example-data-prep.service # データ準備サービスの後で起動する
After=network.target

[Service]
Type=simple
User=example_user
Group=example_user
ExecStart=/usr/local/bin/run_core_logic.sh
Restart=on-failure
RestartSec=10s

[Install]
WantedBy=multi-user.target

/usr/local/bin/run_core_logic.sh

#!/bin/bash

set -euo pipefail
tmpdir=$(mktemp -d -t core-logic-XXXXXXXX)
trap 'rm -rf "$tmpdir"' EXIT

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): コアビジネスロジックサービスを開始します..." >&2

# データ準備サービスが提供したデータを使用

DATA_FILE="/var/lib/example-app/data/latest_data.json"

if [ ! -f "$DATA_FILE" ]; then
    echo "エラー: データファイルが見つかりません: $DATA_FILE" >&2
    exit 1
fi

DATA_STATUS=$(jq -r '.status' "$DATA_FILE")
DATA_COUNT=$(jq -r '.data_count' "$DATA_FILE")

echo "準備されたデータのステータス: $DATA_STATUS, データ数: $DATA_COUNT" >&2

# 模擬的なコアロジック処理


# 例えば、準備されたデータに基づいて計算を実行

processed_result_path="${tmpdir}/processed_result.json"
echo '{"operation": "completed", "result_count": '"$DATA_COUNT"'}' > "$processed_result_path"

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): コアビジネスロジック処理が完了しました。" >&2
exit 0

3. 外部API連携サービス (/etc/systemd/system/example-api-notify.service)

このサービスは、コアロジックサービスが正常に動作していることを必須とします。したがって、Requires=とAfter=を使用します。また、curlとjqを使った外部API連携の例を含めます。

[Unit]
Description=Example External API Notification Service
Documentation=https://example.com/api-notify
Requires=example-core-logic.service # コアロジックサービスが必須
After=example-core-logic.service    # コアロジックサービスの後で起動する
After=network.target

[Service]
Type=simple
User=example_user
Group=example_user
ExecStart=/usr/local/bin/call_api.sh
Restart=on-failure
RestartSec=15s

[Install]
WantedBy=multi-user.target

/usr/local/bin/call_api.sh

#!/bin/bash

set -euo pipefail
tmpdir=$(mktemp -d -t api-notify-XXXXXXXX)
trap 'rm -rf "$tmpdir"' EXIT

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): 外部API連携サービスを開始します..." >&2

API_URL="https://httpbin.org/post" # テスト用のダミーAPIエンドポイント
MAX_RETRIES=5
RETRY_DELAY_BASE=1 # 秒
API_KEY="your_api_key_if_needed" # 実際の運用では環境変数やSecret Managerを使用

# コアロジックサービスから得られるであろう情報を取得

CORE_LOGIC_DATA="/var/lib/example-app/data/latest_data.json"
if [ -f "$CORE_LOGIC_DATA" ]; then
    APP_STATUS=$(jq -r '.status' "$CORE_LOGIC_DATA")
else
    APP_STATUS="unknown"
fi

PAYLOAD=$(jq -n \
    --arg status "$APP_STATUS" \
    --arg timestamp "$(date '+%Y-%m-%dT%H:%M:%SZ')" \
    '{ "event": "service_status_update", "status": $status, "timestamp": $timestamp }')

echo "APIへ送信するペイロード: $PAYLOAD" >&2

for i in $(seq 1 $MAX_RETRIES); do
    echo "$(date '+%Y-%m-%d %H:%M:%S JST'): API呼び出しを試行中... (試行 $i/$MAX_RETRIES)" >&2

    # curlの堅牢な設定


    # -sS: エラー時のみ表示、進捗状況非表示


    # -X POST: HTTP POSTメソッド


    # -H "Content-Type: application/json": ヘッダー設定


    # -H "Authorization: Bearer $API_KEY": 認証ヘッダー（必要に応じて）


    # --data-raw "$PAYLOAD": 生のPOSTデータ


    # --output "$tmpdir/curl_response.json": レスポンスをファイルに保存


    # --connect-timeout 10: 接続タイムアウト10秒


    # --max-time 30: 全体の処理タイムアウト30秒


    # --fail: 400以上のHTTPステータスコードの場合、エラー終了


    # --tlsv1.2: TLSv1.2以降を使用

    if curl -sS -X POST \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer $API_KEY" \
            --data-raw "$PAYLOAD" \
            --output "$tmpdir/curl_response.json" \
            --connect-timeout 10 \
            --max-time 30 \
            --fail \
            --tlsv1.2 \
            "$API_URL"; then
        echo "$(date '+%Y-%m-%d %H:%M:%S JST'): API呼び出しが成功しました。" >&2
        jq '.' "$tmpdir/curl_response.json" >&2 # レスポンスを整形して表示
        exit 0
    else
        CURL_EXIT_CODE=$?
        echo "$(date '+%Y-%m-%d %H:%M:%S JST'): API呼び出しが失敗しました。終了コード: $CURL_EXIT_CODE" >&2
        if [ "$i" -lt "$MAX_RETRIES" ]; then

            # 指数バックオフ

            sleep_time=$((RETRY_DELAY_BASE * (2 ** (i - 1))))
            echo "$(date '+%Y-%m-%d %H:%M:%S JST'): $sleep_time 秒待機してからリトライします..." >&2
            sleep "$sleep_time"
        fi
    fi
done

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): エラー: 最大リトライ回数を超えてもAPI呼び出しが成功しませんでした。" >&2
exit 1

タイマーによる定期実行

systemdタイマーユニット (.timer) は、cronに代わる高機能な定期実行メカニズムを提供します。

1. 定期バッチ実行サービス (/etc/systemd/system/example-batch.service)

このサービスは、タイマーによって定期的に実行されるバッチ処理です。

[Unit]
Description=Example Daily Batch Service
Documentation=https://example.com/batch

# batch.serviceは他のサービスに依存せず、単独で実行される場合が多い


# 必要であれば Wants/After を定義可能

[Service]
Type=oneshot # 一回実行で完了するサービス
User=example_user
Group=example_user
ExecStart=/usr/local/bin/daily_batch.sh

# Type=oneshot の場合、Restart=on-failure は意味をなさないことが多い


# 代わりにスクリプト内でリトライロジックを実装するか、タイマーで再試行を制御

[Install]

# Timerユニットによって起動されるため、WantedBy=は不要

/usr/local/bin/daily_batch.sh

#!/bin/bash

set -euo pipefail
tmpdir=$(mktemp -d -t daily-batch-XXXXXXXX)
trap 'rm -rf "$tmpdir"' EXIT

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): 日次バッチ処理を開始します..." >&2

# 模擬的なバッチ処理


# 例えば、ログファイルのアーカイブやデータベースの最適化など

echo "Processing daily data for $(date '+%Y-%m-%d')." > "$tmpdir/batch_log_$(date '+%Y%m%d').txt"
sleep 2 # 処理に時間がかかることをシミュレート

echo "$(date '+%Y-%m-%d %H:%M:%S JST'): 日次バッチ処理が完了しました。" >&2
exit 0

2. タイマーユニット (/etc/systemd/system/example-batch.timer)

毎日午前3時00分（JST）にexample-batch.serviceを起動するタイマーを設定します。

[Unit]
Description=Runs example daily batch service daily at 3:00 AM
Documentation=https://example.com/batch

# example-batch.serviceを起動することを明示的に記述


# Wants=example-batch.service は暗黙的に適用されるが、明示することで可読性向上

Wants=example-batch.service

[Timer]
OnCalendar=*-*-* 03:00:00 # 毎日午前3時00分に起動
Persistent=true          # タイマー起動がスキップされた場合、起動時に即座に実行する

[Install]
WantedBy=timers.target   # タイマーユニットはtimers.targetによって起動されることを推奨

Root権限の扱いと権限分離

systemdユニットファイル自体は/etc/systemd/system/配下に配置するためroot権限が必要です。しかし、[Service]セクションでUser=およびGroup=ディレクティブを指定することで、サービスプロセスを特定の非rootユーザーとグループで実行できます。これにより、サービスが侵害された場合の影響範囲を最小限に抑え、システム全体のセキュリティを向上させます。

また、systemdは、ProtectSystem=full、ProtectHome=true、NoNewPrivileges=trueなどのサンドボックス関連ディレクティブも提供しており、サービスプロセスの権限をさらに細かく制限できます。

検証

  1. ユニットファイルの配置: 上記で定義した.serviceファイルと.timerファイルを/etc/systemd/system/ディレクトリに配置し、対応するシェルスクリプトを/usr/local/bin/に配置します。シェルスクリプトには実行権限を付与します。

    sudo install -m 755 prepare_data.sh /usr/local/bin/
sudo install -m 755 run_core_logic.sh /usr/local/bin/
sudo install -m 755 call_api.sh /usr/local/bin/
sudo install -m 755 daily_batch.sh /usr/local/bin/

  2. systemd設定のリロード: 新しいユニットファイルを読み込むためにsystemdデーモンをリロードします。

    sudo systemctl daemon-reload

  3. サービスとタイマーの有効化・起動: サービスをシステム起動時に自動起動するように有効化し、手動で起動します。タイマーも有効化します。

    sudo systemctl enable example-data-prep.service
sudo systemctl enable example-core-logic.service
sudo systemctl enable example-api-notify.service
sudo systemctl enable example-batch.timer

sudo systemctl start example-api-notify.service # 依存関係により、全て起動されるはず
sudo systemctl start example-batch.timer

  4. 状態とログの確認: サービスの起動状態とログを確認し、依存関係が正しく機能しているか確認します。

    sudo systemctl status example-api-notify.service
sudo systemctl status example-batch.timer
sudo systemctl status example-batch.service # タイマーによって起動されたか確認

# 全てのサービスのログを時系列で確認

sudo journalctl -u example-data-prep.service -u example-core-logic.service -u example-api-notify.service -u example-batch.service -f

# タイマーの稼働状況を確認

sudo systemctl list-timers --all

    ログには、各スクリプトのecho出力やcurlのレスポンスなどが表示され、サービスが期待通りに連携して動作していることを確認できます。example-api-notify.serviceを起動した際に、そのRequiresとAfterによってexample-core-logic.serviceが起動し、さらにそのWantsとAfterによってexample-data-prep.serviceが順に起動していることを確認してください。

運用

  • ログの集中監視: journalctlはサービスのログを一元的に管理します。ログ転送サービス（Fluentd, Logstashなど）と連携し、集中監視システムで異常を検知できるように設定します。

  • サービス状態の監視: PrometheusやGrafanaのような監視ツールと連携し、systemdサービスの稼働状態やリソース使用率を継続的に監視します。

  • ユニットファイルのバージョン管理: ユニットファイルや実行スクリプトは、Gitなどのバージョン管理システムで管理し、変更履歴を追跡できるようにします。

  • 専用ユーザーの利用: サービスごとに最小限の権限を持つ専用ユーザーを作成し、User=およびGroup=ディレクティブで指定して実行します。これにより、セキュリティリスクを大幅に低減できます。

トラブルシュート

サービスが期待通りに動作しない場合、以下の手順でトラブルシューティングを行います。

  1. 詳細なログの確認:

    sudo journalctl -xeu <service_name>.service

    -xオプションは、関連するコンテキストや説明メッセージを追加表示し、-eはジャーナルの末尾を表示します。

  2. 依存関係の確認:

    systemctl list-dependencies <service_name>.service

    これにより、サービスの依存関係ツリーを確認できます。Wants=、Requires=、After=などの設定が正しいか検証します。

  3. ユニットファイルの構文チェック: systemdは、ユニットファイルに構文エラーがある場合、systemctl statusコマンドでエラーメッセージを表示します。systemctl daemon-reload時にもエラーが表示されることがあります。

  4. スクリプトの直接実行: ExecStartで指定されているスクリプトを、systemd環境に近い形で手動で実行し、エラーが発生するか確認します。特に、環境変数やパスの問題、権限の問題が発見できることがあります。

  5. タイムアウト設定の調整: TimeoutStartSec=やTimeoutStopSec=ディレクティブが短すぎる場合、サービスが起動完了前にsystemdによって強制終了されることがあります。処理が長時間かかる場合は、これらの値を適切に調整してください。

まとめ

systemdユニットファイルは、Linuxサービス管理において非常に強力で柔軟なツールです。Wants=, Requires=, After=といった依存関係ディレクティブを適切に活用することで、複雑なサービスオーケストレーションを確実かつ堅牢に実装できます。また、systemdタイマーはcronに代わる優れた定期実行手段を提供します。

さらに、set -euo pipefailやtrapを用いた堅牢なbashスクリプトの記述、curlとjqによる外部連携の強化、そしてUser=やGroup=による権限分離は、運用中のサービスの安定性とセキュリティを大幅に向上させます。これらのベストプラクティスをDevOpsのワークフローに取り入れることで、より信頼性の高いシステム構築が可能となります。本記事で解説した具体的な日付（2024年07月30日JST）の例を参考に、ご自身のシステムに適用してみてください。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました