일반 시스템 관리 작업을 위한 서비스 모듈 사용하기

Ansible은 전체 플레이북이 필요하지 않은 경우에도 유용합니다. 일부 호스트에서 서비스가 중단되었거나 유지보수 창 전에 시끄러운 서비스를 비활성화해야 하는 경우, 애드혹 명령이 적절한 도구가 될 수 있습니다. 일회성 작업을 위해 YAML 파일을 만들 필요 없이 동일한 인벤토리 타겟팅 및 권한 상승 모델을 제공합니다.

내장된 service 모듈은 시스템 관리자 도구 상자에서 가장 자주 사용되는 도구 중 하나입니다. 이 모듈은 다양한 Linux 배포판에서 서비스를 관리하기 위한 표준화된 멱등성 인터페이스를 제공하며, Systemd, SysVinit, Upstart와 같은 init 시스템 간의 차이점을 추상화합니다. 이 가이드에서는 service 모듈을 애드혹 명령을 통해서만 활용하여 필수적이고 일반적인 시스템 관리 작업을 수행하는 방법을 자세히 설명합니다.

애드혹 명령 및 `service` 모듈 이해하기

애드혹 명령은 /usr/bin/ansible 명령을 사용하는 한 줄 실행으로, 대상 그룹(-i), 모듈(-m), 인수(-a)를 지정합니다. 이는 비영구적이며 플레이북 YAML 파일에 의존하지 않습니다.

service 모듈은 주로 두 가지 매개변수가 필요합니다.

name: 관리할 서비스의 이름 (예: httpd, nginx, sshd).
state: 원하는 운영 상태 (started, stopped, restarted, reloaded).
enabled (선택 사항): 시스템 부팅 시 서비스를 시작할지 여부 (yes 또는 no).

기본 애드혹 명령 구문

아래 모든 예제는 ansible 명령을 사용합니다. 서비스 관리는 종종 루트 권한이 필요하므로 -b (become/sudo) 플래그가 거의 항상 필요합니다.

ansible <host_pattern> -m service -a "name=<service_name> state=<action> enabled=<yes/no>" -b

참고: <host_pattern>을 대상 호스트 또는 그룹(예: webservers, all)으로 바꾸십시오.

1. 서비스가 실행 중인지 확인 (서비스 시작)

가장 일반적인 작업 중 하나는 중요한 서비스가 현재 활성 상태인지 확인하는 것입니다. state=started 매개변수는 서비스가 중지된 경우 Ansible이 시작하도록 합니다. 이미 실행 중인 경우 Ansible은 아무 작업도 수행하지 않습니다(멱등성).

예제: 모든 웹 서버에서 Nginx 웹 서버가 실행 중인지 확인

ansible webservers -m service -a "name=nginx state=started" -b

Ansible이 changed: true 메시지를 반환하면 서비스가 중지되었다가 시작된 것입니다. changed: false를 반환하면 서비스가 이미 실행 중이었던 것입니다.

2. 서비스 중지

활성 서비스를 즉시 중지하려면 state=stopped를 사용하십시오. 이는 유지보수, 종속성 정리 또는 즉각적인 보안 패치에 유용합니다.

예제: 모든 데이터베이스 서버에서 PostgreSQL 데이터베이스 중지

ansible db_servers -m service -a "name=postgresql state=stopped" -b

팁: 중요한 서비스를 중지할 때는 나중에 다른 모듈(예: command 모듈)을 사용하여 상태를 확인하는 명령을 실행하는 것이 좋습니다 (예: ansible db_servers -a 'systemctl status postgresql').

3. 서비스 재시작 및 리로드

구성 파일이 수정되면 서비스를 정상적으로 리로드하거나 강제로 재시작해야 하는 경우가 많습니다. service 모듈은 두 작업을 모두 처리합니다.

재시작 (`state=restarted`)

재시작은 서비스를 완전히 중지한 후 다시 시작하는 것을 의미합니다. 이는 기본 데몬 동작에 영향을 미치는 변경 사항에 필요합니다.

예제: 모든 호스트에서 SSH 데몬 재시작

ansible all -m service -a "name=sshd state=restarted" -b

리로드 (`state=reloaded`)

리로드는 서비스(Nginx 또는 Apache 등)에서 지원하는 경우 실행 중인 연결을 중단하지 않고 구성 변경 사항을 적용합니다. 이는 고가용성 환경에서 선호되는 방법입니다.

예제: Nginx 구성을 정상적으로 리로드

ansible webservers -m service -a "name=nginx state=reloaded" -b

중요: 서비스가 reload를 지원하지 않는 경우 결과는 서비스 관리자 및 단위 정의에 따라 다릅니다. 일부 단위는 리로드 요청을 실패하고, 일부는 리로드를 다른 작업에 매핑하며, 일부는 유용한 작업을 수행하지 않습니다. 프로덕션 변경 사항에 리로드를 사용하기 전에 서비스 자체 문서를 확인하십시오.

4. 서비스 지속성 관리 (활성화 및 비활성화)

state 매개변수는 현재 런타임 상태를 제어합니다. 별도의 enabled 매개변수는 운영 체제 부팅 시 서비스가 자동으로 시작될지 여부를 제어합니다.

부팅 시 서비스 시작 보장 (`enabled=yes`)

이는 호스트 재부팅 후에도 유지되어야 하는 미션 크리티컬 서비스에 중요합니다.

예제: Docker 서비스가 활성화되고 실행 중인지 확인

ansible dockernodes -m service -a "name=docker state=started enabled=yes" -b

부팅 시 서비스 시작 방지 (`enabled=no`)

이는 시스템을 보호하거나 불필요한 기본 서비스(예: 클라우드 기반 방화벽을 사용하는 경우 내장 방화벽 비활성화)를 비활성화하는 데 자주 사용됩니다.

예제: 기본 Firewalld 서비스 비활성화

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

보안 모범 사례: 시스템 업데이트 또는 재부팅 중 예기치 않은 시작을 방지하기 위해 사용하지 않는 서비스는 항상 stopped 및 enabled=no로 설정하십시오.

5. 고급 서비스 유형 및 오류 처리

일반 service 모듈은 모든 주요 init 시스템에서 작동하도록 설계되었지만, 명시적 처리가 유용하거나 필요한 시나리오가 있습니다.

일반 모듈이 실패하는 경우

드물게, 특히 오래된 시스템이나 고도로 사용자 정의된 환경에서 일반 service 모듈이 올바른 init 시스템을 감지하지 못할 수 있습니다. Ansible은 이러한 경우를 위해 시스템별 모듈을 제공합니다.

systemd: 모든 최신 배포판(CentOS 7+, Ubuntu 15+, Debian 8+).
sysvinit: 오래된 시스템 또는 특수 배포판.

대상이 Systemd를 사용한다는 것을 알고 있다면 systemd 모듈을 명시적으로 사용할 수 있지만, 기본 작업의 경우 구문은 일반 service 모듈과 동일합니다.

# systemd 모듈을 명시적으로 사용 ('service'와 기능 동일)
ansible servers -m systemd -a "name=chronyd state=started enabled=yes" -b

사용자 정의 스크립트로 서비스 관리

init 시스템에서 기본적으로 지원하지 않는 서비스 명령(예: 시작 중 사용자 정의 환경 변수)을 실행해야 하는 경우, 전체 플레이북에서 service 모듈을 다른 작업과 결합하거나 애드혹 개입을 위해 shell 모듈을 사용해야 할 수 있지만, 이는 멱등성을 떨어뜨립니다.

# 복잡한 서비스 작업을 위해 'shell'을 사용하는 애드혹 명령 예제 (주의해서 사용)
ansible webservers -a "/usr/bin/my_custom_service_script restart" -b

서비스 모듈 애드혹 명령 치트 시트

작업	인수	예제 명령
실행 중인지 확인	`state=started`	`ansible all -m service -a "name=apache2 state=started" -b`
서비스 중지	`state=stopped`	`ansible all -m service -a "name=fail2ban state=stopped" -b`
강제 재시작	`state=restarted`	`ansible servers -m service -a "name=postfix state=restarted" -b`
정상 리로드	`state=reloaded`	`ansible webservers -m service -a "name=httpd state=reloaded" -b`
자동 시작 설정	`enabled=yes`	`ansible all -m service -a "name=firewalld enabled=yes" -b`
자동 시작 비활성화	`enabled=no`	`ansible all -m service -a "name=cups enabled=no" -b`
실행 및 활성화 확인	`state=started enabled=yes`	`ansible control -m service -a "name=ansible_api state=started enabled=yes" -b`

실제 인시던트를 위한 안전한 워크플로

인시던트 중에 Ansible 서비스 모듈을 사용할 때 명령 자체는 일반적으로 쉬운 부분입니다. 더 어려운 부분은 올바른 호스트를 대상으로 하고 서비스 관리자가 수행할 작업을 이해하는 것입니다.

인벤토리 검사부터 시작하십시오. webservers에서 Nginx를 재시작하려는 경우 해당 그룹에 무엇이 포함되어 있는지 확인하십시오.

ansible-inventory -i inventory.ini --graph webservers

인벤토리가 동적인 경우 동적 소스에 대해 동일한 검사를 실행하십시오. 마이그레이션이나 임시 확장 이벤트 후에 클라우드 태그에 예상치 못한 호스트가 포함되는 것은 일반적입니다. 5개의 애플리케이션 노드에서 안전한 서비스 재시작은 리전의 모든 노드에서 위험할 수 있습니다.

다음으로, 동일한 대상에 대해 읽기 전용 명령을 실행하십시오.

ansible webservers -m command -a "systemctl is-active nginx" -b

이렇게 하면 변경을 수행하기 전에 연결 사용자, 권한 상승, 호스트 패턴 및 서비스 이름을 확인할 수 있습니다. Debian 및 Ubuntu에서 웹 서비스는 일반적으로 nginx 또는 apache2입니다. 많은 Red Hat 계열 시스템에서 Apache는 일반적으로 httpd입니다. Ansible 모듈은 패키지 명명 규칙을 추측할 수 없습니다.

고위험 서비스의 경우 먼저 --limit를 사용하십시오.

ansible webservers --limit web01.example.com -m service -a "name=nginx state=reloaded" -b

작동하면 소규모 그룹으로 확장한 다음 전체 그룹으로 확장하십시오. 애드혹 명령에는 serial이 있는 플레이북의 내장 롤아웃 구조가 없으므로 신중해야 합니다. 대규모 플릿의 경우 serial을 설정하고, 상태 확인을 추가하고, 실패 시 중지할 수 있기 때문에 하나의 거대한 애드혹 명령보다 짧은 플레이북이 더 안전할 수 있습니다.

state=restarted에 주의하십시오. 항상 재시작을 요청하므로 다른 변경 사항이 없어도 changed를 보고하고 서비스를 중단합니다. 실제로 재시작을 원할 때는 괜찮습니다. "상태가 괜찮은지 확인"하는 게으른 방법으로 사용하는 것은 낭비입니다. 일상적인 확인에는 state=started를 선호하십시오. 중지된 서비스를 시작하지만 실행 중인 서비스는 그대로 둡니다.

enabled=yes 및 enabled=no도 동일한 주의가 필요합니다. 이는 현재 런타임 동작뿐만 아니라 부팅 동작을 변경합니다. 문제 해결 중에 다음을 실행하면:

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

지금 방화벽을 중지했을 뿐만 아니라 재부팅 후 시작하지 않도록 시스템에 지시한 것입니다. 호스트 방화벽이 의도적으로 비활성화된 클라우드 환경에서는 올바를 수 있지만 보안 기준을 위반할 수 있습니다. 공유 운영 팀에서는 지속적인 결정이 표시되도록 티켓 메모를 남기거나 플레이북 변경 사항을 커밋하십시오.

systemd로 관리되는 서비스의 경우 ansible.builtin.systemd_service 모듈은 daemon_reload, masked 및 사용자 범위 서비스와 같은 systemd 관련 옵션을 제공합니다. 일반 service 모듈은 여전히 이식 가능한 기본 사항에 유용하지만 systemd 관련 동작이 필요하면 systemd 모듈을 직접 사용하십시오.

ansible appservers -m ansible.builtin.systemd_service -a "name=myapp state=restarted daemon_reload=true" -b

마지막으로 항상 결과를 읽으십시오. changed=true는 Ansible이 모듈에 무언가를 변경하도록 요청했음을 의미하며, 그 후에 애플리케이션이 정상이라는 의미는 아닙니다. 서비스가 깔끔하게 재시작되고 2초 후에 자체 상태 확인에 실패할 수 있습니다. 서비스 변경 후 애플리케이션과 일치하는 확인을 수행하십시오.

ansible webservers -m uri -a "url=http://127.0.0.1/health status_code=200"

또는 HTTP를 사용할 수 없는 경우:

ansible webservers -m command -a "systemctl is-active nginx" -b

가장 좋은 애드혹 서비스 명령은 지루합니다: 좁은 대상, 명확한 상태, 권한 상승 포함, 그리고 바로 뒤에 확인 명령이 있습니다. 이 습관은 빠르게 서비스를 관리할 때 발생하는 대부분의 실수를 방지합니다.

애드혹 명령이 플레이북이 되어야 하는 경우

애드혹 명령은 빠르고 컨텍스트가 적은 작업에 탁월합니다. 반복 가능한 작업을 대체할 수는 없습니다. 동일한 서비스 명령을 채팅에 붙여넣고, 수동 확인 단계를 추가하고, "처음 두 호스트에서 실행하고, 기다린 다음, 나머지에서 실행"이라고 말하는 경우, 이는 이미 존재하려고 하는 플레이북입니다.

플레이북은 검토 가능한 의도를 제공합니다.

- name: Reload nginx safely
  hosts: webservers
  become: true
  serial: 5
  tasks:
    - name: Validate nginx configuration
      ansible.builtin.command: nginx -t
      changed_when: false

    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

    - name: Check local health endpoint
      ansible.builtin.uri:
        url: http://127.0.0.1/health
        status_code: 200

동일한 작업이 여전히 간단하지만 이제 배치, 검증 및 상태 확인이 있습니다. Git에 저장할 수 있습니다. 다음 유지보수 창 전에 누군가 검토할 수 있습니다. 또한 any_errors_fatal: true를 추가하거나 터미널을 보면서 압박 속에서 판단을 내리는 대신 실패 동작을 조정할 수 있습니다.

빠른 시작, 중지 및 확인을 위해 계속 애드혹 service 명령을 사용하십시오. 작업이 고객 대면 가용성을 변경하거나, 롤아웃 순서가 필요하거나, 다른 사람이 반복해야 하는 경우 플레이북을 사용하십시오. 그 경계는 형식에 관한 것이 아니라 위험한 부분을 표시하는 데 관한 것입니다.