RHEL Ansible 플레이북 및 호스트 문제 해결 가이드

소개

이 실습에서는 Red Hat Enterprise Linux 에서 Ansible 을 사용할 때 발생하는 일반적인 문제 해결 방법을 배웁니다. 초기 환경 설정부터 일반적인 플레이북 오류 및 관리 호스트 연결 문제에 이르기까지 다양한 문제를 식별하고 해결하는 실질적인 경험을 쌓게 됩니다. 연습에서는 YAML 구문 수정, Jinja2 템플릿 실수 수정, 원격 시스템 문제 진단 등을 다룹니다.

먼저 RHEL 환경을 준비하고 효과적인 로깅을 위해 Ansible 을 구성하는 것부터 시작합니다. 그런 다음 실제 문제 해결 시나리오에 들어가 Ansible 의 check mode 를 사용하여 서비스 관련 문제를 진단하고 방화벽 구성을 수정하여 호스트 연결 불가능 문제를 해결합니다. 이 실습이 끝나면 강력한 Ansible 자동화 워크플로우를 유지하기 위한 포괄적인 기술 세트를 갖추게 될 것입니다.

RHEL 환경 준비 및 Ansible 로깅 구성

이 단계에서는 Ansible 자동화를 위해 Red Hat Enterprise Linux 환경을 준비합니다. 여기에는 필요한 소프트웨어 설치, 전용 프로젝트 디렉터리 생성, Ansible 동작 제어 및 로깅 활성화를 위한 기본 구성 파일 설정이 포함됩니다. 올바른 설정은 효과적인 자동화 및 문제 해결을 위한 첫 번째 단계입니다.

Ansible 설치

먼저 Ansible 을 설치해야 합니다. 핵심 자동화 엔진은 ansible-core 패키지를 통해 제공됩니다. sudo와 함께 dnf 패키지 관리자를 사용하여 설치합니다. -y 플래그는 모든 확인 프롬프트에 자동으로 "yes"로 응답합니다.

sudo dnf install -y ansible-core

패키지가 종속성과 함께 설치되고 있음을 나타내는 출력이 표시되어야 합니다.

Last metadata expiration check: ...
Dependencies resolved.
================================================================================
 Package             Architecture   Version                Repository      Size
================================================================================
Installing:
 ansible-core        x86_64         <version>              <repo>          2.8 M
...
Transaction Summary
================================================================================
Install  XX Packages

Total download size: XX M
Installed size: XX M
...
Complete!

프로젝트 디렉터리 생성

Ansible 프로젝트를 전용 디렉터리에 구성하는 것이 모범 사례입니다. 이렇게 하면 플레이북, 인벤토리 및 구성 파일이 깔끔하게 분리됩니다. 홈 프로젝트 폴더 내에 ansible_troubleshooting이라는 디렉터리를 만들고 해당 디렉터리로 이동합니다.
```
mkdir -p ~/project/ansible_troubleshooting
cd ~/project/ansible_troubleshooting
```
이제부터 이 실습의 모든 명령은 ~/project/ansible_troubleshooting 디렉터리 내에서 실행됩니다.
Ansible 인벤토리 파일 생성

인벤토리는 Ansible 이 관리할 호스트 (또는 노드) 를 나열하는 파일입니다. 단일 LabEx VM 에서 작업하므로 Ansible 이 로컬 머신 자체를 관리하도록 구성합니다.

inventory라는 파일을 만들고 localhost를 추가합니다. ansible_connection=local 부분은 Ansible 이 SSH 를 사용하지 않고 제어 노드 (VM) 에서 직접 명령을 실행하도록 지시합니다.
```
echo "localhost ansible_connection=local" > inventory
```
cat 명령을 사용하여 파일 내용을 확인할 수 있습니다.
```
cat inventory
```
예상 출력:
```
localhost ansible_connection=local
```
Ansible 로깅 구성

ansible.cfg 파일은 특정 프로젝트에 대한 Ansible 의 동작을 사용자 지정할 수 있게 해줍니다. 프로젝트 디렉터리에 배치하면 해당 설정이 시스템 전체 기본값을 재정의합니다. 여기서는 이 파일을 만들어 인벤토리 위치를 지정하고 로깅을 활성화합니다. 로깅은 모든 플레이북 실행에 대한 자세한 정보를 기록하므로 문제 해결에 매우 중요합니다.

nano 편집기를 사용하여 ansible.cfg 파일을 만듭니다.
```
nano ansible.cfg
```
이제 다음 내용을 nano 편집기에 복사하여 붙여넣습니다. 이 구성은 Ansible 에 현재 디렉터리의 inventory 파일을 사용하고 모든 로그 출력을 ansible.log라는 파일에 쓰도록 지시합니다.
```
[defaults]
inventory = /home/labex/project/ansible_troubleshooting/inventory
log_path = /home/labex/project/ansible_troubleshooting/ansible.log
```
nano에서 파일을 저장하려면 Ctrl+X를 누르고, 확인하려면 Y를 누른 다음, 파일을 쓰려면 Enter를 누릅니다.

이제 환경이 완전히 준비되었습니다. Ansible 이 설치되었고 로컬 인벤토리 및 로깅이 활성화된 프로젝트 디렉터리가 구성되어 다음 단계를 진행할 준비가 되었습니다.

플레이북의 YAML 구문 및 들여쓰기 오류 수정

이 단계에서는 Ansible 플레이북에서 가장 흔한 두 가지 오류 유형인 YAML 구문 오류와 잘못된 들여쓰기를 진단하고 수정하는 방법을 배웁니다. 플레이북 작성에 사용되는 언어인 YAML 은 구조에 매우 엄격합니다. 잘못 배치된 공백 하나 또는 따옴표로 묶이지 않은 특수 문자는 플레이북 실행을 방해할 수 있습니다. 플레이북을 실행하기 전에 유효성을 검사하는 필수 도구인 ansible-playbook --syntax-check 명령을 사용하게 됩니다.

의도적인 오류가 포함된 플레이북 생성

먼저 프로젝트 디렉터리 (~/project/ansible_troubleshooting) 에 webserver.yml이라는 새 플레이북 파일을 생성합니다. 이 파일에는 수정할 의도적인 오류가 포함되어 있습니다.

nano를 사용하여 파일을 생성합니다.
```
nano webserver.yml
```
다음 내용을 편집기에 복사하여 붙여넣습니다. 콜론이 포함된 따옴표 없는 문자열과 두 번째 작업의 잘못된 들여쓰기라는 두 가지 의도적인 오류에 유의하십시오.
```
---
- name: Configure Web Server
  hosts: localhost
  vars:
    ## ERROR 1: Unquoted colon in string
    package_comment: This is a package: httpd
  tasks:
    - name: Install httpd package
      ansible.builtin.dnf:
        name: httpd
        state: present

    ## ERROR 2: Incorrect indentation
      - name: Create a test index page
        ansible.builtin.copy:
          content: "<h1>Welcome to Ansible</h1>"
          dest: /var/www/html/index.html
```
파일을 저장하고 Ctrl+X, Y, Enter를 눌러 nano를 종료합니다.
YAML 구문 오류 (따옴표 없는 콜론) 식별 및 수정

이제 방금 생성한 플레이북에 대한 구문 검사를 실행합니다. 이 명령은 파일을 구문 분석하고 실제 작업을 실행하지 않고 구문 문제를 보고합니다.
```
ansible-playbook --syntax-check webserver.yml
```
예상 출력 (오류): package_comment의 값에 콜론 (:) 이 포함되어 있지만 따옴표로 묶여 있지 않기 때문에 오류가 표시됩니다. YAML 은 콜론을 키 - 값 구분 기호로 해석하여 구문 오류를 발생시킵니다.
```
ERROR! We were unable to read either as JSON nor YAML, these are the errors we found:
- Syntax Error while loading YAML.
  did not find expected ':'

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 6, column 41, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  vars:
    package_comment: This is a package: httpd
                                        ^ here
```
해결 방법: 이를 수정하려면 문자열을 큰따옴표로 묶어야 합니다. nano로 파일을 다시 엽니다.
```
nano webserver.yml
```
따옴표를 추가하도록 vars 아래의 줄을 수정합니다.
```
## ... (rest of the file)
vars:
  ## FIX: Add quotes around the string with a colon
  package_comment: "This is a package: httpd"
## ... (rest of the file)
```
편집기를 저장하고 종료합니다.
YAML 들여쓰기 오류 식별 및 수정

첫 번째 오류를 수정한 후 구문 검사를 다시 실행합니다.
```
ansible-playbook --syntax-check webserver.yml
```
예상 출력 (오류): 이번에는 Ansible 이 플레이북 구조와 관련된 다른 오류를 보고합니다.
```
ERROR! A malformed block was encountered.

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 13, column 11, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:


      ## ERROR 2: Incorrect indentation
      - name: Create a test index page
        ^ here
```
이 오류는 YAML 이 구조를 정의하기 위해 들여쓰기를 사용하기 때문에 발생합니다. 목록의 모든 항목 (이 경우 -로 시작하는 목록 항목인 작업) 은 동일한 수준의 들여쓰기를 가져야 합니다. 두 번째 작업인 Create a test index page는 들여쓰기가 너무 많이 되어 있습니다.

해결 방법: 들여쓰기를 수정하기 위해 파일을 다시 한 번 엽니다.
```
nano webserver.yml
```
두 번째 작업 앞의 추가 공백을 제거하여 첫 번째 작업의 하이픈과 완벽하게 정렬되도록 합니다.
```
## ... (rest of the file)
tasks:
  - name: Install httpd package
    ansible.builtin.dnf:
      name: httpd
      state: present

  ## FIX: Correct the indentation to align with the previous task
  - name: Create a test index page
    ansible.builtin.copy:
      content: "<h1>Welcome to Ansible</h1>"
      dest: /var/www/html/index.html
```
편집기를 저장하고 종료합니다.
수정된 플레이북 확인

마지막으로 구문 검사를 한 번 더 실행합니다.
```
ansible-playbook --syntax-check webserver.yml
```
이번에는 명령이 오류 없이 완료되어야 하며 플레이북 이름이 출력되어 구문이 올바르게 수정되었음을 확인합니다.

예상 출력 (성공):
```
playbook: webserver.yml
```

Jinja2 따옴표 및 템플릿 경로 오류 해결

이 단계에서는 Ansible 의 강력한 템플릿 엔진인 Jinja2 와 관련된 오류를 해결합니다. Jinja2 표현식이 종종 따옴표로 묶여야 하는 이유와 플레이북이 지정된 템플릿 파일을 찾을 수 없을 때 디버깅하는 방법을 배우게 됩니다. 이들은 플레이북이 이미 구문 검사를 통과한 후에 발생하는 일반적인 런타임 오류입니다.

Jinja2 템플릿 파일 생성

먼저 템플릿 파일이 필요합니다. 정적 파일과 달리 템플릿에는 Ansible 이 플레이북 실행 중에 실제 값으로 대체할 변수가 포함될 수 있습니다. 간단한 HTML 템플릿을 생성합니다.

nano를 사용하여 프로젝트 디렉터리 (~/project/ansible_troubleshooting) 에 index.html.j2라는 파일을 생성합니다. .j2 확장자는 Jinja2 템플릿에 대한 일반적인 규칙입니다.
```
nano index.html.j2
```
다음 HTML 콘텐츠를 편집기에 복사하여 붙여넣습니다. {{ welcome_message }} 플레이스홀더는 Jinja2 변수입니다.
```
<h1>{{ welcome_message }}</h1>
<p>This page was deployed by Ansible.</p>
```
파일을 저장하고 nano를 종료합니다 (Ctrl+X, Y, Enter).
플레이북 수정하여 템플릿 사용 및 오류 발생

이제 webserver.yml 플레이북을 수정하여 ansible.builtin.template 모듈을 사용하도록 합니다. 또한 따옴표 없는 Jinja2 변수와 잘못된 템플릿 경로라는 두 가지 새로운 오류를 발생시킵니다.

nano로 webserver.yml을 엽니다.
```
nano webserver.yml
```
파일의 전체 내용을 다음 내용으로 바꿉니다. become: true 지시문은 Ansible 에 관리자 권한 (sudo 사용) 으로 작업을 실행하도록 지시하며, 이는 소프트웨어를 설치하고 /var/www/html과 같은 시스템 디렉터리에 파일을 쓰는 데 필요합니다.
```
---
- name: Configure Web Server
  hosts: localhost
  become: true
  vars:
    package_name: httpd
    welcome_message: "Welcome to Ansible with Jinja2"
  tasks:
    - name: Install httpd package
      ansible.builtin.dnf:
        ## ERROR 1: Unquoted Jinja2 variable
        name: { { package_name } }
        state: present

    - name: Create a test index page from template
      ansible.builtin.template:
        ## ERROR 2: Incorrect template source path
        src: index.j2
        dest: /var/www/html/index.html
```
편집기를 저장하고 종료합니다.

Jinja2 따옴표 오류 식별 및 수정

이것은 Jinja2 문제이지만 YAML 구문 오류로 나타날 수 있습니다. 구문 검사기를 실행하여 Ansible 이 이를 어떻게 해석하는지 확인합니다.

ansible-playbook --syntax-check webserver.yml

예상 출력 (오류): {{로 시작하는 YAML 값은 특수 구문으로 취급되므로 문자열로 해석되려면 따옴표로 묶어야 하므로 구문 오류가 발생합니다.

ERROR! A malformed block was encountered.

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 11, column 19, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

          ## ERROR 1: Unquoted Jinja2 variable
          name: {{ package_name }}
                  ^ here

해결 방법: webserver.yml을 열고 Jinja2 변수를 큰따옴표로 묶습니다.

nano webserver.yml

Install httpd package 작업을 수정합니다.

## ... (rest of the file)
tasks:
  - name: Install httpd package
    ansible.builtin.dnf:
      ## FIX: Quote the Jinja2 expression
      name: "{{ package_name }}"
      state: present
## ... (rest of the file)

저장하고 종료합니다. 이제 구문 검사가 통과해야 합니다.

템플릿 경로 오류 식별 및 수정

이제 구문이 올바르게 되었으므로 플레이북을 실행해 봅니다.
```
ansible-playbook webserver.yml
```
예상 출력 (오류): 플레이북이 실패하지만 이번에는 구문 오류가 아니라 런타임 오류입니다. 오류 메시지는 소스 파일 index.j2를 찾을 수 없다고 명확하게 명시합니다.
```
TASK [Create a test index page from template] **********************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find or access '/home/labex/project/ansible_troubleshooting/index.j2' on the Ansible Controller."}
```
이는 플레이북의 src 매개변수가 index.j2를 가리키지만 생성한 파일의 이름이 index.html.j2이기 때문에 발생합니다.

해결 방법: 마지막으로 webserver.yml을 열고 파일 이름을 수정합니다.
```
nano webserver.yml
```
Create a test index page from template 작업의 src 매개변수를 수정합니다.
```
## ... (rest of the file)
- name: Create a test index page from template
  ansible.builtin.template:
    ## FIX: Correct template source filename
    src: index.html.j2
    dest: /var/www/html/index.html
## ... (rest of the file)
```
편집기를 저장하고 종료합니다.

플레이북 성공적으로 실행

플레이북을 다시 실행합니다. 이제 모든 작업을 성공적으로 완료해야 합니다.

ansible-playbook webserver.yml

예상 출력 (성공):

PLAY [Configure Web Server] ****************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Install httpd package] ***************************************************
changed: [localhost]

TASK [Create a test index page from template] **********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

체크 모드를 사용하여 관리 호스트 서비스 오류 문제 해결

이 단계에서는 Ansible 의 가장 강력한 문제 해결 기능 중 하나인 체크 모드를 사용하는 방법을 배우게 됩니다. 체크 모드 (--check 플래그로 활성화) 를 사용하면 실제로 시스템을 수정하지 않고 플레이북을 실행하여 어떤 변경이 발생할지 확인할 수 있습니다. 이는 잘못된 서비스 이름과 같은 문제를 진단하고 플레이북을 안전하게 테스트하는 데 매우 유용합니다.

서비스 관리를 위한 플레이북 생성

이제 httpd 웹 서버 서비스가 실행 중인지 확인하도록 설계된 새 플레이북 service.yml을 생성합니다. 그러나 일반적인 오류를 시뮬레이션하기 위해 의도적으로 잘못된 서비스 이름을 사용합니다.

nano를 사용하여 ~/project/ansible_troubleshooting 디렉터리에 service.yml 파일을 생성합니다.
```
nano service.yml
```
다음 내용을 복사하여 붙여넣습니다. 서비스 이름이 apache2로 설정되어 있는데, 이는 다른 Linux 배포판에서 Apache 웹 서버의 일반적인 이름이지만 RHEL 에는 올바르지 않습니다.
```
---
- name: Manage Web Server Service
  hosts: localhost
  become: true
  tasks:
    - name: Ensure web server service is started
      ansible.builtin.service:
        ## ERROR: Incorrect service name for RHEL
        name: apache2
        state: started
        enabled: true
```
파일을 저장하고 nano를 종료합니다 (Ctrl+X, Y, Enter).
체크 모드를 사용하여 서비스 오류 식별

플레이북을 정상적으로 실행하는 대신 체크 모드로 실행합니다. 이렇게 하면 Ansible 이 변경을 수행하는 것을 방지하지만 시스템 상태를 확인하고 어떤 작업을 수행할지 보고할 수 있습니다.
```
ansible-playbook --check service.yml
```
예상 출력 (오류): 플레이북이 실패합니다. 오류 메시지는 apache2라는 이름의 서비스를 찾을 수 없다고 명확하게 표시합니다. 이를 통해 플레이북의 name 매개변수가 잘못되었음을 즉시 알 수 있습니다.
```
TASK [Ensure web server service is started] ************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find the requested service 'apache2': host"}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
```
올바른 서비스 이름 찾기

플레이북을 수정하려면 RHEL 에서 httpd 패키지에 대한 올바른 서비스 이름을 찾아야 합니다. 이를 수행하는 안정적인 방법은 패키지가 설치한 파일을 나열하고 일반적으로 /usr/lib/systemd/system/에 있는 서비스 단위 파일을 찾는 것입니다.

rpm 명령을 사용하여 httpd 패키리를 쿼리합니다.
```
rpm -ql httpd | grep systemd
```
예상 출력: 이 명령은 서비스 파일을 포함하여 systemd 관련 파일을 나열합니다.
```
/usr/lib/systemd/system/httpd.service
/usr/lib/systemd/system/httpd@.service
...
```
출력 httpd.service는 올바른 서비스 이름이 httpd임을 알려줍니다.
플레이북 수정 및 체크 모드로 다시 실행

이제 올바른 서비스 이름을 알았으므로 service.yml 파일을 편집합니다.
```
nano service.yml
```
서비스 name을 apache2에서 httpd로 변경합니다.
```
## ... (rest of the file)
- name: Ensure web server service is started
  ansible.builtin.service:
    ## FIX: Correct service name for RHEL
    name: httpd
    state: started
    enabled: true
```
편집기를 저장하고 종료합니다. 이제 플레이북을 체크 모드로 다시 실행합니다.
```
ansible-playbook --check service.yml
```
예상 출력 (체크 모드 성공): 이번에는 플레이북이 changed 상태를 보고해야 합니다. 체크 모드에서 changed는 "실제 실행이었다면 변경이 발생했을 것"을 의미합니다. 이는 플레이북 로직이 올바르게 되었고 Ansible 이 httpd 서비스를 시작해야 함을 식별했음을 나타냅니다.
```
TASK [Ensure web server service is started] ************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
```
참고: 이 특정 컨테이너 기반 랩 환경에서는 완전한 systemd init 시스템이 실행되지 않습니다. 체크 모드는 올바르게 작동하지만 ansible.builtin.service 모듈의 정상 실행은 여전히 문제가 발생할 수 있습니다. 여기서 핵심 교훈은 체크 모드를 사용하여 플레이북의 로직을 시스템 구성에 대해 검증하는 것입니다.

방화벽 구성 및 호스트 연결 불가 문제 수정

이 마지막 단계에서는 방화벽과 같은 잘못된 시스템 구성으로 인한 실패 및 Ansible 인벤토리 파일의 오류로 인한 연결 문제와 같은 두 가지 중요한 런타임 문제를 해결합니다. 이를 숙달하면 자동화에서 가장 일반적인 장애물을 해결하는 데 도움이 됩니다.

파트 1: 방화벽 구성 수정

서버 구성의 일반적인 작업은 방화벽에서 포트를 여는 것입니다. 플레이북이 대상 시스템에 존재하지 않는 방화벽 서비스를 참조하면 실패할 수 있습니다.

firewalld 설치 및 준비

먼저 RHEL 에서 방화벽 관리 서비스를 제공하는 firewalld 패키지가 설치되어 있는지 확인합니다.
```
sudo dnf install -y firewalld
```
firewalld 서비스를 시작합니다.
```
sudo systemctl start firewalld
```
이 연습에서 사용되는 firewalld 모듈을 포함하는 ansible.posix 컬렉션을 설치해야 합니다.
```
ansible-galaxy collection install ansible.posix
```
참고: Ansible 버전 호환성에 대한 경고가 표시될 수 있지만 컬렉션은 이 연습에서 올바르게 작동합니다.
방화벽 오류가 있는 플레이북 생성

firewalld 서비스를 사용하도록 설정하려는 새 플레이북 firewall.yml을 생성합니다. 그러나 오류를 트리거하기 위해 의도적으로 잘못된 서비스 이름인 web을 사용합니다.
```
nano firewall.yml
```
편집기에 다음 내용을 복사하여 붙여넣습니다.
```
---
- name: Configure System Firewall
  hosts: localhost
  become: true
  tasks:
    - name: Allow web traffic through firewall
      ansible.posix.firewalld:
        ## ERROR: 'web' is not a standard firewalld service
        service: web
        permanent: true
        state: enabled
```
nano를 저장하고 종료합니다 (Ctrl+X, Y, Enter).

플레이북 실행 및 실패 진단

플레이북을 실행합니다. firewalld가 web이라는 이름의 서비스를 인식하지 못하므로 실패합니다.

ansible-playbook firewall.yml

예상 출력 (오류): 오류 메시지는 web이 지원되는 서비스가 아니라고 명확하게 표시하여 문제점을 직접적으로 알려줍니다.

TASK [Allow web traffic through firewall] **************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "web is not a supported service. This is what I have."}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

올바른 방화벽 서비스 이름 찾기

유효한 사전 정의된 서비스 이름 목록을 찾으려면 firewall-cmd 명령줄 도구를 사용할 수 있습니다.
```
firewall-cmd --get-services
```
예상 출력: 사용 가능한 서비스의 긴 목록이 표시됩니다. 웹 트래픽에 대한 올바른 서비스인 http를 찾기 위해 목록을 살펴봅니다.
```
RH-Satellite-6 ... ftp http https imaps ipp ipp-client ...
```
플레이북 수정 및 성공적으로 실행

firewall.yml을 편집하고 잘못된 서비스 이름 web을 올바른 이름인 http로 바꿉니다.
```
nano firewall.yml
```
수정된 작업은 다음과 같이 표시됩니다.
```
## ... (rest of the file)
- name: Allow web traffic through firewall
  ansible.posix.firewalld:
    ## FIX: Use the correct firewalld service name
    service: http
    permanent: true
    state: enabled
```
저장하고 종료합니다. 이제 플레이북을 다시 실행합니다. 성공적으로 완료되어야 합니다.
```
ansible-playbook firewall.yml
```

파트 2: 호스트 도달 불가능 오류 문제 해결

"unreachable" 오류는 Ansible 이 인벤토리에 나열된 호스트에 연결할 수 없음을 의미합니다. 이는 종종 호스트 이름의 간단한 오타로 인해 발생합니다.

도달 불가능한 호스트 시뮬레이션

의도적으로 inventory 파일에 오타를 도입하고 로컬 연결 설정을 제거합니다. 이렇게 하면 Ansible 이 잘못 입력된 호스트 이름으로 실제 네트워크 연결을 시도하도록 강제됩니다.
```
nano inventory
```
localhost를 localhossst로 변경하고 ansible_connection=local을 제거합니다.
```
## ERROR: Intentional typo in hostname, no local connection
localhossst
```
편집기를 저장하고 종료합니다.
플레이북 수정하여 인벤토리 호스트 사용

먼저 webserver.yml 플레이북을 수정하여 하드코딩된 localhost 대신 인벤토리 호스트를 사용하도록 해야 합니다. 플레이북이 hosts: localhost를 사용할 때 Ansible 은 이를 특수 사례로 취급하고 인벤토리 파일을 완전히 건너뜁니다.
```
nano webserver.yml
```
hosts 줄을 localhost에서 all로 변경합니다.
```
---
- name: Configure Web Server
  hosts: all ## Changed from 'localhost' to use inventory hosts
  become: true
  ## ... rest of the playbook remains the same
```
편집기를 저장하고 종료합니다.

플레이북 실행하여 오류 트리거

이제 수정된 플레이북을 실행해 봅니다. 인벤토리에 localhossst 오타가 포함되어 있으므로 실패합니다.

ansible-playbook webserver.yml

예상 출력 (오류): Ansible 이 실패하고 호스트를 UNREACHABLE로 보고합니다. 오류 메시지는 호스트 이름을 확인할 수 없음을 나타냅니다.

PLAY [Configure Web Server] ****************************************************

TASK [Gathering Facts] **********************************************************
fatal: [localhossst]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname localhossst: Name or service not known", "unreachable": true}

PLAY RECAP *********************************************************************
localhossst                : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

인벤토리 파일 수정

UNREACHABLE 상태는 호스트 이름 및 네트워크 연결을 다시 확인해야 함을 나타냅니다. 이 경우 inventory 파일의 오타를 수정하는 것이 해결책입니다.
```
nano inventory
```
localhossst를 localhost로 다시 변경합니다.
```
## FIX: Corrected hostname
localhost ansible_connection=local
```
저장하고 종료합니다. ansible-playbook webserver.yml을 다시 실행하면 이제 성공합니다.
선택 사항: 원본 플레이북 복원

향후 연습을 위해 플레이북을 hosts: localhost를 사용하도록 복원하려면 다음과 같이 변경할 수 있습니다.
```
nano webserver.yml
```
hosts 줄을 localhost로 다시 변경합니다.
```
---
- name: Configure Web Server
  hosts: localhost ## Restored to original
  become: true
  ## ... rest of the playbook
```
저장하고 종료합니다. 이 단계는 하드코딩된 localhost(인벤토리를 건너뜁니다) 를 사용하는 것과 인벤토리 정의 호스트를 사용하는 것의 차이를 보여줍니다.

요약

이 실습에서는 ansible-core를 설치하고 로깅을 구성하여 Red Hat Enterprise Linux 환경을 Ansible 에 준비한 다음 다양한 일반적인 문제를 해결했습니다. 잘못된 YAML 구문, 들여쓰기, Jinja2 따옴표 및 잘못된 템플릿 경로 수정과 같은 플레이북 내의 오류를 진단하고 해결하는 방법을 배웠습니다. 이러한 기술은 유효하고 안정적인 자동화 코드를 작성하는 데 필수적입니다.

또한 관리 대상 호스트 환경과 관련된 문제를 해결했습니다. Ansible 의 확인 모드를 사용하여 실제 변경 없이 대상 노드에서 잠재적인 서비스 실패를 식별하기 위해 안전하게 드라이런을 수행했습니다. 이 실습은 방화벽 구성을 수정하여 호스트 도달 불가능 문제를 해결함으로써 제어 노드에서 관리 대상 호스트까지 포괄적인 디버깅 접근 방식을 제공하는 연결 문제를 해결하는 것으로 마무리되었습니다.

RHEL 에서 Ansible 플레이북 및 호스트 문제 해결

소개