本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
systemdサービスユニットファイルの作成と管理:DevOpsベストプラクティス
はじめに
Linuxシステムにおけるサービス管理のデファクトスタンダードであるsystemdは、堅牢なアプリケーション運用に不可欠です。本記事では、DevOpsエンジニアとしてsystemdサービスユニットおよびタイマーユニットの作成と管理を、セキュリティ、冪等性、そして効率性を考慮したベストプラクティスに基づいて解説します。安全なシェルスクリプトの書き方、curlとjqを用いた外部連携、そしてroot権限の適切な扱いについても深掘りします。
要件と前提
目的
任意のアプリケーションをsystemdサービスとして登録し、自動起動・監視可能にする。
定期実行タスクをsystemdタイマーで管理する。
サービスデプロイプロセスを冪等なシェルスクリプトで自動化する。
実行時のセキュリティを強化し、権限分離を徹底する。
前提条件
systemdが動作するLinux環境(例: CentOS, Ubuntu, Fedoraなど)。
Bashシェルおよび基本的なLinuxコマンドの知識。
curl,jq,systemctl,journalctlコマンドが利用可能であること。root権限での操作が必要な箇所があることを理解していること。
セキュリティと権限分離の基本原則
systemdサービスは多くの場合、システム起動時にroot権限で実行されますが、アプリケーション本体は可能な限り非特権ユーザーで動作させるべきです。これにより、万が一アプリケーションに脆弱性があった場合でも、システム全体への影響を最小限に抑えることができます。具体的には、以下の原則に従います。
最小権限の原則: サービスは必要最低限の権限のみを持つユーザー/グループで実行する。
ファイルシステム保護:
ProtectSystem,ProtectHome,PrivateTmpなどのディレクティブで、サービスからアクセス可能なファイルシステム領域を制限する。権限昇格の禁止:
NoNewPrivileges,CapabilityBoundingSetなどで、サービスが新たな特権を取得するのを防ぐ。環境分離: サービス固有の実行環境を構築し、システム全体の環境に影響を与えないようにする。
実装
systemdサービスをデプロイする一般的なフローは以下の通りです。
graph TD
A["サービス定義とスクリプトの作成"] --> B{"冪等なセットアップスクリプト"};
B --> C["アプリバイナリ/設定のダウンロード/配置"];
C --> D["systemdユニットファイルの作成/配置"];
D --> E["systemctl daemon-reload|ユニット設定を再読み込み|"];
E --> F["systemctl enable --now my-app.service|サービスの有効化と起動|"];
F --> G["systemctl status my-app.service|サービスの状態確認|"];
G --> H["ログ確認: journalctl -u my-app.service|標準出力/エラーを確認|"];
H --> I["サービス正常稼働"];
サービス対象アプリケーションの準備
今回は、my-appという架空のGo言語製HTTPサーバーを例に、これをsystemdで管理します。アプリケーションバイナリは /usr/local/bin/my-app に、設定ファイルは /etc/my-app/config.json に配置すると仮定します。
冪等なセットアップスクリプトの作成
デプロイプロセスは、複数回実行しても同じ結果になる「冪等性」を持つべきです。また、シェルスクリプトはエラー耐性を高めるために安全な書き方を採用します。
安全なシェルスクリプトの原則
set -euo pipefail:-e: エラーが発生したら即座にスクリプトを終了。-u: 未定義の変数を使用したらエラー。-o pipefail: パイプライン中のコマンドが一つでも失敗したらパイプライン全体を失敗とする。
trap: スクリプト終了時にクリーンアップ処理を実行する。mktemp -d: 一時ファイルを安全な方法で作成する。
一時ディレクトリの利用とクリーンアップ
#!/bin/bash
# file: setup.sh
# ----------------------------------------------------
# 安全なシェルスクリプトのヘッダ
# ----------------------------------------------------
set -euo pipefail
# 一時ディレクトリの作成
TMP_DIR=$(mktemp -d -t my-app-deploy-XXXXXX)
# スクリプト終了時に一時ディレクトリを自動削除
trap 'rm -rf "$TMP_DIR"' EXIT HUP INT QUIT TERM
# ログファイル名(JST基準の具体日付 2024年05月15日 を使用)
LOG_FILE="/var/log/my-app-setup_$(date +%Y%m%d_%H%M%S).log"
# 標準出力と標準エラー出力をログファイルとコンソールにリダイレクト
exec > >(tee -a "$LOG_FILE") 2>&1
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 🚀 my-app サービスセットアップ開始..."
echo "一時ディレクトリ: $TMP_DIR"
# ----------------------------------------------------
# root権限の確認と非特権ユーザーの準備
# ----------------------------------------------------
if [[ "$(id -u)" -ne 0 ]]; then
echo "エラー: このスクリプトはroot権限で実行する必要があります。" >&2
exit 1
fi
APP_USER="my-app-user"
APP_GROUP="my-app-group"
# ユーザーとグループが存在しない場合のみ作成 (冪等性)
if ! id "$APP_USER" &>/dev/null; then
echo "ユーザー $APP_USER を作成中..."
useradd --system --no-create-home --shell /sbin/nologin "$APP_USER"
fi
if ! getent group "$APP_GROUP" &>/dev/null; then
echo "グループ $APP_GROUP を作成中..."
groupadd --system "$APP_GROUP"
fi
# ユーザーをグループに追加 (既に存在しても問題なし)
usermod -a -G "$APP_GROUP" "$APP_USER"
# アプリケーションディレクトリの準備 (冪等性)
APP_DIR="/usr/local/bin"
CONFIG_DIR="/etc/my-app"
LOG_DIR="/var/log/my-app"
mkdir -p "$APP_DIR" "$CONFIG_DIR" "$LOG_DIR"
chown "$APP_USER:$APP_GROUP" "$CONFIG_DIR" "$LOG_DIR"
chmod 750 "$CONFIG_DIR" "$LOG_DIR"
# ----------------------------------------------------
# curl と jq を用いた外部API連携の例
# ----------------------------------------------------
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] ⚙️ 設定ファイルを取得・生成中..."
# 外部APIから設定情報を取得する例 (ダミーURL)
# --retry: 5回までリトライ
# --retry-delay: リトライ間隔 (秒)
# --retry-max-time: 最大リトライ時間 (秒)
# --cacert: CA証明書を指定してTLS検証を強化
# --show-error: エラー時に詳細を表示
# -f, --fail: サーバーエラー(4xx, 5xx)でも失敗とみなす
# -s, --silent: 進捗表示を抑制
# -S, --show-error: エラー時にはエラーメッセージを表示
CONFIG_JSON_URL="https://api.example.com/v1/config/my-app" # ダミーURL
APP_BIN_URL="https://downloads.example.com/my-app-v1.0.0.tar.gz" # ダミーURL
CA_CERT_PATH="/etc/ssl/certs/ca-certificates.crt" # システムのCA証明書パス
# 設定を取得し、一部をjqで加工
if curl -fsSL --retry 5 --retry-delay 5 --retry-max-time 60 \
--cacert "$CA_CERT_PATH" "$CONFIG_JSON_URL" > "$TMP_DIR/raw_config.json"; then
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 取得した設定を加工中..."
# jqを使用して、設定値の一部をデフォルト値に上書きまたは追加する例
jq '. + { "log_level": "info", "max_connections": 100 }' "$TMP_DIR/raw_config.json" > "$CONFIG_DIR/config.json"
chown "$APP_USER:$APP_GROUP" "$CONFIG_DIR/config.json"
chmod 640 "$CONFIG_DIR/config.json"
else
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 🚨 エラー: 設定ファイルの取得または加工に失敗しました。" >&2
# エラー時はデフォルト設定を使用するなどのフォールバック
echo '{"port": 8080, "log_level": "info", "max_connections": 100}' > "$CONFIG_DIR/config.json"
chown "$APP_USER:$APP_GROUP" "$CONFIG_DIR/config.json"
chmod 640 "$CONFIG_DIR/config.json"
fi
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 📥 アプリケーションバイナリをダウンロード中..."
if curl -fsSL --retry 5 --retry-delay 5 --retry-max-time 60 \
--cacert "$CA_CERT_PATH" "$APP_BIN_URL" | tar -xz -C "$TMP_DIR"; then
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] バイナリを配置中..."
mv "$TMP_DIR/my-app" "$APP_DIR/my-app"
chown "$APP_USER:$APP_GROUP" "$APP_DIR/my-app"
chmod 755 "$APP_DIR/my-app"
else
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 🚨 エラー: アプリケーションバイナリのダウンロードに失敗しました。" >&2
exit 1
fi
# ----------------------------------------------------
# systemdユニットファイルの作成と配置
# ----------------------------------------------------
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 📝 systemdサービスユニットファイルを作成中..."
SERVICE_UNIT_PATH="/etc/systemd/system/my-app.service"
TIMER_UNIT_PATH="/etc/systemd/system/my-app-updater.timer"
UPDATER_SERVICE_UNIT_PATH="/etc/systemd/system/my-app-updater.service"
cat <<EOF > "$SERVICE_UNIT_PATH"
[Unit]
Description=My Application Service
After=network.target
[Service]
ExecStart=/usr/local/bin/my-app -config /etc/my-app/config.json
WorkingDirectory=/usr/local/bin
User=$APP_USER
Group=$APP_GROUP
Restart=on-failure
RestartSec=5s
LimitNOFILE=65536
StandardOutput=journal
StandardError=journal
SyslogIdentifier=my-app
# --- セキュリティ強化ディレクティブ ---
# 新しい特権の取得を禁止
NoNewPrivileges=true
# chrootやmountなどの危険なシステムコールを制限
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_CHOWN CAP_SETUID CAP_SETGID
# /root, /home, /srv, /mediaなどのユーザーディレクトリを保護
ProtectHome=true
# /usr, /boot, /etcへの書き込みを禁止
ProtectSystem=full
# サービス専用の一時ディレクトリ (/tmp, /var/tmp) を提供
PrivateTmp=true
# ファイルシステムの名前空間を分離し、サービスのプロセスから見えるファイルシステムを制限
PrivateDevices=true
# ネットワークインターフェース情報を隠蔽
PrivateNetwork=false # ネットワークアクセスが必要なためfalse
# サービスが実行するプロセスのPID名前空間を分離
PIDFile=/run/my-app.pid # アプリケーションがPIDファイルを生成する場合
# サービスプロセスがアクセスできるリソースを制限
MemoryAccounting=true
CPUAccounting=true
IOAccounting=true
EOF
cat <<EOF > "$UPDATER_SERVICE_UNIT_PATH"
[Unit]
Description=My Application Update Task
Requires=my-app.service
After=my-app.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo 'Running update task...'; /usr/local/bin/my-app --update; echo 'Update task finished.'"
User=$APP_USER
Group=$APP_GROUP
StandardOutput=journal
StandardError=journal
SyslogIdentifier=my-app-updater
# タイマーサービスもセキュリティ強化
NoNewPrivileges=true
ProtectSystem=full
PrivateTmp=true
EOF
cat <<EOF > "$TIMER_UNIT_PATH"
[Unit]
Description=Run My Application Update Task daily
Requires=my-app-updater.service
[Timer]
# 毎日午前3時に実行
OnCalendar=*-*-* 03:00:00
# 起動時に実行されていない場合は、次回のスケジュールで実行
Persistent=true
# 実行精度を1分に設定 (デフォルトは1分)
AccuracySec=1min
[Install]
WantedBy=timers.target
EOF
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] ✅ ユニットファイルの配置が完了しました。"
# ----------------------------------------------------
# systemdデーモンのリロードとサービスの有効化・起動
# ----------------------------------------------------
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 🔄 systemdデーモンをリロード中..."
systemctl daemon-reload
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] 🚀 my-app.service を有効化し、起動中..."
systemctl enable --now my-app.service
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] ⏰ my-app-updater.timer を有効化し、起動中..."
systemctl enable --now my-app-updater.timer
echo "[$ (date +%Y-%m-%d_%H:%M:%S)] ✨ セットアップが完了しました。"
systemd サービスユニットファイルの作成
my-app.service は、アプリケーション本体を実行するためのユニットです。
[Unit] セクション: ユニットの一般的な情報と依存関係を定義します。
Description: ユニットの説明。After: サービスが起動する前に完了しているべきユニットを指定。
[Service] セクション: サービス固有の設定を定義します。
ExecStart: サービス起動時に実行されるコマンド。WorkingDirectory: コマンドが実行されるディレクトリ。User,Group: サービスを実行するユーザーとグループ。root権限を避けるための重要な設定です。Restart: サービス終了時の再起動ポリシー(例:on-failure,always)。RestartSec: 再起動までの待機時間。LimitNOFILE: オープン可能なファイルディスクリプタの最大数。StandardOutput,StandardError: 標準出力と標準エラーの転送先(journalはsystemdジャーナルへ)。セキュリティ強化ディレクティブ:
NoNewPrivileges=true: サービスが新たな特権を取得することを禁止します。CapabilityBoundingSet: プロセスが持つ可能性のあるLinuxケーパビリティ(特権)を制限します。例:CAP_NET_BIND_SERVICEは1024番以下のポートにバインドする権限。ProtectHome=true,ProtectSystem=full:/home,/root、/usr,/etcなどへのアクセスを制限し、ファイルシステムを保護します。PrivateTmp=true: サービス専用の一時ディレクトリ (/tmp,/var/tmp) を提供し、システム全体の一時ファイルへのアクセスを防ぎます。PrivateDevices=true: サービスがデバイスファイルにアクセスするのを防ぎます。PIDFile: アプリケーションがPIDファイルを生成する場合に指定します。systemdがPIDを管理します。
[Install] セクション: ユニットの有効化(systemctl enable)に関する情報を定義します。
WantedBy: このユニットを有効化した際に、どのターゲットユニットにシンボリックリンクが張られるかを指定します。multi-user.targetは通常システム起動時のターゲットです。
systemd タイマーユニットファイルの作成
my-app-updater.timer は定期的なタスクを実行するためのユニットです。
my-app-updater.serviceはタイマーによって起動される実際のタスクを定義します。
[Timer] セクション: タイマー固有の設定を定義します。
OnCalendar: タイマーがアクティブになる日時を指定します。Cron形式に似ています。Persistent=true: systemdの起動中に実行されなかったイベントがある場合、そのイベントがすぐに実行されます。
検証
セットアップスクリプト実行後、以下のコマンドでサービスの状態を確認します。
サービスユニットの起動と状態確認
systemctl status my-app.service
出力例:
● my-app.service - My Application Service
Loaded: loaded (/etc/systemd/system/my-app.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2024-05-15 10:00:00 JST; 1min 20s ago
Main PID: 1234 (my-app)
Tasks: 6 (limit: 4915)
Memory: 10.5M
CPU: 45ms
CGroup: /system.slice/my-app.service
└─1234 /usr/local/bin/my-app -config /etc/my-app/config.json
Active: active (running) であれば正常に起動しています。
タイマーユニットの起動と状態確認
systemctl status my-app-updater.timer
出力例:
● my-app-updater.timer - Run My Application Update Task daily
Loaded: loaded (/etc/systemd/system/my-app-updater.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2024-05-15 10:00:00 JST; 1min 30s ago
Trigger: Thu 2024-05-16 03:00:00 JST; 16h left
Triggers: ● my-app-updater.service
Active: active (waiting) で、Trigger に次回の実行日時が表示されていれば正常です。
ログの確認
サービスやタイマーの出力を確認するには journalctl を使用します。
journalctl -u my-app.service journalctl -u my-app-updater.service
-f オプションを付けてリアルタイムでログを追うこともできます。
journalctl -u my-app.service -f
運用
サービスの一時停止・再起動
systemctl stop my-app.service # 停止 systemctl start my-app.service # 起動 systemctl restart my-app.service # 再起動
ユニットファイルの更新とリロード
ユニットファイルを変更した場合、systemdに設定を再読み込みさせる必要があります。
systemctl daemon-reload # systemdデーモンに設定ファイルの変更を通知 systemctl restart my-app.service # サービスを再起動して新しい設定を適用
自動起動の管理
システム起動時にサービスが自動的に起動するかどうかを設定します。
systemctl enable my-app.service # 自動起動を有効化 systemctl disable my-app.service # 自動起動を無効化
トラブルシューティング
サービスが起動しない場合
systemctl statusで確認: 最も重要なコマンドです。エラーメッセージ、PID、CGroup情報から手がかりを得ます。journalctl -uでログを確認: アプリケーションが出力するログや、systemd自体のエラーメッセージを確認します。ユニットファイルの構文エラー:
systemctl daemon-reload時にエラーが出力されることがあります。systemd-analyze verify <unit_file>で構文チェックが可能です。
ログからの原因特定
journalctl は非常に強力なツールです。
journalctl -u my-app.service --since "1 hour ago": 過去1時間分のログ。journalctl -u my-app.service -p err..crit: エラー以上の深刻度を持つログのみ表示。journalctl -e -u my-app.service: 最新のログを最後まで表示。
systemd-analyze の活用
systemd-analyze verify my-app.service: ユニットファイルの構文や参照関係をチェックします。systemd-analyze security my-app.service: ユニットファイルのセキュリティ設定を評価し、潜在的な脆弱性を特定します。この機能は、設定したセキュリティ強化ディレクティブが正しく機能しているかを確認するのに役立ちます。
まとめ
systemdサービスユニットとタイマーユニットの作成・管理におけるDevOpsベストプラクティスを解説しました。冪等なシェルスクリプトを用いた安全なデプロイ、curlとjqを活用した設定管理、そしてUserディレクティブやセキュリティ強化ディレクティブによる厳格な権限分離は、堅牢なシステム運用に不可欠です。これらの原則を適用することで、サービスの信頼性とセキュリティを向上させ、トラブルシューティングの効率化にも繋がります。systemdの機能を最大限に活用し、安定したアプリケーション運用を目指しましょう。
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月15日
- 変更まとめの冒頭にあった不要な句読点を修正しました。

