• 목록

1. Ansible 출력 기록하기

이 게시글에서는 Ansible 출력 기록하기에 대한 문서를 살펴보고, 예시만 안내드리는 글입니다.

Ansible은 서버 환경을 자동화하고 관리하는 매우 유용한 도구입니다. 특히 다수의 서버에 대해 동일한 작업을 반복해서 수행할 때 큰 이점을 제공하죠. 하지만 이런 환경에서 무언가 잘못되었을 때, 어떤 일이 발생했는지 알기 위해선 로그가 중요합니다. 기본적으로 Ansible은 플레이북을 실행한 후의 결과를 제어 노드의 STDOUT에 출력합니다. 그러나 이렇게 출력된 정보를 별도로 로그 파일로 저장하는 기능은 자동화된 환경에서 필수적인 요구사항 중 하나입니다.

Ansible에서는 출력된 정보를 로그로 남기기 위한 몇 가지 방법을 제공합니다. 제어 노드에서 단일 로그 파일을 생성할 수도 있고, 각 관리 노드별로 개별 로그를 남길 수도 있습니다. 또한 Ansible Tower를 이용하면 더욱 심층적인 로그 관리와 데이터를 제공받을 수 있죠. 아래에서 각각의 방법에 대해 구체적으로 살펴보겠습니다.

1.1. 단일 로그 파일로 Ansible 출력 저장하기

Ansible의 출력 정보를 제어 노드에서 단일 로그로 관리하려면, 설정 파일에서 log_path 옵션을 사용합니다. 이 설정을 통해 Ansible에서 출력된 모든 정보를 한 곳에 모아둘 수 있습니다. 특히, 여러 서버에서 동일한 작업을 수행할 경우 이 방법이 유용할 수 있습니다.

log_path 설정을 추가하는 방법은 다음과 같습니다:

```bash

 sudo vi /etc/ansible/ansible.cfg

```

ansible.cfg 파일을 열고 다음과 같은 설정을 추가합니다:

```cfg

 [defaults]

 log_path = /var/log/ansible.log

```

이렇게 설정하면 Ansible의 모든 출력이 /var/log/ansible.log 파일에 기록됩니다. 해당 명령을 실행할 시 모든 작업 로그를 한 곳에서 확인할 수 있어 디버깅과 관리가 용이해집니다. 또한, 유사한 작업을 구분하기 위해 display_args_to_stdout 설정을 추가로 적용할 수 있습니다. 이 설정은 출력 시 변수 값을 포함해 유사한 태스크를 명확하게 구분해줍니다.

```cfg

 display_args_to_stdout = True

```

1.2. 관리 노드별로 개별 로그 저장하기

단일 로그 파일로 관리하는 것이 아니라 각 관리 노드별로 개별 로그를 저장하고 싶은 경우, no_target_syslog 및 syslog_facility 설정을 이용하면 됩니다. 이 방법을 사용하면 각 노드에서 별도의 로그 파일을 생성하여 서버별로 작업 내역을 독립적으로 확인할 수 있습니다.

설정을 위해서는 다음과 같이 ansible.cfg 파일을 수정합니다:

```cfg

 [defaults]

 no_target_syslog = True

 syslog_facility = LOCAL1

```

위와 같이 설정한 경우, 각 관리 노드는 독립적으로 LOCAL1에 로그를 기록하게 됩니다. 이 방법은 특히 복잡한 네트워크 환경에서 각 서버별 로그를 따로 관리해야 할 때 매우 유용합니다. 각 관리 노드에서 발생한 문제를 빠르게 파악하고 해결하는 데 큰 도움이 될 수 있습니다.

1.3. Ansible Tower를 이용한 로그 저장

좀 더 고도화된 로그 관리가 필요하다면 Ansible Tower를 활용할 수 있습니다. Ansible Tower는 GUI 기반의 관리 도구로, 모든 작업 내역을 안전한 데이터베이스에 저장할 수 있습니다. 이를 통해 과거 작업 이력을 손쉽게 확인할 수 있으며, 특정 호스트나 프로젝트에 대한 로그를 그래프 또는 REST API로 분석할 수 있습니다.

Ansible Tower는 단순히 로그를 저장하는 것 이상의 기능을 제공합니다. 예를 들어 Tower는 특정 기간 동안의 실행 내역을 기준으로 성능이나 안정성을 분석할 수 있습니다. 추가적으로 다양한 인벤토리와 호스트 그룹별로 작업 이력을 쉽게 비교할 수 있어, 대규모 환경에서는 매우 효과적입니다.

Ansible Tower를 설치하고 사용하는 방법은 공식 문서를 참조하거나 다음과 같은 기본 명령어로 시작할 수 있습니다:

```bash

 ansible-tower-cli job_list

```
```bash

==== ============ =========================== ====== =======

 id  job_template           created           status elapsed

==== ============ =========================== ====== =======

5889           44 2024-05-18T09:00:00.777093Z failed 44.467

5890           44 2024-05-18T11:00:16.195209Z failed 44.279

5891           44 2024-05-18T13:00:01.459862Z failed 44.431

5892           44 2024-05-18T15:00:16.981905Z failed 46.443

5893           44 2024-05-18T17:00:02.596481Z failed 44.527

5894           44 2024-05-18T19:00:18.091572Z failed 44.742

5895           44 2024-05-18T21:00:03.553992Z failed 44.028

5896           44 2024-05-18T23:00:19.066804Z failed 49.068

5897           44 2024-05-19T01:00:04.445344Z failed 45.625

5898           44 2024-05-19T03:00:19.802392Z failed 44.591

5899           44 2024-05-19T05:00:05.142273Z failed 44.608

5900           44 2024-05-19T07:00:20.421560Z failed 45.54

5902           44 2024-05-19T09:00:05.758622Z failed 44.27

5903           44 2024-05-19T11:00:21.585323Z failed 45.532

5904           44 2024-05-19T13:00:06.912870Z failed 44.43

5905           44 2024-05-19T15:00:21.992404Z failed 44.232

5906           44 2024-05-19T17:00:07.479634Z failed 44.142

5907           44 2024-05-19T19:00:22.918508Z failed 44.045

5908           44 2024-05-19T21:00:08.275273Z failed 45.267

5909           44 2024-05-19T23:00:23.671440Z failed 44.249

5910           44 2024-05-20T01:00:09.046858Z failed 44.27

5911           44 2024-05-20T03:00:24.474527Z failed 44.193

5912           44 2024-05-20T05:00:09.641346Z failed 44.339

5913           44 2024-05-20T07:00:24.933178Z failed 45.015

5914           44 2024-05-20T09:00:10.131656Z failed 44.248

==== ============ =========================== ====== ======= (Page 1 of 19.)

```

 

위 명령을 사용하면 현재 실행된 작업 목록을 확인할 수 있으며, 더 나아가 특정 작업의 상세 로그도 조회할 수 있습니다. 이 기능은 복잡한 환경에서 발생하는 문제를 쉽게 추적하는 데 매우 유용합니다.

1.4. no_log로 민감한 데이터 보호하기

Ansible을 사용하는 환경에서는 종종 비밀번호나 API 키와 같은 민감한 데이터가 로그에 포함될 수 있습니다. 이런 민감한 정보를 보호하기 위해서는 no_log 속성을 사용할 수 있습니다. 특정 태스크에 no_log: True 속성을 추가하면 해당 태스크에서 출력되는 민감한 데이터가 로그에 기록되지 않도록 할 수 있습니다.

예를 들어, 비밀번호를 설정하는 작업이 있다면 이를 로그에서 숨기기 위해 다음과 같이 설정할 수 있습니다:

```yaml

 - name: Set password for the user

   user:

      name: john_doe

      password: "{{ 'password123' | password_hash('sha512') }}"

   no_log: True

```

이 속성을 적용하면 Ansible 출력 로그에 비밀번호가 기록되지 않으며, 보안 문제를 방지할 수 있습니다. 하지만 no_log 속성은 디버깅 출력에는 적용되지 않기 때문에, 실제 운영 환경에서는 디버깅 모드를 해제하고 작업하는 것이 중요합니다. 디버깅 모드를 활성화한 채로 작업을 수행하면 민감한 데이터가 노출될 수 있습니다.

1.5. 결론

Ansible 출력 로그를 관리하는 방법은 자동화된 서버 환경에서 매우 중요한 부분입니다. 특히 로그를 어떻게 설정하고 관리하느냐에 따라 장애 발생 시 문제 해결의 속도가 크게 달라질 수 있습니다. 제어 노드에서 단일 로그로 관리하거나, 각 관리 노드에서 개별 로그를 관리하는 방법을 선택할 수 있으며, 고급 로그 관리가 필요할 경우 Ansible Tower를 활용하는 것도 좋은 방법입니다. 무엇보다 민감한 정보가 포함된 로그는 no_log 속성을 통해 반드시 보호해야 하며, 운영 환경에서는 디버깅을 주의해야 합니다.