What the Exam Actually Asks

한 줄 요약

RHCE 가 실제로 묻는 것은 Ansible 문법이 아니라 RHEL 을 원하는 상태로 만들 수 있는가입니다. 그래서 감점은 시스템 쪽에 몰립니다.

왜 문법이 아니라 시스템인가

RHCE(EX294)는 Ansible 시험처럼 보이지만, 실제로 묻는 것은 RHEL 시스템을 원하는 상태로 만들 수 있는가입니다. 그래서 감점이 나는 자리가 문법이 아니라 시스템 쪽에 몰려 있습니다.

started 와 enabled

state: started    # 지금 돌고 있는가
enabled: true     # 재부팅 후에도 뜨는가

두 개는 다른 이야기입니다. started 만 쓰면 채점 순간에는 통과합니다. 재부팅하면 사라지고, 재부팅은 보통 새벽에 일어납니다.

firewalld 의 두 세계

firewalld 는 지금 도는 규칙(runtime) 과 파일에 적힌 규칙(permanent) 을 따로 관리합니다.

준 것	결과	증상
permanent 만	파일에는 적히는데 지금은 안 열림	"설정했는데 왜 안 되지"
immediate 만	지금은 열리는데 재시작하면 사라짐	"어제는 됐는데"
둘 다	완성

SELinux 는 조용히 막는다

SELinux 가 막으면 애플리케이션에는 평범한 오류로 보입니다. connection refused 거나 403 입니다. 파일 권한은 멀쩡하니 더 헷갈립니다.

그리고 불리언에 persistent: true 를 빠뜨리면 지금만 켜지고 재부팅 때 되돌아갑니다. 되돌아간 뒤의 증상이 처음과 똑같아서, 고쳤다고 믿은 채 같은 장애를 다시 겪습니다.

파일 컨텍스트는 두 단계입니다. sefcontext 는 규칙만 등록하고, 이미 있는 파일에 붙이려면 restorecon 을 따로 돌려야 합니다.

멱등은 믿음이 아니라 숫자다

"멱등하게 썼다" 는 믿음이고, "두 번째 실행의 changed 가 0 이다" 는 사실입니다. 후자만 의미가 있습니다.

깨는 원인은 거의 언제나 둘입니다.

1. 조건 없는 command/shell — 언제나 changed 입니다. creates: 나 changed_when: 으로 조건을 주세요.
2. 매번 달라지는 템플릿 — 시각이나 난수를 넣으면 내용이 계속 바뀝니다. 그러면 핸들러가 매번 서비스를 재시작해, 아무것도 안 바뀌었는데 배포마다 중단이 생깁니다.

시험장에서 시간을 잃는 자리

RHCE 는 아는 것을 못 써서 떨어지기보다 시간이 모자라서 떨어진다. 그래서 절차를 미리 정해 두는 것이 지식만큼 중요하다.

인벤토리와 접속을 가장 먼저 확인한다. 플레이북을 아무리 잘 써도 대상에 못 붙으면 0점이다. ansible all -m ping 한 번으로 전부 응답하는지 보고, 권한 상승이 되는지도 함께 확인한다. 이 확인에 드는 1분이 나중에 "왜 안 되지" 로 잃을 20분을 막는다.

문서를 어디서 볼지 정해 둔다. 모듈 옵션 이름은 외우는 것이 아니라 ansible-doc 으로 찾는 것이다. 다만 찾는 데 시간이 걸리므로, 자주 쓰는 것(package, service, copy, template, lineinfile, user, firewalld, seboolean)은 손에 익혀 두고 나머지만 찾는다.

한 문제를 끝내면 그 자리에서 검증한다. 나중에 몰아서 확인하면 어느 문제에서 무엇이 틀렸는지 다시 찾아야 한다. 서비스를 다뤘으면 systemctl is-enabled 까지, 방화벽을 다뤘으면 firewall-cmd --list-all 까지 그 자리에서 본다.

막히면 넘어간다. 한 문제에 매달려 있는 동안 풀 수 있었던 두 문제가 지나간다. 넘어갈 때는 무엇을 남겨 뒀는지 적어 두고, 남는 시간에 돌아온다.

그리고 마지막에 반드시 시간을 남겨 재부팅 후 상태를 확인한다. 이것이 이 모듈에서 계속 말한 영속성 문제를 잡는 유일한 방법이다. 재부팅할 시간이 없다면 최소한 systemctl is-enabled 와 firewalld 의 permanent 목록만이라도 훑는다. 실무에서도 똑같다. "지금 되는 것" 과 "재부팅 뒤에도 되는 것" 은 다른 상태이고, 그 차이는 언제나 가장 나쁜 시각에 드러납니다.

실무에서 진짜 중요한 것

상태를 바꾸는 모듈에는 언제나 영속 여부를 함께 적습니다. state: started 에는 enabled: true 를, firewalld 에는 permanent 와 immediate 를, SELinux 불리언에는 persistent: true 를 짝지어 둡니다. 빠뜨리면 지금은 통과하고 재부팅 뒤에 사라지는데, 재부팅은 보통 새벽에 일어납니다.

멱등은 두 번째 실행의 changed 가 0 인 것으로만 증명합니다. 깨는 원인은 거의 언제나 조건 없는 command/shell 과 매번 달라지는 템플릿 둘입니다. 후자가 특히 나쁩니다 — 핸들러가 매번 서비스를 재시작해서, 아무것도 안 바뀌었는데 배포마다 중단이 생깁니다.

SELinux 가 막으면 애플리케이션 오류처럼 보입니다. connection refused 나 403 으로 나타나고 파일 권한은 멀쩡하니, 원인을 찾기까지 가장 오래 걸립니다. sefcontext 는 규칙만 등록한다는 것도 함께 기억해야 합니다 — 이미 있는 파일에 붙이려면 restorecon 을 따로 돌려야 합니다.

다음 실습은 AlmaLinux 9 VM 에서 돕니다. SELinux 가 Enforcing 이고 firewalld 가 살아 있어서, 위의 것들을 빠뜨리면 실제로 막힙니다.