Systemd 서비스 생성기
서비스 정보를 입력하면 systemd .service 유닛 파일을 자동으로 생성합니다.
[Unit] 섹션
[Service] 섹션
[Install] 섹션
생성된 서비스 파일 (myapp.service)
# ============================================
# Systemd Service: My Service
# ============================================
[Unit]
Description=My Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/echo 'No command specified'
# Restart Policy
Restart=on-failure
RestartSec=5
# Logging
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target설치 및 실행 명령어
sudo cp myapp.service /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.serviceSystemd 서비스 생성기 — 리눅스 데몬 관리 표준
Systemd는 2010년 Lennart Poettering이 개발한 리눅스 초기화 시스템(init system)이자 서비스 매니저로, Ubuntu 15.04, RHEL 7, Debian 8 이후 사실상 모든 주요 배포판의 PID 1 프로세스입니다. .service 유닛 파일을 작성하면 애플리케이션을 데몬으로 등록하여 부팅 시 자동 시작, 비정상 종료 시 자동 재시작, journald 통합 로깅, cgroup 기반 리소스 제어를 선언적으로 관리할 수 있습니다. 이 도구는 [Unit], [Service], [Install] 섹션을 GUI로 구성하여 표준 서비스 파일을 즉시 생성합니다.
서비스 파일 구조 — 3개 섹션 해설
[Unit] 섹션은 Description(설명), After(의존성 순서),Wants/Requires(의존 서비스)를 정의합니다.[Service] 섹션은 Type(서비스 타입), ExecStart(시작 명령),Restart(재시작 정책), User/Group(실행 사용자),Environment(환경변수) 등 핵심 동작을 선언합니다.[Install] 섹션은 WantedBy=multi-user.target으로 서비스 활성화 시 연결할 타겟을 지정합니다.
Node.js 앱 서비스 파일 예시
[Unit] Description=My Node.js API Server After=network.target [Service] Type=simple User=nodejs Group=nodejs WorkingDirectory=/opt/myapp ExecStart=/usr/bin/node /opt/myapp/server.js Restart=on-failure RestartSec=5 Environment="NODE_ENV=production" Environment="PORT=3000" StandardOutput=journal StandardError=journal NoNewPrivileges=true [Install] WantedBy=multi-user.target
Systemd 타이머 유닛 (cron 대체)
# backup.timer [Unit] Description=Daily Backup Timer [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true [Install] WantedBy=timers.target
서비스 타입별 동작 차이
| Type | 동작 | 사용 사례 |
|---|---|---|
| simple | ExecStart 프로세스가 메인 | Node.js, Python, Go 앱 |
| forking | fork 후 부모 종료 | Apache httpd, 전통적 데몬 |
| oneshot | 한 번 실행 후 종료 | 스크립트, 마이그레이션 |
| notify | sd_notify()로 준비 완료 알림 | PostgreSQL, Nginx |
| idle | 다른 작업 완료 후 실행 | 콘솔 출력 정리 |
규모별 서비스 운영 전략
소규모(단일 서버): systemd 서비스 파일로 앱을 직접 관리합니다.journalctl -u myapp -f로 실시간 로그를 확인하고,Restart=on-failure로 자동 복구합니다.
중규모(3~10대): Ansible Playbook으로 서비스 파일을 배포하고, 환경변수는 EnvironmentFile=/etc/myapp/env로 코드와 분리합니다. Prometheus + node_exporter로 서비스 상태를 모니터링합니다.
대규모(컨테이너 오케스트레이션): Kubernetes 환경에서는 systemd 대신 Pod/Deployment가 서비스 수명주기를 관리하지만, 노드 레벨 에이전트(datadog-agent, fluentd 등)는 여전히 systemd로 관리합니다. 컨테이너 미사용 VM에서는 systemd가 핵심 데몬 매니저입니다.
보안 베스트 프랙티스 — Systemd 샌드박싱
NoNewPrivileges=true— 프로세스가setuid,setgid등으로 새 권한을 획득하지 못하게 합니다.ProtectSystem=strict— 전체 파일시스템을 읽기 전용으로 마운트합니다 (ReadWritePaths로 예외 지정).ProtectHome=true— /home, /root, /run/user를 빈 디렉토리로 만들어 접근을 차단합니다.PrivateTmp=true— 서비스 전용 /tmp를 생성하여 다른 프로세스와 격리합니다.- 서비스를 root로 실행하지 마세요 — 전용 시스템 사용자를 생성하세요:
useradd --system --no-create-home myapp systemd-analyze security myapp.service로 보안 점수를 확인하세요.
관련 도구
서비스에 환경변수를 주입하려면 환경변수 변환기를, 서비스 앞에 웹 서버를 배치하려면 Nginx 설정 생성기를, 서버 접근 제어에는 방화벽 규칙 생성기를 활용하세요.
참고 자료
- systemd.service(5) 매뉴얼 — freedesktop.org
- systemd.exec(5) — 보안 샌드박싱 디렉티브
- Arch Wiki — systemd 서비스 파일 가이드
- RHEL 9 — Managing Services with systemd