운영을 잇다 04 — Zabbix·AWX·NetBox 운영 매뉴얼
AI_Manager
서버가 설치됐다는 것과 운영할 준비가 됐다는 것은 다르다. 운영자는 이상 징후를 발견하고, 영향을 받는 자산을 확인하고, 승인된 작업을 실행한 뒤 정상 복구를 확인해야 한다. 이 글은 앞서 구성한 실습 환경을 대상으로 관제 → 판단 → 작업 → 확인 → 보고를 반복하는 방법을 정리한 운영 매뉴얼이다.
Zabbix에서 상태를 보고, NetBox에서 자산과 관리 주소를 확인하며, AWX에서 Git에 저장한 작업을 실행한다. 도구별 기능 소개보다 실제 메뉴에서 무엇을 설정하고 어떤 결과를 확인해야 하는지에 초점을 맞췄다. 메뉴는 영문 이름을 함께 표기했으며 화면 언어에 따라 번역은 다를 수 있다.
1. 적용 환경과 이 매뉴얼의 범위
기준 구성은 Rocky Linux 10.2, Zabbix 7.0.30 LTS, NetBox 4.7.1, AWX 24.6.1이다. 중앙 두 노드, quorum, PROD·DEV·STG의 Proxy 겸 Bastion, PXE 설치와 Git 기반 자동화를 사용한다. 모두 한 PC의 VirtualBox 위에 있으므로 물리 PC 전체 장애를 견디는 구성은 아니다.
| 구분 | 현재 구성에서 확인된 내용 | 이 매뉴얼에서 추가로 설정하는 예시 |
|---|---|---|
| Zabbix | 환경별 Proxy, Active Agent, 기본 Linux 템플릿, 실제 값 수집 | 운영 대시보드, 조직별 임계값, 알림 정책, 보고 일정 |
| AWX | Project, 승인 인벤토리, NetBox 인벤토리, Onboard·Verify·Workflow | 운영자 권한 분리, 정기 점검 일정, 승인 단계 |
| NetBox | VM·인터페이스·IP 등록, 환경·수집 상태 구분, AWX 동기화 | 담당자·랙·유지보수 정보, 자산 수명주기 절차 |
| 정기 보고 | 메일 발송이나 PDF 보고 성공을 검증한 기록은 없음 | 보고용 서비스, SMTP, 수신자, 일일·주간·월간 보고 설정 |
아래 대시보드와 트리거, 보고 일정은 운영을 시작하기 위한 설정안이다. 이미 실습에 적용하고 검증한 화면으로 소개하지 않는다. 기존 자동화의 실제 객체 이름과 동작은 구축 소스에 맞췄다. 새 설정은 DEV에서 확인한 뒤 STG와 PROD에 적용한다.
2. 접속과 역할 분담: 어디에서 무엇을 바꾸는가
| 도구 | 내부 접속 주소 | 운영자가 하는 일 |
|---|---|---|
| Zabbix | https://zabbix.fullmoon.test |
문제 확인, 최신 데이터·그래프 조회, 알림·점검 기간 관리 |
| NetBox | https://netbox.fullmoon.test |
자산 종류·관리 IP·환경·담당 정보 확인과 변경 기록 |
| AWX | https://awx.fullmoon.test |
승인된 템플릿 실행, 작업 결과·실패 원인·Git 커밋 확인 |
| Git | git.fullmoon.test의 승인 저장소 |
플레이북과 인벤토리 변경 이력 관리 |
주소는 인터넷 공개 서비스가 아니라 실습 내부 이름이다. 관리 단말의 내부 DNS 또는 구축 편의 SSH 터널, CA 신뢰 설정이 먼저 준비되어야 한다. 인증서 검증을 끄고 접속하는 방식을 정상 절차로 사용하지 않는다.
화면 조회 담당자는 조회 권한, 작업 담당자는 필요한 AWX 템플릿 실행 권한, 관리자는 템플릿·자격 증명·알림 정책 수정 권한을 갖게 한다. 자동화용 API 계정을 사람이 일상적으로 로그인하는 계정으로 사용하지 않는다. NetBox의 자산 상태를 바꾼다고 Zabbix 알림이나 AWX 예약 작업이 자동으로 모두 정지되는 것도 아니다.
정보의 기준을 나눈다. 승인한 주소·환경은 Git과 NetBox의 검토된 정보, 실제 CPU·OS·서비스 상태는 수집 결과, 장애 상태는 Zabbix, 변경 결과는 AWX 작업 기록으로 확인한다. 화면 간 값이 다르면 어느 쪽을 덮어쓸지부터 결정하지 말고 마지막 변경과 수집 실패 여부를 먼저 확인한다.
3. Zabbix 대시보드: 현재 장애와 용량 추세를 나누어 본다
현재 자동 등록된 대상의 Host group은 FullMoon/Linux다. 호스트에는 environment=PROD, DEV, STG와 managed-by=fullmoon-awx 태그가 붙는다. 이 값을 기준으로 관제 범위를 나눈다. 중앙 서비스와 Proxy 자체의 상세 지표는 별도 호스트·아이템을 등록해야 하며, 아래 배치안에 적었다는 이유로 자동 수집되지는 않는다.
3-1. 관제 대시보드 만들기
Dashboards → Create dashboard에서 FullMoon | 운영 관제를 만들고 편집 모드에서 위젯을 추가한다. 처음에는 화면 하나에서 판단할 수 있도록 다음 순서로 배치한다.
| 위치 | 위젯 | 설정 기준 | 운영자가 읽을 내용 |
|---|---|---|---|
| 맨 위 왼쪽 | Problems by severity | FullMoon/Linux, PROD 태그 |
우선 대응해야 할 문제 규모 |
| 맨 위 오른쪽 | Host availability | FullMoon/Linux, Active Agent 포함 여부 확인 |
수집 경로별 이용 가능 상태 |
| 가운데 전체 | Problems | PROD 태그, 해결되지 않은 문제 중심 | 호스트·심각도·문제명·확인 여부 |
| 아래 왼쪽 | Top hosts | CPU 사용률 아이템, 대상 호스트 범위 지정 | 자원 사용 상위 서버 |
| 아래 오른쪽 | Graph | CPU·메모리·디스크 중 필요한 지표 | 급격한 변화와 지속적인 증가 |
Problems 계열의 태그 필터는 environment가 PROD와 일치하도록 설정한다. Host availability처럼 같은 태그 필터를 제공하지 않는 위젯에는 이를 억지로 적용하지 않는다. 환경별 Host group을 별도로 만들고 소속을 관리하거나, 위젯이 지원하는 호스트 선택 방식으로 범위를 나눈다. 그룹을 새로 만들 때에는 자동 등록 코드와 조회 계정 권한도 함께 정리한다.
같은 구성으로 DEV·STG 관제 페이지를 나누되, PROD와 개발 환경의 문제를 같은 우선순위로 섞지 않는다. 대시보드는 운영 팀에 공유하고 일반 관제자는 조회만 가능하게 한다. 실제 계정으로 로그인해 위젯이 비어 있지 않은지 확인한다. 위젯 구성과 공유 방식은 Zabbix 7.0 대시보드 문서를 기준으로 한다.
3-2. 가용성 아이콘만 보고 정상으로 판단하지 않는다
이 실습은 Active Agent가 같은 환경의 Proxy로 값을 보내는 방식이다. Passive 인터페이스 표시, Active Agent 상태, 실제 값의 갱신은 따로 확인해야 한다. Monitoring → Latest data에서 호스트를 선택하고 system.uptime을 비롯한 값이 계속 갱신되는지 본다. 값이 없거나 수집이 중단된 상태를 CPU 사용률 0%와 같은 정상값으로 해석하지 않는다. 가용성 위젯의 표시 기준도 함께 확인한다.
3-3. 용량 대시보드와 보고용 대시보드
FullMoon | 용량 추세에는 CPU 평균·최대, 메모리 사용률, 파일시스템 사용률과 여유 공간, 네트워크 전송량을 배치한다. CPU 순간 최고값만 보고 증설을 결정하지 않고 반복 여부·부하 시간대·실제 업무 영향을 함께 본다. 디스크는 사용률과 남은 용량을 같이 본다.
보고용은 FullMoon | 일일 보고, FullMoon | 주간 보고, FullMoon | 월간 보고로 분리한다. PDF에서 읽기 쉽도록 한 페이지에 핵심 그래프를 배치한다. 기간을 지원하는 그래프는 Dashboard의 기간을 따르게 설정하고, 고정된 최근 한 시간 같은 위젯 설정이 보고 기간을 가리지 않게 한다. 현재 Problems 목록은 보고 시점의 상태일 수 있으므로, 이를 지난달 전체 장애 건수로 해석하지 않는다.
4. Zabbix 템플릿: 공통 Linux 점검과 조직 점검을 분리한다
기존 대상에는 Linux by Zabbix agent active가 연결되어 있다. CPU·메모리·파일시스템 같은 기본 점검은 이 템플릿을 사용한다. 공통 템플릿을 임의로 고치기 전에 호스트별 매크로와 발견 규칙의 예외 설정으로 해결할 수 있는지 확인한다. 같은 key를 가진 아이템을 다른 템플릿에서 중복 생성하지 않는다.
4-1. 추가 템플릿을 직접 만드는 예시
여기서는 실습 대상의 PXE 설치 완료 표식 파일을 확인하는 FullMoon Operations Checks를 만든다. 기존 Linux 템플릿을 대체하지 않는 추가 점검이다. 표식이 있다는 것만으로 이후의 모든 운영 설정이 정상이라는 뜻은 아니다.
Data collection → Templates → Create template을 연다.- Template name을
FullMoon Operations Checks, Template group을 별도의Templates/FullMoon으로 지정한다. 그룹이 없다면 먼저 만든다. - 설명에 점검 목적·담당자·적용 대상이 “FullMoon PXE로 설치한 Linux 대상”임을 적는다.
- 저장한 템플릿의
Items → Create item에서 아래 항목을 등록한다.
| 항목 | 입력 예시 |
|---|---|
| Name | PXE 설치 완료 표식 |
| Type | Zabbix agent (active) |
| Key | vfs.file.exists[/var/lib/fullmoon-lab/pxe-installed] |
| Type of information | Numeric (unsigned) |
| Update interval | 1m — 예시 수집 주기 |
| History | 7일 — 실습 시작값, 보존 정책에 맞춰 조정 |
| Tags | component=provisioning, scope=configuration |
값 1은 파일 존재, 0은 부재다. 읽기 권한이나 경로 문제로 Unsupported가 되지 않는지 확인한다. Agent key의 의미는 Zabbix Agent 아이템 문서를 참고한다.
Data collection → Hosts → fml-dev-app-01 → Templates에서 추가 템플릿을 연결한다.Latest data에서 실제 값과 갱신 상태를 확인한 뒤 STG·PROD로 적용 범위를 넓힌다.- 템플릿을 YAML로 내보내 Git에 저장하고 변경 이유를 커밋한다. 내보낸 내용에 비밀 매크로가 포함되지 않는지도 확인한다.
템플릿 연결 해제와 “연결 해제 후 지우기”는 결과가 다르다. 기존 항목·이력을 정리하는 옵션을 변경 취소 버튼처럼 사용하지 않는다. 생성·연결·상속의 기본 동작은 템플릿 설정 문서에 따른다.
4-2. 파일시스템과 네트워크는 발견 규칙을 활용한다
서버마다 디스크와 NIC 이름이 다르므로 모든 경로를 수동 아이템으로 늘리지 않는다. 기본 템플릿의 Discovery rules와 item/trigger prototypes를 확인해 실제 발견된 파일시스템과 인터페이스를 점검한다. 일시적인 컨테이너 마운트나 사용하지 않는 인터페이스는 검토 후 필터·매크로·override로 제외한다. 전체 발견 규칙을 끄기보다 제외 이유와 적용 범위를 남긴다.
5. Zabbix 트리거: 언제 문제로 보고 언제 복구로 볼 것인가
아이템은 값을 수집하고, 트리거는 그 값으로 문제를 판정한다. 이벤트가 발생해도 알림 Action이 없거나 수신자 설정이 틀리면 담당자에게 전달되지 않는다. 이 세 단계를 나누어 설정한다.
5-1. 표식 파일 누락 트리거 등록
Data collection → Templates → FullMoon Operations Checks → Triggers → Create trigger를 연다. Name은 PXE 설치 완료 표식이 없습니다, Severity는 시작값으로 Warning을 선택한다. 다음 예시는 표식이 반복해서 없을 때 문제를 만들고, 다시 존재하는 값이 확인되면 복구시키는 조건이다.
문제 조건
max(/FullMoon Operations Checks/vfs.file.exists[/var/lib/fullmoon-lab/pxe-installed],5m)=0
OK event generation: Recovery expression
복구 조건
min(/FullMoon Operations Checks/vfs.file.exists[/var/lib/fullmoon-lab/pxe-installed],1m)=15m, 1m은 판정에 필요한 관찰 구간이다. 데이터가 없는 상태를 파일 부재로 단정하지 않으며, 신규 연결 직후에는 충분한 값이 쌓였는지도 확인한다. 문제 표현식이 참인 동안에는 복구 표현식만 참이 되어도 복구되지 않는다. Single 이벤트 모드를 사용하고, 설명에는 대상 경로와 점검 순서를 적는다. 표현식과 복구 조건은 트리거 설정 문서를 참고한다.
5-2. CPU·메모리·디스크 임계값을 정하는 방법
다음 수치는 운영을 시작할 때 검토할 예시다. 실제 업무 부하·디스크 크기·허용 중단 범위에 따라 바꾼다. 이미 같은 의미의 기본 트리거가 있으면 먼저 그 매크로를 조정하고 동일한 알림을 중복으로 만들지 않는다.
| 항목 | 문제 판정 예시 | 복구·후속 확인 |
|---|---|---|
| CPU | 여러 수집 구간 동안 높은 사용률 유지 | 충분히 낮아진 상태가 지속되는지 확인 |
| 메모리 | 가용 메모리 감소와 swap 증가가 함께 지속 | 실제 프로세스·메모리 압박 해소 확인 |
| 파일시스템 | 사용률 85% 이상과 여유 용량 부족 검토 | 정리 후 여유 공간 확보·증가 추세 확인 |
| 수집 중단 | 정상 수집 주기보다 충분히 긴 구간에 새 값 없음 | Proxy·Agent 경로 복구와 새 값 확인 |
CPU를 별도 트리거로 검토한다면 Latest data에서 해당 아이템 key가 system.cpu.util인지 먼저 확인한다. 예를 들어 평균 90% 초과를 문제로, 75% 미만을 복구로 두면 경계값 주변의 반복 알림을 줄일 수 있다. 기본 템플릿의 기존 트리거와 비교한 후 적용한다.
# 대상과 아이템을 확인한 뒤 사용하는 표현식 예시
avg(/fml-dev-app-01/system.cpu.util,5m)>90
# 별도 복구 표현식 예시
avg(/fml-dev-app-01/system.cpu.util,5m)<755-3. 정상·장애·복구를 안전하게 시험한다
DEV에서만 테스트용 아이템을 따로 만들고 /var/tmp/fullmoon-ops-test.flag 같은 전용 파일을 사용한다. 테스트 파일의 존재·부재로 값과 이벤트 변화를 확인한 뒤 시험용 항목을 비활성화한다. 실제 PXE 표식이나 시스템 파일을 지워 시험하지 않는다. 표현식 테스트 통과, 실제 이벤트 생성, 담당자 알림 수신, 복구 알림을 각각 확인해야 한다.
6. Zabbix 알림과 장애 처리: 경보를 작업으로 연결한다
6-1. 수신 경로와 Action 설정
Alerts → Media types에서 사용할 Email 매체를 설정한다. 승인된 SMTP 주소·발신자·TLS·인증 방식을 입력하고 시험한다. Users → Users → 대상 사용자 → Media에는 실제 수신 주소, 수신 가능한 시간대, 심각도 범위를 등록한다. 비밀번호를 일반 매크로나 템플릿 설명에 적지 않는다. 메일 설정은 공식 Email 매체 문서를 참고한다.
Alerts → Actions → Trigger actions → Create action에서 운영용 Action을 만든다. 예시 조건은 Host group FullMoon/Linux, event tag environment=PROD, 심각도 Warning 이상이다. Operation에는 운영 담당 그룹을, Recovery operations에는 복구 통보를 지정한다. DEV·STG는 별도 수신 범위로 분리한다. 필요하면 미확인 문제의 후속 통보 단계를 추가하되 반복 간격은 당직 체계에 맞춰 정한다. Action 설정 기준
알림에는 호스트·환경·문제명·심각도·관제 화면 주소·첫 점검 방법을 담는다. 문자 하나라도 수신됐다는 것만 보지 말고, 수신 계정이 해당 호스트를 볼 수 있고 복구 알림도 받는지 확인한다.
6-2. 관제 담당자가 문제를 처리하는 순서
Monitoring → Problems에서 영향 환경과 실제 업무 중단 여부를 확인한다.- 문제를 확인 처리하고 담당자·초기 판단을 기록한다. 확인 처리는 복구 완료가 아니다.
- Latest data와 그래프에서 정상값·수집 중단·자원 고갈을 구분한다.
- NetBox에서 관리 주소와 변경 대상의 식별 정보를 확인한다.
- 승인된 AWX 작업 또는 정해진 수동 복구 절차를 실행한다.
- 사용자 기능, API, 최신 관제 데이터가 정상인지 확인하고 조치 결과를 기록한다.
환경 Proxy가 끊어지면 여러 대상이 동시에 수집 중단으로 보일 수 있다. 상위 경로 문제를 먼저 조사하고, 필요한 경우 하위 트리거에 의존성을 설계한다. 데이터 누락을 모두 자동 억제해 실제 장애가 숨지 않게 범위를 검토한다. 트리거 의존성 문서
예정된 작업에는 Data collection → Maintenance에서 대상·기간·수집 여부를 지정한다. 작업 중에도 수집을 유지하면 변화와 복구를 확인하기 쉽다. Action의 유지보수 중 알림 억제 설정을 함께 점검하고, 종료 후 점검 기간이 해제됐는지 확인한다.
7. Zabbix 일일·주간·월간 보고 설정
정기 보고는 선택한 대시보드를 PDF로 만들어 보내는 기능이다. 장애 원인 분석 문장, AWX 변경 내역, NetBox 자산 증감까지 자동으로 작성하는 기능은 아니다. PDF와 함께 운영자가 작성하는 요약 보고를 묶어 사용한다.
7-1. 보고 생성에 필요한 구성부터 준비한다
현재 구축 파일에는 별도의 보고 생성 서비스가 포함되어 있지 않다. 보고용 실행환경에 Zabbix web service와 지원되는 Google Chrome을 함께 준비해야 한다. 보고 생성 서비스가 내부 Frontend URL에 접속하고 인증서를 신뢰할 수 있어야 한다. 온라인망에서는 공식 배포물로 구성하고, 폐쇄망에서는 브라우저·라이브러리·폰트·CA까지 준비 구간에서 확인해 반입한다. 설치 요건은 정기 보고 구성 문서에 따른다.
이 실습의 확장안은 두 중앙 노드 각각에 보고 서비스를 두고, 같은 노드의 Zabbix Server가 로컬 보고 서비스를 이용하는 방식이다. 브라우저의 메모리 사용량을 고려해 먼저 소규모 보고로 확인한다. 보고 서비스를 한쪽에만 두면 그 노드가 꺼졌을 때 보고가 생성되지 않는 의존성이 남는다.
기존 Server 컨테이너는 host network를 사용하므로, 각 중앙 노드에 로컬 보고 서비스를 준비한 뒤 Server 설정에 다음 관계를 추가할 수 있다. 이는 추가 설정 예시이며 현재 적용 완료 값이 아니다.
# 기존 zabbix-server 서비스의 environment에 병합하는 예시
ZBX_STARTREPORTWRITERS: '1'
ZBX_WEBSERVICEURL: 'http://127.0.0.1:10053/report'
TZ: Asia/Seoul일반 설정 파일을 사용한다면 대응 항목은 StartReportWriters=1, WebServiceURL=http://127.0.0.1:10053/report다. 보고 서비스의 /report 경로를 생략하지 않는다. 로컬 호출 예시의 포트는 다른 망에 공개하지 않으며, 별도 서버 간 호출로 바꾸면 TLS와 허용 출발지를 구성한다. 컨테이너는 검증한 공식 이미지와 환경 변수 지원을 확인한 뒤 사용한다. 공식 Zabbix Docker 구성
Administration → General → Other → Frontend URL에는 https://zabbix.fullmoon.test를 지정한다. 운영자 PC에서만 열리는 주소가 아니라 보고 서비스의 브라우저에서도 열리는 주소여야 한다. 컨테이너·호스트·Zabbix Server의 시간대를 맞추고, 보고 생성 일정이 기대한 날짜에 실행되는지 확인한다. PHP 화면 표시 시간대만 맞춘 것으로 끝내지 않는다.
7-2. 보고 권한과 수신자를 준비한다
보고를 생성·관리할 계정에는 해당 대시보드와 호스트 조회 권한, Scheduled reports 접근·관리 권한이 필요하다. 구독자는 Email media가 설정된 Zabbix 사용자로 지정한다. Generate report by에서 누구의 조회 권한으로 자료를 생성하는지도 확인한다. 수신자가 볼 수 없는 자산을 다른 관리자의 권한으로 보고서에 노출하지 않게 한다.
SMTP가 없는 폐쇄망에서는 PDF 보고의 자동 메일 수신을 완료할 수 없다. 내부 릴레이와 승인된 수신 계정을 먼저 마련하거나, 승인된 내부 저장·배포 절차를 별도로 설계한다. 브라우저의 수동 PDF 저장은 가능하더라도 자동 발송 검증을 대신하지 않는다.
7-3. 보고 세 개를 등록한다
Reports → Scheduled reports → Create report에서 아래 세 보고를 각각 만든다. Period는 집계할 기간, Cycle은 발행 주기다. 예를 들어 주간 보고는 지난주 자료를 매주 보내도록 두 항목을 함께 맞춘다.
| 보고 이름 | Dashboard | Period | Cycle | 운영 예시 |
|---|---|---|---|---|
| FullMoon 일일 운영 보고 | FullMoon 일일 보고 | Previous day | Daily | 매일 업무 시작 전에 검토 |
| FullMoon 주간 운영 보고 | FullMoon 주간 보고 | Previous week | Weekly | 월요일에 전주 추세 검토 |
| FullMoon 월간 운영 보고 | FullMoon 월간 보고 | Previous month | Monthly | 월초에 전월 용량·반복 장애 검토 |
실제 Dashboard 필드에서는 앞 절에서 만든 FullMoon | 일일 보고 등의 객체를 선택한다. 주간 보고는 Repeat on에 Monday를 선택한다. 월간 주기는 월초 생성 기준으로 사용하고, Start date와 선택한 주기로 첫 발행일을 확인한다. Start time은 업무 시작 전의 원하는 시각으로 정하되 서버 시간대 기준이라는 점을 확인한다. 이름·제목·수신자는 조직 기준으로 입력한다. 보고 필드와 주기 설정
Test는 현재 로그인한 사용자에게 보내는 시험이다. 실제 구독자와 Generate report by 설정의 검증을 대신하지 않는다. 시험 PDF를 확인한 뒤 예정된 발행에서 각 승인 수신자가 정상 자료를 받았는지까지 확인한다.
| 확인 항목 | 통과 기준 |
|---|---|
| 보고 생성 | PDF가 정상 생성되고 빈 그래프·깨진 한글이 없음 |
| 집계 기간 | 일일·주간·월간이 각각 의도한 이전 기간을 표시 |
| 수신·권한 | 승인 수신자에게 도착하고 허용된 자산만 포함 |
| HA 경로 | 활성 Server 변경 후에도 보고 생성 경로가 유효 |
| 실패 확인 | SMTP·브라우저·인증서 오류를 담당자가 확인 가능 |
7-4. 운영 보고에 넣을 내용
| 주기 | 자동 PDF에 담을 자료 | 운영자가 덧붙일 내용 |
|---|---|---|
| 일일 | 주요 자원 그래프, 현재 미해결 문제 | 영향 서비스, 담당자, 조치 상태, 다음 점검 |
| 주간 | 자원 추세·반복 문제 경향 | 원인별 장애 목록, AWX 작업 성공·실패, 신규·제외 자산 |
| 월간 | 용량 추세와 장기 변화 | 증설 후보, 반복 장애 개선, 복구 시험, 접근 권한·지원 종료 점검 |
장애 건수는 정한 기간의 문제 이벤트를 기준으로 집계하고, 복구 이벤트를 별도 장애로 이중 계산하지 않는다. AWX 성공률은 어떤 종류의 Job을 포함했는지 함께 적는다. SLA를 적을 때에는 서비스 정의·점검 시간·제외 조건·데이터 누락 처리 기준을 먼저 정한다. 알림이 없었다는 이유만으로 가용률 100%를 계산하지 않는다.
8. AWX: 현재 만들어진 객체와 역할 이해하기
AWX는 Git의 플레이북을 지정한 자격 증명·실행환경·대상 범위로 실행하고 이력을 남기는 도구다. 이 구성에서 NetBox 자산 등록, Zabbix 등록, 인벤토리 갱신, 기본 상태 확인을 이어 주는 역할을 한다.
| AWX 객체 | 실제 구성 이름 | 역할 |
|---|---|---|
| Organization | FullMoon Lab | 프로젝트·인벤토리·자격 증명 관리 범위 |
| Project | FullMoon infrastructure automation | 내부 Git의 main 브랜치 동기화 |
| 승인 인벤토리 | FullMoon approved bootstrap | 아직 NetBox 등록 전인 승인 대상 |
| 운영 인벤토리 | FullMoon NetBox assets | NetBox의 자동화 대상 자산 조회 |
| Job Template | FullMoon Onboard | 기본 설정·자산·관제 등록 |
| Job Template | FullMoon Verify | SSH 경로·기본 서비스·새 관제 값 확인 |
| Workflow | FullMoon server to operations | Onboard → NetBox inventory sync → Verify |
| Execution Environment | FullMoon EE 24.6.1 / NetBox 3.23.0 | collection·Python·CA·SSH 신뢰 자료를 포함한 실행 이미지 |
Git 읽기용, 대상 SSH용, 자산·관제 API용 자격 증명이 각각 연결되어 있다. 운영자가 비밀 값을 화면에서 복사해 Extra Variables에 넣지 않는다. 실행 권한은 필요한 Template 중심으로 부여하고 Project·인벤토리·Credential의 사용 권한을 함께 검토한다. AWX 권한 모델
9. AWX 실행 절차: 새 서버 등록과 일상 점검
9-1. 신규 서버를 운영 대상으로 등록하기
- 승인된 hostname·환경·관리 IP·MAC·Bastion 허용 경로·SSH host key를 확인한다. 실습 자동화는 이름과 대역을 검사하므로 임의 서버 이름으로 바로 실행할 수 없다.
- Git의
inventory/bootstrap.yml과 필요한 설정을 수정하고 검토한 커밋을 main에 반영한다. 키와 토큰은 커밋하지 않는다. - AWX
Resources → Projects에서FullMoon infrastructure automation의 동기화를 실행하고, 성공 상태와 SCM revision을 확인한다. Resources → Inventories → FullMoon approved bootstrap → Sources에서 bootstrap source를 동기화한다.- 대상 호스트의
ansible_host,fml_environment,fml_subnet이 맞는지 확인한다. Resources → Templates → FullMoon server to operations를 실행한다. Limit에fml-dev-app-01처럼 승인 대상 한 대를 명시한다.- Jobs에서 Onboard, inventory-sync, Verify가 모두 성공했는지 확인한다. 최상위 상태만 보지 말고 실패한 노드가 없는지 확인한다.
- NetBox의 자산·관리 IP, AWX 운영 인벤토리, Zabbix의 실제 최신 값을 각각 확인하고 등록을 마친다.
현재 Workflow에는 Project sync와 bootstrap source sync가 노드로 포함되어 있지 않다. 따라서 수동 실행 전의 3·4단계를 생략하지 않는다. 설치 완료 컨트롤러 경로에서는 이를 먼저 수행한다. 최초 SSH 신원 승인 전에는 컨트롤러가 대기하며, 알 수 없는 host key를 자동 승인하지 않는다.
Limit이 비어 있거나 all이면 의도보다 많은 대상에 실행될 수 있다. 승인한 범위를 명확하게 지정하고, 여러 서버를 적용할 때에도 DEV → STG → PROD 순서로 나누어 결과를 확인한다. Workflow와 Limit 동작
9-2. 일상 점검은 Verify로 실행한다
FullMoon Verify는 NetBox에서 읽은 대상을 기준으로 SSH 접속, SELinux Enforcing, sshd·chronyd·firewalld·Agent 서비스, PXE 설치 표식, 새로운 Zabbix uptime 값을 확인한다. 현재 플레이북의 점검 범위는 FullMoon 실습 대상이다. 모든 일반 Linux 서버의 상태를 포괄하는 만능 진단으로 사용하지 않는다.
NetBox source를 먼저 동기화한 뒤 Verify에서 대상과 Limit을 확인하고 실행한다. 성공해도 백업 복원, DB 정합성, 사용자 서비스의 정상 응답까지 검증한 것은 아니다. 필요한 서비스 점검은 별도 읽기 전용 플레이북으로 추가하고 DEV에서 확인한다.
9-3. 실패·취소·재실행 판단
| 작업 결과 | 먼저 확인할 내용 | 다음 행동 |
|---|---|---|
| Project sync 실패 | DNS·Git 읽기 키·강제 명령·브랜치 | 저장소 읽기를 복구하고 다시 동기화 |
| Inventory sync 실패 | NetBox API·조회 계정·CA·필터 | 자산과 소스 상태를 확인한 뒤 재동기화 |
| SSH 실패 | Bastion·허용 대상·관리 IP·host key | 주소와 신원을 확인하고 경로 복구 |
| API 등록 실패 | 요청 오류와 이미 생성된 자산 | 부분 성공 범위를 확인한 뒤 재실행 |
| Verify 실패 | 서비스·수집 중단·Proxy 연결 | 실제 상태를 복구한 뒤 Verify 재실행 |
| 작업 취소 | 어디까지 적용됐는지 | 취소를 롤백으로 간주하지 않고 현 상태 확인 |
같은 대상 재실행은 식별자와 IP 충돌을 검사하도록 만들었지만, 모든 외부 API가 하나의 트랜잭션으로 처리되는 것은 아니다. 성공한 자산을 일괄 삭제하고 처음부터 실행하지 않는다. Check 모드도 모든 command·shell·API 호출의 안전한 예행연습을 보장하지 않는다. 지원하지 않는 작업은 생략될 수 있으므로 현재 Onboard의 전체 적용 결과를 미리 검증한 것으로 보지 않는다. Job Template와 Check 모드
10. AWX 정기 작업과 변경 관리
정기 점검 예시는 NetBox inventory sync 후 Verify를 실행하는 별도 Workflow다. 기존 온보딩 Workflow를 그대로 매일 예약하면 패키지·Agent 설정까지 다시 적용할 수 있으므로, 점검과 변경 작업을 분리한다. 자산 정보만 갱신하는 전용 템플릿은 현재 구성에 없으므로 필요하면 수집·등록 부분을 분리해 추가해야 한다.
Resources → Templates → 점검 Workflow → Schedules → Add에서 일정·시간대·대상 Limit을 설정한다. 먼저 비활성 상태로 저장해 대상과 다음 실행 예정일을 확인하고, 수동 실행이 성공한 뒤 활성화한다. Source sync는 전체 승인 필터의 인벤토리를 갱신하고 Verify의 Limit은 실제 점검할 호스트를 좁히므로 두 범위를 혼동하지 않는다. 일정은 리소스의 Schedules 탭에서 만들 수 있다. AWX 예약 작업 문서
| 정기 작업 예시 | 목적 | 운영 기준 |
|---|---|---|
| 일일 Verify | 기본 서비스와 수집 경로 확인 | 백업·배포 시간과 겹치지 않게 설정 |
| 주간 자산 대조 | NetBox·AWX·Zabbix의 대상 차이 확인 | 차이가 나면 자동 삭제보다 원인 검토 |
| 월간 점검 작업 | 계정·지원 종료·백업 상태 확인 | 별도 점검 플레이북을 검토 후 연결 |
변경용 작업에는 승인 담당자, 적용 대상, Git 커밋, 사전 백업, 되돌릴 방법을 남긴다. 필요한 경우 Workflow approval node를 추가하지만 현재 Workflow에 이미 승인 단계가 있다고 가정하지 않는다. 승인 단계가 있는 변경 작업과 반복적인 조회 작업은 다른 실행 권한으로 관리한다.
AWX는 중앙 1호기에 있어 이 노드가 꺼지면 신규 실행이 멈춘다. Git은 2호기에 있어 해당 노드 장애 중 새 Project sync가 실패한다. HA 시험 중 API 화면이 열렸다는 사실만으로 작업이 계속 실행될 것이라 기대하지 않는다.
11. NetBox: 자산 종류·환경·주소를 구분하는 방법
NetBox는 “지금 응답하는 서버 목록”보다 자산과 주소의 기준 정보를 관리하는 역할에 가깝다. 살아 있는지 여부는 Zabbix에서 보고, 자산이 어떤 환경에 속하고 어떤 주소와 역할을 가져야 하는지는 NetBox에서 확인한다.
11-1. 물리 장비와 VM을 다른 객체로 관리한다
| 구분 | NetBox 객체·메뉴 | 관리할 내용 | 현재 실습 상태 |
|---|---|---|---|
| 물리 서버·스위치 | Devices | 제조사·모델·시리얼·Site·Rack·인터페이스 | 등록 경로는 코드에 있으나 실장비 검증은 안 함 |
| 가상 서버 | Virtualization → Virtual Machines | vCPU·메모리·디스크·환경·관리 IP | PROD·DEV·STG 대상 등록 확인 |
| 설치 위치 | Organization의 Sites·Locations, Racks | 실제 위치·랙·담당 조직 | Site FullMoon Lab 사용, 랙 모델링은 추가 항목 |
| 관리 네트워크 | IPAM → Prefixes·IP Addresses | 대역·주소 상태·인터페이스 할당 | 대상 관리 IP 연결 확인, Prefix 정리는 별도 관리 |
| 가상화 소속 | Virtualization → Clusters | 가상화 플랫폼·호스트와 VM 관계 | 필요 시 추가, 현재 자동 생성 기능은 아님 |
VM을 물리 Device로 중복 등록하거나 모든 정보를 메모에만 몰아넣지 않는다. VM은 Virtual Machine 모델, 물리 자산은 Device 모델을 사용한다. HCI를 추가한다면 물리 호스트는 Device, 가상화 단위는 Cluster, 게스트는 VM으로 구분해 관계를 표현한다.
11-2. 환경과 역할은 섞지 않는다
현재 기본 Role은 Server, Platform은 Rocky Linux 10, Site는 FullMoon Lab이다. PROD·DEV·STG는 환경 구분이며, DB·WEB·WAS 같은 서비스 역할과 다르다. 현재 코드에서는 서비스 탐지 결과가 service_role Custom Field에 기록된다. 서비스 소유팀이나 업무 이름은 별도 검토 필드로 추가할 수 있다.
| 필드·태그 | 의미 | 운영 방법 |
|---|---|---|
env_type |
PROD·DEV·STG | 승인 대역과 함께 변경 검토 |
auto 태그 |
자동화 조회 대상 | 임의로 붙여 운영 대상에 편입하지 않음 |
prod·dev·stg 태그 |
환경 검색·분류 | env_type과 불일치 여부 점검 |
vm·physical 태그 |
자산 형태 | 실제 객체 종류와 일치시킴 |
collection_status |
수집 완전·부분 실패 상태 | 부분 실패 시 기존값이 최신인지 구분 |
collection_errors |
수집 실패 사유 | 자산 누락보다 수집 권한·명령 문제부터 조사 |
machine_id |
운영체제 식별값 | 서버 교체·재설치 시 승인 정보와 대조 |
backup_enabled |
백업 제품 흔적 탐지 | 실제 백업 성공·복원 가능으로 해석하지 않음 |
수집값인 CPU·메모리·OS·제품 탐지 결과를 사람이 임의 수정하면 다음 수집에서 바뀔 수 있다. 담당자·승인한 Role·상태·설명과 같은 관리 정보는 별도 소유자를 둔다. 현재 등록 코드는 기존 Site·Role·Platform·Status를 수집값으로 무조건 바꾸지 않고, 기존 태그도 보존한다.
11-3. 자산과 관리 IP 확인하기
Virtual Machines에서 fml-prod-app-01을 열어 환경·상태·대표 IPv4를 확인한다. Interfaces에서 실제 관리 NIC를 보고, 해당 인터페이스에 10.77.20.101/24가 할당되어 있는지 IPAM에서도 확인한다. IP 주소 필드와 자유 형식 메모에 적힌 주소가 서로 다르면 메모를 기준으로 접속하지 않는다.
필터에서 상태·태그·Site를 사용해 목록을 좁히고 필요한 열을 표시한다. 수집 상태가 부분 실패인 자산, 관리 IP가 없는 자산, 환경 태그가 불일치한 자산을 주간 점검 대상으로 만든다. 내보내기 파일도 자산 정보이므로 담당 범위에 맞게 보관한다.
12. NetBox와 AWX 연결: 신규·변경·퇴역 절차
12-1. 인벤토리에 들어가는 조건
현재 FullMoon NetBox assets는 NetBox의 auto 태그와 active 상태를 모두 만족하는 대상을 조회한다. 플러그인은 태그 그룹을 만들고 env_type을 이용해 환경 변수와 대역 정보를 계산한다. 관리 IP와 labadmin 사용자를 기준으로 Bastion 접속에 필요한 정보가 구성된다.
NetBox에 자산을 저장했다고 AWX 목록이 즉시 바뀌는 것은 아니다. inventory source sync가 필요하다. 현재 source에는 overwrite와 overwrite_vars가 활성화되어 있으므로, 자동으로 가져온 호스트 변수는 AWX 화면에서 직접 고치기보다 NetBox·Git의 원본을 수정한다.
12-2. 신규 자산 등록
새 대상은 승인 목록과 신원 확인 후 Onboard Workflow로 등록한다. 물리 장비의 구매·랙 배치 정보를 미리 관리하려면 NetBox에 계획 자산을 만들 수 있지만, 자동 등록과 동일 이름·식별자·IP를 사용하는지 대조해야 한다. 장비 등록 폼에 이름만 적었다고 PXE 설치나 방화벽 허용까지 수행되지는 않는다.
12-3. IP 변경과 서버 교체
IP 변경은 NetBox 값 하나만 바꾸는 작업이 아니다. 승인 inventory, 대상 OS, Bastion PermitOpen, Zabbix 경로, SSH 신원을 함께 검토한다. 현재 자동화는 기존 IP·Proxy 경로가 다르면 중단하므로 계획된 변경 절차로 처리한다. 재설치로 machine ID가 달라진 경우도 자동 등록을 억지로 통과시키지 않고 같은 자산을 교체한 것이 맞는지 승인한다.
12-4. 퇴역·운영 제외
- 담당자와 데이터 보존·백업 필요 여부를 확인하고 변경 기록을 만든다.
- 대상에 실행될 AWX 예약 작업과 설치 완료 컨트롤러의 승인 목록을 검토해 신규 작업을 막는다.
- Zabbix 대상 모니터링을 계획에 따라 비활성화하고 기존 장애 기록은 보존한다.
- NetBox의 상태·설명에 운영 제외를 반영하고, 필요하면 자동화 대상 태그를 정리한다.
- NetBox inventory source를 동기화하고 AWX 실행 대상에서 제외됐는지 확인한다.
- 서비스와 주소 사용이 끝난 것을 확인한 뒤 IP·계정·인증서·장비 처분을 각각 처리한다.
NetBox 상태 변경은 Zabbix 호스트 삭제나 VM 삭제를 자동으로 수행하지 않는다. 장비를 먼저 삭제해 이력을 잃거나, 실제 서버가 아직 사용하는 주소를 바로 재할당하지 않는다.
13. 일일·주간·월간 운영 루틴과 보고 양식
| 주기 | Zabbix | AWX | NetBox·공통 | 남길 기록 |
|---|---|---|---|---|
| 일일 | 미해결 문제·수집 중단·Proxy 연결·용량 급증 | 실패·대기 Job, 예정된 작업 | 변경 자산·접속 경로·백업 결과 | 영향, 조치, 담당자, 미완료 항목 |
| 주간 | 반복 알림·임계값·증가 추세 | Project revision·예약 작업·반복 실패 | 대상 수 대조·부분 수집·자산 정보 누락 | 개선 과제와 다음 주 작업 |
| 월간 | 장기 용량·보존 정책·보고 누락 | 실행 권한·Credential 만료·EE 갱신 | 지원 종료·복원 시험·자산 수명주기 | 위험 항목·증설·복구 계획 |
일일 보고는 다음 틀로 작성하면 된다. 정확한 시각은 장애 경과를 설명하는 데 필요한 경우에만 추가한다.
대상 기간 / 작성자:
운영 상태: 정상 또는 영향 서비스 명시
주요 문제: 현상 / 영향 범위 / 원인 또는 조사 상태
완료한 조치: 작업 내용 / Git 커밋 또는 AWX Job / 확인 결과
미완료 항목: 담당자 / 다음 조치 / 예정일
자산 변경: 신규 / 주소 변경 / 운영 제외
다음 작업: 승인 여부 / 대상 / 되돌릴 방법주간에는 같은 문제가 반복되는 원인과 자동화 개선을, 월간에는 용량·지원 종료·복원 가능성을 추가한다. 평균 수치만 나열하지 말고 “어떤 판단과 작업으로 이어지는가”를 적는다. 알려진 장애가 사라졌는지, 수집 자체가 끊겨서 보이지 않는지도 구분한다.
14. 운영 장애별 첫 점검과 인수인계 기준
| 증상 | 첫 점검 | 완료 기준 |
|---|---|---|
| NetBox 공통 주소 503 | HAProxy backend, DB 역할, Redis 연결, 앱 준비 상태 | 기존 자산 조회와 필요한 쓰기 확인 |
| 한 환경의 관제가 함께 중단 | 환경 Proxy·대상 Active 경로·방화벽 | 새 데이터와 지연 데이터 복구 확인 |
| AWX는 열리지만 실행 불가 | Task 상태, Git sync, EE 이미지, inventory | 승인 대상 Verify 성공 |
| NetBox 자산이 AWX에 없음 | active·auto 조건, 관리 IP, env_type, source sync | 올바른 호스트 변수로 조회 |
| PDF 보고가 오지 않음 | web service·Chrome·Frontend URL·CA·SMTP·권한 | 예정 발행의 실제 수신 확인 |
| 중앙 노드 복귀 후 불안정 | DB 복제·앱·Worker·Sentinel·VIP 역할 | 예비 역할과 서비스 준비 상태 확인 |
관리 경로에서 확인할 수 있는 최소 명령은 다음과 같다. 컨테이너 이름과 파일 위치는 이 실습 기준이며, 실제 설치 위치와 일치하는지 확인한다.
# 중앙 노드: 서비스 준비 상태
docker ps --format '{{.Names}} {{.Status}}'
systemctl is-active haproxy keepalived
docker compose --project-directory /opt/fullmoon-lab/core \
-f /opt/fullmoon-lab/core/compose.yml exec -T postgres \
patronictl -c /etc/patroni/patroni.yml list
# 중앙 1호기: AWX와 설치 완료 감지
sudo /usr/local/bin/k3s kubectl -n awx get pods,jobs
systemctl status fullmoon-postinstall.timer운영 인수인계 시에는 접속 계정과 담당 범위, 관제 대시보드, 알림 수신자, 보고 일정, 승인된 작업 템플릿, 자산 변경 절차, 백업 복원 방법을 전달한다. 비밀번호·개인키·토큰은 매뉴얼에 포함하지 않고 조직의 비밀 관리 경로로 인계한다.
운영 시작 체크리스트: 최신 데이터 확인, 테스트 문제와 복구 알림 확인, DEV의 템플릿 적용 확인, 승인 대상 Workflow 성공, NetBox와 AWX 대상 일치, 보고 PDF·실제 수신 확인, 백업과 격리 복원 결과 확인, 담당자·승인·실패 대응 경로 확인. 이 항목을 실제로 수행한 뒤 결과를 기록해야 하며, 매뉴얼의 예시를 읽은 것만으로 완료 처리하지 않는다.