Red Hat Certified Engineer (RHCE) #3 설정 파일과 연결: ansible.cfg, ssh, become

#2 Inventory에서 Ansible이 어떤 호스트를 다룰지 정의했다면, 이번에는 Ansible이 그 호스트에 어떻게 연결하고 어떤 권한으로 작업하는지를 정합니다. 그 중심에 있는 것이 설정 파일인 ansible.cfg, SSH 키 기반 연결, 그리고 권한 상승을 담당하는 become입니다. 이 세 가지가 맞물려야 제어 노드에서 작성한 플레이북이 관리 노드에서 의도대로 실행됩니다.

ansible.cfg는 Ansible의 거의 모든 기본 동작을 바꾸는 스위치판입니다. 어떤 inventory를 쓸지, 어떤 사용자로 접속할지, 권한을 어떻게 올릴지가 모두 이 파일 한 장에 담깁니다. 시험에서는 프로젝트 디렉터리마다 전용 ansible.cfg를 두고 become까지 구성하는 유형이 단골로 나오므로, 탐색 우선순위와 주요 항목을 정확히 외워 두겠습니다.

ansible.cfg 탐색 우선순위 #

Ansible은 실행될 때 설정 파일을 정해진 순서로 찾고, 가장 먼저 발견한 한 장만 사용합니다. 여러 곳에 파일이 있어도 합쳐지지 않고, 우선순위가 높은 파일이 나머지를 완전히 가립니다. 탐색 순서는 다음과 같습니다.

여기서 시험에 직접 연결되는 핵심은 현재 디렉터리의 ./ansible.cfg가 홈과 시스템 설정을 모두 이긴다는 점입니다. 그래서 프로젝트 디렉터리마다 전용 ansible.cfg를 두면, 그 디렉터리에서 명령을 실행하는 동안에는 항상 의도한 설정이 적용됩니다. 시험에서 “이 디렉터리에서 작업하라"고 지정하면, 그 디렉터리에 ansible.cfg를 만드는 것이 정석입니다.

현재 어떤 설정 파일이 실제로 적용되는지는 다음 명령으로 확인합니다.

ansible --version

출력의 config file 줄에 실제로 읽힌 파일 경로가 표시됩니다. 의도한 ansible.cfg가 아닌 다른 경로가 보이면, 현재 디렉터리나 환경 변수를 다시 점검하겠습니다.

보안 주의: 현재 디렉터리 설정 #

현재 디렉터리의 ansible.cfg를 읽으려면, 그 디렉터리가 다른 사용자가 쓸 수 없는 상태여야 합니다. world-writable 디렉터리에 있는 ansible.cfg는 보안상 무시되고 경고가 출력됩니다. 시험에서 직접 만든 프로젝트 디렉터리는 보통 문제가 없지만, 공용 경로에서 작업할 때는 권한을 확인하는 편이 안전합니다.

ansible.cfg 주요 설정 #

설정 파일은 [섹션] 아래에 키 = 값 형식으로 항목을 나열하는 INI 구조입니다. RHCE에서 자주 쓰는 섹션은 [defaults]와 [privilege_escalation] 두 가지입니다.

[defaults] 섹션 #

[defaults]는 inventory 위치, 접속 사용자, 키 검사 정책 등 가장 기본적인 동작을 정의합니다.

각 항목을 조금 더 살펴보겠습니다.

• inventory. 이 값을 지정하면 -i 옵션 없이도 항상 같은 inventory를 사용합니다. 프로젝트 디렉터리의 inventory 파일을 가리키게 두면 명령이 짧아집니다.
• remote_user. 시험에서는 보통 일반 사용자로 접속한 뒤 become으로 권한을 올리므로, root가 아니라 작업 계정을 지정합니다.
• host_key_checking. 새로 만든 관리 노드에 처음 접속할 때 나오는 호스트 키 확인 프롬프트를 막아 플레이북이 멈추지 않게 합니다. 실무에서는 보안상 켜 두는 편이지만, 실습 환경에서는 흔히 false로 둡니다.
• roles_path. #11 Role에서 다룰 role을 프로젝트 안의 특정 디렉터리에서 찾게 하려면 이 값을 지정합니다.

[privilege_escalation] 섹션 #

[privilege_escalation]은 일반 사용자로 접속한 뒤 어떻게 root 권한으로 작업할지를 정의합니다. become 관련 설정이 모두 여기에 모입니다.

• become = true로 두면 플레이북의 모든 작업이 기본적으로 권한 상승 상태로 실행됩니다. 패키지 설치나 서비스 관리처럼 root가 필요한 작업이 대부분인 RHCE에서는 이 값을 켜 두는 경우가 많습니다.
• become_method. RHEL에서는 거의 항상 sudo를 씁니다.
• become_user. 특정 task만 다른 계정이 되어야 할 때는 task 수준에서 따로 지정하고, 전역 기본은 보통 root로 둡니다.
• become_ask_pass. sudo가 비밀번호를 요구하면 true로 두거나, 명령 실행 시 -K 옵션으로 입력합니다.

SSH 키 기반 연결 #

Ansible은 SSH로 관리 노드에 접속합니다. 매번 비밀번호를 입력하지 않고 플레이북을 자동으로 돌리려면, SSH 공개 키를 관리 노드에 등록해 키 기반 인증을 구성합니다. 이것이 RHCE 환경 구성의 첫 단추입니다.

1) 키 쌍 생성 #

제어 노드에서 키 쌍이 없다면 먼저 만듭니다.

ssh-keygen

기본 경로(~/.ssh/id_rsa, ~/.ssh/id_rsa.pub)와 빈 passphrase로 생성하면, 추가 입력 없이 자동 접속할 수 있습니다.

2) 공개 키 배포 #

생성한 공개 키를 각 관리 노드로 복사합니다.

ssh-copy-id devops@node1.example.com

ssh-copy-id는 공개 키를 대상 호스트의 ~/.ssh/authorized_keys에 자동으로 추가합니다. 이 단계에서만 한 번 비밀번호를 입력하면, 이후로는 키로 접속합니다. 관리 노드가 여러 대면 각 호스트에 동일하게 실행합니다.

3) 접속 사용자 지정 #

Ansible이 어떤 사용자로 접속할지는 ansible.cfg의 remote_user로 정하거나, inventory에서 호스트별로 ansible_user를 지정합니다.

[webservers]
node1.example.com ansible_user=devops
node2.example.com ansible_user=devops

inventory의 ansible_user는 해당 호스트에만 적용되고, ansible.cfg의 remote_user보다 우선합니다. 호스트마다 접속 계정이 다를 때 유용합니다.

become으로 권한 상승 #

키 기반으로 접속하는 계정은 보통 일반 사용자입니다. 패키지 설치, 서비스 재시작, 시스템 파일 수정처럼 root 권한이 필요한 작업은 become으로 sudo 권한을 빌려 처리합니다.

become을 켜는 방법은 세 가지 수준이 있습니다.

1) ansible.cfg에서 전역 설정 #

앞서 본 [privilege_escalation]의 become = true가 가장 넓은 범위입니다. 이 디렉터리에서 실행하는 모든 플레이북과 ad-hoc 명령이 기본으로 권한을 상승합니다.

2) play나 task 수준에서 설정 #

플레이북 안에서 play 전체 또는 개별 task에 become을 지정할 수 있습니다.

- name: 웹 서버 구성
  hosts: webservers
  become: true
  tasks:
    - name: httpd 설치
      ansible.builtin.dnf:
        name: httpd
        state: present

    - name: 로그 확인은 일반 사용자로
      ansible.builtin.command: whoami
      become: false

play에 become: true를 두면 그 play의 모든 작업이 권한을 상승하고, 특정 작업만 become: false로 두면 그 작업만 원래 계정으로 실행됩니다. 작업별 become이 play 설정을 덮어쓰므로, 예외가 필요한 작업만 따로 지정하면 됩니다.

특정 작업을 root가 아닌 다른 계정으로 실행하려면 become_user를 작업에 붙입니다.

    - name: postgres 사용자로 작업
      ansible.builtin.command: psql -c "SELECT 1"
      become: true
      become_user: postgres

3) 명령행 옵션으로 설정 #

설정 파일을 바꾸지 않고 일회성으로 권한을 올릴 때는 명령행 옵션을 씁니다.

ansible-playbook site.yml --become -K

• --become(또는 -b). 이번 실행에 한해 권한 상승을 켭니다.
• -K(--ask-become-pass). sudo 비밀번호를 한 번 물어봅니다. 대상 계정의 sudo가 비밀번호를 요구할 때 필요합니다.

관리 노드의 sudo가 비밀번호 없이 동작하도록 NOPASSWD로 설정되어 있으면 -K 없이도 됩니다. 시험 환경에서는 작업 계정에 비밀번호 없는 sudo가 미리 구성되어 있는 경우가 많지만, 그렇지 않다면 -K나 become_ask_pass로 비밀번호를 전달하겠습니다.

연결 테스트 #

설정과 키, become까지 갖췄다면 실제로 연결되는지 확인합니다. ping 모듈이 가장 빠른 점검 도구입니다.

ansible all -m ping

ansible의 ping 모듈은 ICMP가 아니라 SSH로 접속해 Python이 동작하는지까지 확인하는 모듈입니다. 모든 호스트에서 다음과 비슷한 응답이 나오면 연결이 정상입니다.

node1.example.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

권한 상승까지 점검하려면 become을 켜고 현재 사용자를 확인합니다.

ansible all -m command -a "whoami" --become

모든 호스트가 root를 반환하면 become이 정상 동작하는 것입니다. UNREACHABLE이 나오면 SSH 키나 ansible_user를, sudo 관련 오류가 나오면 become 설정이나 -K 여부를 점검하겠습니다.

프로젝트 전체 예제 #

지금까지 다룬 내용을 하나의 프로젝트로 묶어 보겠습니다. 작업 디렉터리에 ansible.cfg와 inventory를 함께 두는 구조가 시험의 표준 형태입니다.

ansible.cfg는 다음과 같이 작성합니다.

[defaults]
inventory = ./inventory
remote_user = devops
host_key_checking = false
roles_path = ./roles

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

같은 디렉터리의 inventory는 다음과 같습니다.

[webservers]
node1.example.com
node2.example.com

[dbservers]
node3.example.com

이 디렉터리에서 명령을 실행하면 ./ansible.cfg가 자동으로 적용되어, -i 옵션이나 --become 없이도 의도한 inventory와 권한 상승이 그대로 동작합니다.

ansible all -m ping
ansible all -m command -a "whoami"

whoami 결과가 모두 root라면, ansible.cfg의 become = true가 적용되었다는 뜻입니다. 프로젝트 디렉터리 하나에 설정과 inventory를 모아 두면, 그 디렉터리 안에서는 항상 같은 환경이 재현됩니다.

시험 포인트 #

• 프로젝트별 ansible.cfg. 시험은 보통 특정 작업 디렉터리를 지정합니다. 그 디렉터리에 ansible.cfg를 만들어 inventory, remote_user, become을 명시하는 것이 정석입니다. ./ansible.cfg가 홈과 시스템 설정을 모두 이깁니다.
• become 설정. RHCE 작업 대부분이 root 권한을 요구하므로, [privilege_escalation]에 become = true를 두는 구성이 자주 나옵니다. 특정 task만 예외가 필요하면 task 수준에서 become: false나 become_user로 조정합니다.
• 연결 확인. 환경을 꾸린 직후에는 ansible all -m ping으로 SSH 연결을, --become을 붙인 whoami로 권한 상승을 함께 점검하겠습니다.
• 적용 설정 확인. ansible --version의 config file 줄로 실제로 읽힌 ansible.cfg가 의도한 파일인지 확인하는 습관이 사소한 실수를 막습니다.
• host_key_checking. 새 관리 노드에서 호스트 키 프롬프트로 플레이북이 멈추지 않도록 false로 두는 경우가 많습니다.

정리 #

이번 글에서 잡은 것:

• ansible.cfg 우선순위. ANSIBLE_CONFIG 환경 변수, 현재 디렉터리, 홈 디렉터리, /etc/ansible 순으로 찾고 가장 먼저 발견한 한 장만 적용
• 주요 설정. [defaults]의 inventory,remote_user,host_key_checking,roles_path, [privilege_escalation]의 become,become_method,become_user,become_ask_pass
• SSH 키 연결. ssh-keygen으로 키를 만들고 ssh-copy-id로 배포, remote_user나 inventory의 ansible_user로 접속 계정 지정
• become. ansible.cfg 전역, play와 task 수준, 명령행 --become -K 세 가지 방식으로 sudo 권한 상승
• 연결 테스트. ansible all -m ping으로 연결을, --become을 붙인 whoami로 권한 상승을 확인

다음: ad-hoc 명령 #

연결과 권한까지 갖췄으니, 이제 플레이북을 작성하기 전에 모듈을 즉석에서 실행해 보겠습니다.

#4 ad-hoc 명령: 모듈 즉석 실행에서는 ansible 명령으로 모듈을 한 줄로 실행하는 방법, 자주 쓰는 모듈(command,shell,copy,file,dnf,service), 그리고 빠른 점검과 일회성 작업에 ad-hoc을 활용하는 감각을 정리하겠습니다.