LabHub

RHEL 계열 관리 · RHCE — Ansible 로 RHEL 을 다룬다 · 이론

시험이 실제로 묻는 것

LabHub 에서 이어서 보기

한 줄 요약

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. 매번 달라지는 템플릿 — 시각이나 난수를 넣으면 내용이 계속 바뀝니다. 그러면 핸들러가 매번 서비스를 재시작해, 아무것도 안 바뀌었는데 배포마다 중단이 생깁니다.

실무에서 진짜 중요한 것

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

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

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

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