DevOps 지식 허브
DevOps 지식 허브

Systemd 마스터하기: 첫 번째 사용자 지정 서비스 유닛 파일 생성하기

사용자 지정 유닛 파일(Unit File)을 생성하여 Systemd 서비스 관리의 기본 사항을 배웁니다. 이 튜토리얼에서는 필수적인 `[Unit]`, `[Service]`, `[Install]` 섹션을 분석하고, `systemctl`을 사용하여 Linux에서 기본 백그라운드 서비스를 정의, 활성화, 시작 및 확인하는 방법에 대한 단계별 지침을 제공합니다.

42 조회수

Systemd 마스터하기: 첫 번째 사용자 지정 서비스 유닛 파일 만들기

Systemd는 최신 Linux 배포판 전반에 걸쳐 보편적으로 사용되는 서비스 관리자가 되었으며, 시스템 부팅 초기화부터 실행 중인 사용자 공간 서비스 처리까지 모든 것을 담당합니다. 사용자 지정 유닛 파일(Unit Files)을 작성하는 방법을 이해하는 것은 애플리케이션 배포를 자동화하고, 서비스가 올바르게 재시작되도록 보장하며, 특정 프로세스를 운영 체제의 라이프사이클에 원활하게 통합하는 데 필수적입니다.

이 포괄적인 가이드는 Systemd 서비스 유닛 파일의 필수적인 구조를 안내하며, 핵심적인 [Unit], [Service], [Install] 섹션을 다룹니다. 이 튜토리얼을 마치면 자신만의 사용자 지정 서비스를 정의하고, 활성화하고, 관리할 수 있게 될 것입니다.

전제 조건 (Prerequisites)

구성을 시작하기 전에 관리자 권한(sudo)과 Linux 파일 시스템에 대한 기본적인 이해가 있는지 확인하십시오. 이 가이드는 Systemd를 사용하는 최신 배포판(예: Debian, Ubuntu, Fedora, CentOS 7+/RHEL 7+)에서 작업한다고 가정합니다.

Systemd 유닛 파일 이해하기

Systemd 유닛 파일은 Systemd가 관리하는 리소스를 설명하는 INI 스타일의 구성 파일입니다. 서비스의 경우, 이 파일들은 일반적으로 사용자 지정 또는 관리자가 정의한 서비스는 /etc/systemd/system/에, 벤더가 제공한 서비스는 /lib/systemd/system/ 내에 위치합니다.

서비스 유닛 파일은 .service 확장자로 끝나야 합니다(예: mydaemon.service). 구조는 필수 섹션과 선택적 섹션으로 나뉘며, 가장 중요한 세 가지는 [Unit], [Service], 그리고 [Install]입니다.

1단계: 서비스 스크립트 (실행 파일) 만들기

유닛 파일을 만들기 전에, 서비스가 관리할 간단한 스크립트나 애플리케이션이 필요합니다. 이 예제에서는 10초마다 메시지를 기록하는 기본 스크립트를 생성합니다.

  1. 스크립트 디렉터리 및 파일 생성:

    bash sudo mkdir -p /opt/my-custom-service sudo nano /opt/my-custom-service/reporter.sh

  2. reporter.sh에 다음 내용을 추가:

    ```bash

    !/bin/bash

    LOG_FILE="/var/log/reporter.log"
    while true; do
    echo "$(date +'%Y-%m-%d %H:%M:%S') - Custom service heartbeat active." >> $LOG_FILE
    sleep 10
    done
    ```

  3. 스크립트를 실행 가능하게 만들기:

    bash sudo chmod +x /opt/my-custom-service/reporter.sh

2단계: 사용자 지정 서비스 유닛 파일 정의하기

이제 Systemd에게 스크립트를 어떻게 실행할지 알려주는 Systemd 유닛 파일을 생성합니다.

  1. 서비스 파일 생성:

    bash sudo nano /etc/systemd/system/my-reporter.service

  2. 표준 섹션으로 파일 채우기:

[Unit] 섹션

이 섹션은 서비스에 대한 메타데이터를 포함하며, 다른 유닛(서비스, 소켓, 마운트 포인트 등)과의 관계를 정의합니다.

  • Description: 서비스에 대한 사람이 읽을 수 있는 이름입니다.
  • After: 나열된 유닛이 성공적으로 시작된 후에만 이 서비스가 시작되어야 함을 지정합니다.
[Unit]
Description=My Custom Reporter Daemon
# 기본 네트워킹 및 로깅 서비스가 작동된 후에만 시작
After=network.target

[Service] 섹션

이것은 핵심 섹션으로, 실행할 명령이 무엇인지 그리고 Systemd가 프로세스를 어떻게 관리해야 하는지를 정의합니다.

  • Type: 프로세스 시작 유형을 정의합니다. simple은 포그라운드에서 지속적으로 실행되는 스크립트에 대한 표준입니다.
  • User/Group: 프로세스를 실행할 사용자 컨텍스트를 지정합니다(보안을 위해 강력히 권장됨).
  • ExecStart: 서비스 시작 시 실행할 명령 또는 스크립트의 절대 경로입니다.
  • Restart: 자동 재시작 정책을 정의합니다(예: on-failure, always).
[Service]
Type=simple
User=your_username # 중요: 'your_username'을 가능하면 비-루트 사용자로 교체하세요
Group=your_group # 선택 사항, 일반적으로 사용자 그룹과 일치

# Systemd가 실행하는 명령
ExecStart=/opt/my-custom-service/reporter.sh

# 재시작 정책
Restart=on-failure
RestartSec=5s # 재시작을 시도하기 전에 5초 대기
StandardOutput=journal # 출력을 Systemd 저널로 직접 보냄
StandardError=journal

보안 경고: 절대적으로 필요한 경우가 아니면 사용자 지정 서비스를 root 사용자로 실행하지 마십시오. 애플리케이션 프로세스를 위해 전용의, 최소 권한 사용자(least-privileged user)를 정의하십시오.

[Install] 섹션

이 섹션은 서비스가 어떻게 활성화되어야 하는지를 지정합니다. 구체적으로, 부팅 시 자동으로 시작되도록 연결해야 할 타겟을 지정합니다.

  • WantedBy: 이 서비스를 끌어와야 하는 타겟을 지정합니다. 정상 부팅 시 시작되어야 하는 표준 시스템 서비스의 경우, multi-user.target이 표준 선택입니다.
[Install]
WantedBy=multi-user.target

3단계: 서비스 재로드, 활성화 및 시작

유닛 파일을 생성하거나 수정한 후에는 Systemd에게 구성 데몬을 재로드하도록 알린 다음 새 서비스를 관리해야 합니다.

  1. Systemd 관리자 구성 재로드:
    이 단계는 유닛 파일이 추가되거나 수정될 때마다 필수입니다.

    bash sudo systemctl daemon-reload

  2. 서비스 활성화 (부팅 시 자동 시작):
    이는 적절한 타겟 디렉터리(예: multi-user.target.wants/)에서 서비스 파일을 가리키는 심볼릭 링크를 생성하여, 시스템 부팅 시 자동으로 시작되도록 보장합니다.

    bash sudo systemctl enable my-reporter.service
    출력은 심볼릭 링크 생성을 확인할 것입니다.

  3. 서비스 시작:
    이는 ExecStart에 정의된 프로세스를 즉시 시작합니다.

    bash sudo systemctl start my-reporter.service

4단계: 서비스 상태 및 로그 확인

서비스가 올바르게 시작되어 의도한 대로 실행 중인지 확인하는 것이 중요합니다.

  1. 상태 확인:
    status 명령은 현재 상태, 최근 로그 라인 및 실행 세부 정보를 제공합니다.

    bash systemctl status my-reporter.service

    출력에서 Active: active (running)을 확인하십시오.

  2. 로그 보기 (Journalctl):
    [Service] 섹션에서 출력을 저널로 지정했으므로, journalctl을 사용하여 런타임 메시지를 볼 수 있습니다.

    bash journalctl -u my-reporter.service -f

  3. 파일 출력 확인:
    스크립트에서 지정된 로그 파일을 확인합니다.

    bash tail -f /var/log/reporter.log

필수 관리 명령

일단 정의되면, systemctl 명령을 사용하여 서비스를 관리하는 것은 간단합니다.

작업 명령
서비스 중지 sudo systemctl stop my-reporter.service
서비스 재시작 sudo systemctl restart my-reporter.service
자동 시작 비활성화 sudo systemctl disable my-reporter.service
상태 확인 systemctl status my-reporter.service

요약 및 다음 단계

[Unit], [Service], [Install] 섹션을 마스터함으로써 Systemd를 사용하여 강력하고 관리되는 서비스를 성공적으로 구축했습니다. 이 기초를 통해 복잡한 애플리케이션 라이프사이클을 관리하고, 안정적인 시작 순서, 오류 발생 시 자동 재시작, 그리고 Systemd 저널을 통한 중앙 집중식 로깅을 보장할 수 있습니다.

더 고급 사용 사례를 위해, 구성 로딩을 위한 EnvironmentFile 또는 전통적인 데몬 관리를 위해 Type을 forking으로 변경하는 것과 같은 [Service] 섹션 내의 옵션들을 탐색해 보세요.