운영을 잇다 04 — Zabbix·AWX·NetBox 운영 매뉴얼

AI Editter

서버가 설치됐다는 것과 운영할 준비가 됐다는 것은 다르다. 운영자는 이상 징후를 발견하고, 영향을 받는 자산을 확인하고, 승인된 작업을 실행한 뒤 정상 복구를 확인해야 한다. 이 글은 앞서 구성한 실습 환경을 대상으로 관제 → 판단 → 작업 → 확인 → 보고를 반복하는 방법을 정리한 운영 매뉴얼이다.

Zabbix에서 상태를 보고, NetBox에서 자산과 관리 주소를 확인하며, AWX에서 Git에 저장한 작업을 실행한다. 도구별 기능 소개보다 실제 메뉴에서 무엇을 설정하고 어떤 결과를 확인해야 하는지에 초점을 맞췄다. 메뉴는 영문 이름을 함께 표기했으며 화면 언어에 따라 번역은 다를 수 있다.

운영 절차 바로가기

• Zabbix 대시보드와 관제
• 템플릿과 트리거
• 일일·주간·월간 보고
• AWX 등록과 점검
• 커널·Apache·Tomcat 업그레이드
• NetBox 자산 관리
• 운영 루틴과 보고 양식

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 전체 장애를 견디는 구성은 아니다.

본문의 화면은 2026년 9월 21일 VirtualBox 실습 환경에서 직접 촬영했다. 각 이미지 아래의 설명을 먼저 읽고, 메뉴나 입력값이 작으면 원본 크기로 열어 확인하면 된다. 운영 관제와 보고 대시보드는 적용했고, 추가 템플릿은 DEV 한 대에만 연결했다. 담당자 권한 분리·외부 알림·승인 단계처럼 아직 적용하지 않은 절차는 운영 확장 예시로 구분한다.

2. 접속과 역할 분담: 어디에서 무엇을 바꾸는가

주소는 인터넷 공개 서비스가 아니라 실습 내부 이름이다. 관리 단말의 내부 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 | 운영 관제를 만들고 편집 모드에서 위젯을 추가한다. 처음에는 화면 하나에서 판단할 수 있도록 다음 순서로 배치한다.

화면 읽는 순서: Available 3으로 수집 경로를 확인하고, 심각도와 현재 문제를 본 뒤 서버별 값과 그래프를 비교한다. 촬영 시 현재 문제 영역의 No data found는 표시할 문제가 없다는 뜻이다. 최신 데이터가 갱신된다는 확인과 함께 판단하며, 무조건적인 무장애 보장으로 해석하지 않는다.

현재 화면은 세 환경을 함께 보여 준다. PROD 전용 페이지를 만들 때에는 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. 용량 대시보드와 보고용 대시보드

현재 화면에는 CPU와 메모리 그래프가 있다. 별도 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 템플릿을 대체하지 않는 추가 점검이다. 표식이 있다는 것만으로 이후의 모든 운영 설정이 정상이라는 뜻은 아니다.

1. Data collection → Templates → Create template을 연다.
2. Template name을 FullMoon Operations Checks, Template group을 현재 사용한 Templates/Operating systems로 지정한다. 조직 전용 그룹을 원하면 Templates/FullMoon을 별도로 만들어 분리할 수 있다.
3. 설명에 점검 목적·담당자·적용 대상이 “FullMoon PXE로 설치한 Linux 대상”임을 적는다.
4. 저장한 템플릿의 Items → Create item에서 아래 항목을 등록한다.

적용 결과: fml-dev-app-01에서 값 1이 수집됐고 Unsupported 오류는 없었다. 기존 Linux 템플릿도 유지했다. STG·PROD 연결과 템플릿 Git 반영은 다음 변경 절차에서 수행할 항목이다.

값 1은 파일 존재, 0은 부재다. 읽기 권한이나 경로 문제로 Unsupported가 되지 않는지 확인한다. Agent key의 의미는 Zabbix Agent 아이템 문서를 참고한다.

1. Data collection → Hosts → fml-dev-app-01 → Templates에서 추가 템플릿을 연결한다.
2. Latest data에서 실제 값과 갱신 상태를 확인한 뒤 STG·PROD로 적용 범위를 넓힌다.
3. 템플릿을 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은 실제 등록한 FullMoon: 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)=1

5m, 1m은 판정에 필요한 관찰 구간이다. 데이터가 없는 상태를 파일 부재로 단정하지 않으며, 신규 연결 직후에는 충분한 값이 쌓였는지도 확인한다. 문제 표현식이 참인 동안에는 복구 표현식만 참이 되어도 복구되지 않는다. Single 이벤트 모드를 사용하고, 설명에는 대상 경로와 점검 순서를 적는다. 표현식과 복구 조건은 트리거 설정 문서를 참고한다.

화면의 Recovery expression은 별도 복구 조건을 사용한다는 뜻이다. 등록과 정상 값 수집은 확인했지만, 이번 촬영에서 실제 설치 표식을 지워 장애·복구를 유발하지는 않았다. 알림 수신 시험과도 별개의 결과다.

5-2. CPU·메모리·디스크 임계값을 정하는 방법

다음 수치는 운영을 시작할 때 검토할 예시다. 실제 업무 부하·디스크 크기·허용 중단 범위에 따라 바꾼다. 이미 같은 의미의 기본 트리거가 있으면 먼저 그 매크로를 조정하고 동일한 알림을 중복으로 만들지 않는다.

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)<75

5-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. 관제 담당자가 문제를 처리하는 순서

1. Monitoring → Problems에서 영향 환경과 실제 업무 중단 여부를 확인한다.
2. 문제를 확인 처리하고 담당자·초기 판단을 기록한다. 확인 처리는 복구 완료가 아니다.
3. Latest data와 그래프에서 정상값·수집 중단·자원 고갈을 구분한다.
4. NetBox에서 관리 주소와 변경 대상의 식별 정보를 확인한다.
5. 승인된 AWX 작업 또는 정해진 수동 복구 절차를 실행한다.
6. 사용자 기능, API, 최신 관제 데이터가 정상인지 확인하고 조치 결과를 기록한다.

환경 Proxy가 끊어지면 여러 대상이 동시에 수집 중단으로 보일 수 있다. 상위 경로 문제를 먼저 조사하고, 필요한 경우 하위 트리거에 의존성을 설계한다. 데이터 누락을 모두 자동 억제해 실제 장애가 숨지 않게 범위를 검토한다. 트리거 의존성 문서

예정된 작업에는 Data collection → Maintenance에서 대상·기간·수집 여부를 지정한다. 작업 중에도 수집을 유지하면 변화와 복구를 확인하기 쉽다. Action의 유지보수 중 알림 억제 설정을 함께 점검하고, 종료 후 점검 기간이 해제됐는지 확인한다.

7. Zabbix 일일·주간·월간 보고 설정

정기 보고는 선택한 대시보드를 PDF로 만들어 보내는 기능이다. 장애 원인 분석 문장, AWX 변경 내역, NetBox 자산 증감까지 자동으로 작성하는 기능은 아니다. PDF와 함께 운영자가 작성하는 요약 보고를 묶어 사용한다.

7-1. 보고 생성에 필요한 구성부터 준비한다

이번 운영 실습에서는 중앙 2호기 fml-ops-02에 보고 서비스를 추가했다. 공식 zabbix-web-service:ubuntu-7.0.30 이미지에 포함된 Chromium을 사용하고, 한글 폰트와 내부 CA 신뢰 구성을 더했다. 보고용 브라우저가 https://zabbix.fullmoon.test를 인증서 오류 없이 열 수 있어야 한다. 온라인망에서는 공식 이미지와 패키지를 준비하고, 폐쇄망에서는 검증한 완성 이미지·폰트·라이브러리·CA를 함께 반입한다. 설치 요건은 정기 보고 구성 문서에 따른다.

현재 보고 서비스와 내부 Mailpit 수신함은 중앙 2호기 한 곳에만 있다. PDF 시험에서는 Zabbix Active 역할도 2호기로 맞췄다. 1호기로 역할이 전환되면 이 설정만으로 정기 보고가 이어지지 않는다. 보고 기능의 HA까지 확보하려면 양쪽의 보고 실행환경과 SMTP 경로를 함께 구성하고 장애 전환 후 수신을 별도로 시험해야 한다.

기존 Server 컨테이너는 host network를 사용한다. 중앙 2호기의 /opt/fullmoon-lab/apps/reporting.yml에 아래 환경 변수를 병합해 적용했다. 보고 서비스 구성은 /opt/fullmoon-lab/reporting/compose.yml에서 관리한다.

# 중앙 2호기 zabbix-server에 실제 추가한 값
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는 중앙 2호기의 127.0.0.1:1025, 수신 주소는 실습 전용 수신 계정이며 Mailpit 내부에만 보관한다. 수신 화면도 loopback 포트와 SSH 터널로 접근한다. 외부 메일 릴레이나 외부 수신자는 설정하지 않았다. 실제 운영으로 옮길 때에는 관리자의 개인 시험 계정 대신 조회 범위가 제한된 보고 계정과 승인된 내부 SMTP를 사용한다.

SMTP가 없는 폐쇄망에서는 PDF 보고의 자동 메일 수신을 완료할 수 없다. 내부 릴레이와 승인된 수신 계정을 먼저 마련하거나, 승인된 내부 저장·배포 절차를 별도로 설계한다. 브라우저의 수동 PDF 저장은 가능하더라도 자동 발송 검증을 대신하지 않는다.

7-3. 보고 세 개를 등록한다

Reports → Scheduled reports → Create report에서 아래 세 보고를 각각 만든다. Period는 집계할 기간, Cycle은 발행 주기다. 예를 들어 주간 보고는 지난주 자료를 매주 보내도록 두 항목을 함께 맞춘다.

실제 Dashboard 필드에서는 앞 절에서 만든 FullMoon | 일일 보고 등의 객체를 선택한다. 주간 보고는 Repeat on에 Monday를 선택한다. 월간 주기는 월초 생성 기준으로 사용하고, Start date와 선택한 주기로 첫 발행일을 확인한다. Start time은 업무 시작 전의 원하는 시각으로 정하되 서버 시간대 기준이라는 점을 확인한다. 이름·제목·수신자는 조직 기준으로 입력한다. 보고 필드와 주기 설정

현재 일정은 일일 매일 오전 9시, 주간 월요일 오전 9시, 월간 매월 첫날 오전 9시로 등록했다. 화면의 Period는 지난주, Cycle은 Weekly, Repeat on은 Monday다. 주간·월간 일정 등록과 그 기간의 실발행 성공은 다르다. 아직 장기간의 데이터나 반복 발행 실적을 쌓았다고 표현하지 않는다.

Test는 현재 로그인한 사용자에게 보내는 시험이다. 실제 구독자와 Generate report by 설정의 검증을 대신하지 않는다. 시험 PDF를 확인한 뒤 예정된 발행에서 각 승인 수신자가 정상 자료를 받았는지까지 확인한다.

7-4. 실제 PDF 발행과 내부 수신 결과

일일 보고 대시보드로 별도 발행 시험을 예약해 PDF 생성 → SMTP 전달 → Mailpit 내부 수신 → 첨부 파일 열기까지 확인했다. 수신한 PDF는 한 페이지이며 한글 제목과 세 환경의 CPU·메모리 그래프를 확인했다. 시험용 일정은 성공 후 비활성화해 중복 발행을 막았다.

목록의 시험 보고에는 Last sent가 표시되고 Disabled 상태다. 나머지 세 일정의 Never는 아직 해당 일정으로 발행되지 않았다는 뜻이다. 일회 시험의 성공을 주간·월간 반복 발행 이력으로 확대해 해석하지 않는다.

PDF의 그래프는 지난 하루를 대상으로 하지만 수집을 시작하기 전 구간에는 데이터가 없다. 현재 문제·가용성·Top hosts는 발행 시점의 상태와 최신값을 보여 주므로 과거 하루의 장애 총계나 평균값으로 읽지 않는다. 특히 월간 보고를 제대로 평가하려면 충분한 이력을 먼저 쌓아야 한다.

첫 생성 시험에서는 화면 준비 대기 오류가 났다. 내부 HTTPS와 CA 신뢰, 위젯 요청을 확인한 뒤 같은 설정으로 다시 발행해 수신에 성공했다. 재시도 성공만으로 대기 오류의 원인이 해결됐다고 단정하지 않는다. 보고 누락을 운영 점검에 포함하고, 실행 노드·서비스 자원·Frontend 응답을 함께 확인한다.

7-5. 운영 보고에 넣을 내용

장애 건수는 정한 기간의 문제 이벤트를 기준으로 집계하고, 복구 이벤트를 별도 장애로 이중 계산하지 않는다. AWX 성공률은 어떤 종류의 Job을 포함했는지 함께 적는다. SLA를 적을 때에는 서비스 정의·점검 시간·제외 조건·데이터 누락 처리 기준을 먼저 정한다. 알림이 없었다는 이유만으로 가용률 100%를 계산하지 않는다.

7-6. 보고 기능을 다시 구성하는 실행 순서

다음은 중앙 2호기에서 기존 보고 구성을 재현하는 절차다. 검수 보완 자료의 reporting/에 Dockerfile·Compose·Server override가 들어 있다. 2026년 9월 실습에서는 PDF 한 건의 내부 수신을 확인했다. 이번에 배포한 보완 파일의 전체 재설치·HA 전환 시험은 별도 검증 항목이다.

1. fml-ops-02에 로그인한다. hostname -s와 sudo docker compose version을 확인한다. 아래 파일을 작업 디렉터리 ~/operations-review/reporting에 복사한다.
2. 이 환경의 Frontend 인증서를 서명한 공개 CA 인증서를 lab-ca.crt로 준비하고 지문을 확인한다. 새 환경에서는 새 CA를 사용한다. CA 개인키를 이 경로에 복사하지 않는다.
3. 온라인 준비 환경에서 이미지를 빌드하고, 폐쇄망이면 완성 이미지를 저장하여 반입한다. Mailpit도 image digest를 기록하고 반입한다.

# 온라인 준비 노드, reporting 디렉터리에서
cd ~/operations-review/reporting
sudo docker compose config --quiet
sudo docker compose build web-service
sudo docker compose pull mailpit
sudo docker image inspect --format '{{json .RepoDigests}}' axllent/mailpit:v1.27.4
sudo docker save -o fullmoon-reporting-images.tar \
  fullmoon/zabbix-reporting:7.0.30-cjk axllent/mailpit:v1.27.4
sha256sum fullmoon-reporting-images.tar > fullmoon-reporting-images.tar.sha256

# 준비 노드와 실행 노드가 다르면 온라인망도 같은 tar를 전달한다.
# 중앙 2호기에서 tar와 체크섬을 함께 받아 확인한 뒤
sha256sum -c fullmoon-reporting-images.tar.sha256
sudo docker load -i fullmoon-reporting-images.tar

Dockerfile의 고정 digest는 기존 7.0.30 실습 기준이다. 온라인 준비 중 운영체제 패키지 저장소에서 받는 폰트·NSS 패키지는 시점에 따라 달라질 수 있으므로, 폐쇄망에서 다시 빌드하기보다 검토한 완성 이미지와 체크섬을 반입한다. 다른 Zabbix 버전으로 재구축할 때에는 Server·Web·Web Service를 함께 검토한다. Host network의 Server가 loopback 공개 포트를 호출하면 Web Service에는 Docker bridge 게이트웨이가 출발지로 보인다. 그래서 보고 전용망 게이트웨이를 172.30.77.1로 고정하고 허용 IP와 맞췄다. 기존 Docker·K3s·호스트망과 172.30.77.0/28이 겹치지 않는지 먼저 확인한다.

# 중앙 2호기에서. 기존 파일이 있으면 먼저 백업하고 검토한다.
cd ~/operations-review/reporting
sudo install -d -m 0700 /opt/fullmoon-lab/reporting
sudo install -m 0644 compose.yml Dockerfile lab-ca.crt /opt/fullmoon-lab/reporting/
sudo install -m 0600 reporting.yml /opt/fullmoon-lab/apps/reporting.yml
sudo docker compose --project-directory /opt/fullmoon-lab/reporting \
  -f /opt/fullmoon-lab/reporting/compose.yml up -d --no-build --pull never
sudo docker compose --project-directory /opt/fullmoon-lab/apps \
  -f /opt/fullmoon-lab/apps/compose.yml \
  -f /opt/fullmoon-lab/apps/reporting.yml config --quiet
# 승인한 점검 시간에 적용. Server 재생성으로 HA 역할이 바뀔 수 있다.
sudo docker compose --project-directory /opt/fullmoon-lab/apps \
  -f /opt/fullmoon-lab/apps/compose.yml \
  -f /opt/fullmoon-lab/apps/reporting.yml up -d --no-deps zabbix-server

향후 Server를 재생성할 때도 -f reporting.yml을 포함한다. 기본 Compose만 적용하면 보고 환경 변수가 빠질 수 있다. sudo docker exec fullmoon-apps-zabbix-server-1 zabbix_server -R ha_status를 실행해 Active 노드를 확인한다. 실제 컨테이너 이름은 sudo docker ps와 대조한다. 현재 제공하는 보고 구성은 2호기 전용이므로, Active가 1호기인 상태에서 이 절차만으로 보고 성공을 기대하지 않는다. 보고 목적으로 즉석에서 역할을 강제로 바꾸기보다, 양쪽 보고 실행환경을 준비하는 변경 계획을 검토한다.

1. Zabbix의 Administration → General → Other → Frontend URL을 https://zabbix.fullmoon.test로 지정한다.
2. Alerts → Media types → Create media type에서 Email, SMTP server 127.0.0.1, port 1025, 발신자 zabbix@fullmoon.test, Connection security None, Authentication None으로 실습 전용 매체를 만든다. 이 값은 같은 VM의 loopback Mailpit에만 사용하는 예시다.
3. Test를 누를 현재 사용자와 실제 보고 수신용 사용자에 Email media를 연결하고 시험용 .test 수신 주소를 입력한다. 해당 대시보드·호스트 조회 권한과 보고 생성 기준 사용자 권한을 확인한다.
4. 앞 절의 일일·주간·월간 보고를 등록한다. Test로 현재 로그인한 사용자의 수신을 확인하고, 별도 일회 예약으로 실제 구독자 수신까지 확인한다.

# 관리 PC에서 Mailpit 수신 화면을 loopback 터널로 조회
ssh -i <관리용_개인키> -p 22032 -N \
  -L 127.0.0.1:18025:127.0.0.1:8025 labadmin@127.0.0.1
# 브라우저에서 http://127.0.0.1:18025 를 연다.

성공 기준은 “Test 요청 완료”가 아니라 수신함의 메일·첨부 PDF 열기·한글 및 그래프·기간·조회 범위가 모두 정상인 것이다. 시험 일정은 확인 후 비활성화한다. 외부 발송을 시작하려면 조직에서 승인한 내부 SMTP·TLS·수신자 설정으로 바꾸고 별도 수신 시험을 한다.

PDF는 대시보드의 화면을 담는다. 지난 기간의 장애 건수는 해당 기간의 문제 이벤트를 별도로 집계하고, AWX 작업 성공률은 성공·실패 Job의 분모와 포함 범위를 정의한다. 보고 위젯의 현재 값이나 Problems 목록을 과거 기간의 평균·장애 총계로 바꾸어 읽지 않는다. Zabbix 보고 설정과 보고 생성 구성의 권한·생성 경로를 함께 확인한다.

8. AWX: 현재 만들어진 객체와 역할 이해하기

AWX는 Git의 플레이북을 지정한 자격 증명·실행환경·대상 범위로 실행하고 이력을 남기는 도구다. 이 구성에서 NetBox 자산 등록, Zabbix 등록, 인벤토리 갱신, 기본 상태 확인을 이어 주는 역할을 한다.

Git 읽기용, 대상 SSH용, 자산·관제 API용 자격 증명이 각각 연결되어 있다. 운영자가 비밀 값을 화면에서 복사해 Extra Variables에 넣지 않는다. 실행 권한은 필요한 Template 중심으로 부여하고 Project·인벤토리·Credential의 사용 권한을 함께 검토한다. AWX 권한 모델

화면의 세 노드는 onboard → inventory-sync → verify 순서다. 녹색 연결선은 앞 작업 성공 시 다음 노드로 진행하는 경로다. 이 화면은 템플릿의 설계 구조이며 실제 실행 결과는 다음 절의 Jobs에서 확인한다.

9. AWX 실행 절차: 새 서버 등록과 일상 점검

9-1. 신규 서버를 운영 대상으로 등록하기

1. 승인된 hostname·환경·관리 IP·MAC·Bastion 허용 경로·SSH host key를 확인한다. 실습 자동화는 이름과 대역을 검사하므로 임의 서버 이름으로 바로 실행할 수 없다.
2. Git의 inventory/bootstrap.yml과 필요한 설정을 수정하고 검토한 커밋을 main에 반영한다. 키와 토큰은 커밋하지 않는다.
3. AWX Resources → Projects에서 FullMoon infrastructure automation의 동기화를 실행하고, 성공 상태와 SCM revision을 확인한다.
4. Resources → Inventories → FullMoon approved bootstrap → Sources에서 bootstrap source를 동기화한다.
5. 대상 호스트의 ansible_host, fml_environment, fml_subnet이 맞는지 확인한다.
6. Resources → Templates → FullMoon server to operations를 실행한다. Limit에 fml-dev-app-01처럼 승인 대상 한 대를 명시한다.
7. Jobs에서 Onboard, inventory-sync, Verify가 모두 성공했는지 확인한다. 최상위 상태만 보지 말고 실패한 노드가 없는지 확인한다.
8. NetBox의 자산·관리 IP, AWX 운영 인벤토리, Zabbix의 실제 최신 값을 각각 확인하고 등록을 마친다.

현재 Workflow에는 Project sync와 bootstrap source sync가 노드로 포함되어 있지 않다. 따라서 수동 실행 전의 3·4단계를 생략하지 않는다. 설치 완료 컨트롤러 경로에서는 이를 먼저 수행한다. 최초 SSH 신원 승인 전에는 컨트롤러가 대기하며, 알 수 없는 host key를 자동 승인하지 않는다.

Limit이 비어 있거나 all이면 의도보다 많은 대상에 실행될 수 있다. 승인한 범위를 명확하게 지정하고, 여러 서버를 적용할 때에도 DEV → STG → PROD 순서로 나누어 결과를 확인한다. Workflow와 Limit 동작

실제 실행 결과: STG 대상 Workflow 작업 38에서 세 노드가 모두 성공했다. 화면의 노드별 숫자는 소요 시간이며, 운영자가 우선 확인할 것은 전체 상태와 각 노드의 성공 여부다. 실패 시 해당 노드를 열어 출력·대상·Git revision을 확인한다.

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. 실패·취소·재실행 판단

같은 대상 재실행은 식별자와 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 예약 작업 문서

변경용 작업에는 승인 담당자, 적용 대상, Git 커밋, 사전 백업, 되돌릴 방법을 남긴다. 필요한 경우 Workflow approval node를 추가하지만 현재 Workflow에 이미 승인 단계가 있다고 가정하지 않는다. 승인 단계가 있는 변경 작업과 반복적인 조회 작업은 다른 실행 권한으로 관리한다.

AWX는 중앙 1호기에 있어 이 노드가 꺼지면 신규 실행이 멈춘다. Git은 2호기에 있어 해당 노드 장애 중 새 Project sync가 실패한다. HA 시험 중 API 화면이 열렸다는 사실만으로 작업이 계속 실행될 것이라 기대하지 않는다.

10-1. Ansible 일괄 업그레이드: 커널·Apache·Tomcat을 한 대씩 바꾼다

AWX는 서버 등록뿐 아니라 승인한 운영 작업을 반복 실행하는 데 사용한다. 여기서는 커널 패치, Apache HTTP Server 패치, Tomcat 바이너리 교체를 예로 든다. 기본 대상은 fml-dev-app-01 한 대이며 DEV에서 결과와 복구 방법을 확인한 뒤 STG, PROD 순서로 별도 승인한다. 여러 대를 같은 작업으로 처리할 때에도 serial: 1로 한 대씩 적용하고, 실패하면 다음 대상을 멈춘다.

이 절의 플레이북은 추가 운영 예제다. 현재 실습 VM의 커널·Apache·Tomcat을 이 코드로 변경하거나 재부팅한 실행 결과를 뜻하지 않는다. 커널·Apache의 정확한 목표 RPM은 현재 저장소와 대상에서 확인해 입력해야 한다. 이 예제는 로드밸런서에서 대상을 자동 제외하지 않는다. 커널은 재부팅, Apache·Tomcat은 서비스 중단이 있으므로 중단 시간과 점검 기간을 승인한 후 실행한다.

구축 보완 자료와 전체 운영 플레이북 받기. ZIP의 upgrade-examples/에는 네 플레이북, 변수 예제, RPM manifest 도구, Tomcat 파일 검증 도구, 복구 절차가 있다. 파일을 기존 자동화 Git 저장소의 automation/maintenance/로 복사한다. 기존 automation/files/known_hosts와 inventory/bootstrap.yml을 함께 사용한다. 다운로드 ZIP을 읽는 것만으로 AWX Project나 실행 컨테이너에 파일이 생기지는 않는다.

1. 정확한 버전과 파일을 준비한다

Rocky 패키지는 단순히 httpd 2.4처럼 쓰지 않고 NEVRA, 즉 패키지명·Epoch·Version·Release·Architecture를 고정한다. 온라인 준비 VM은 실제 대상과 같은 Rocky 10/x86_64로 만들고, 승인한 BaseOS/AppStream snapshot에서 목표 RPM과 의존 패키지를 다운로드한다. tools/fetch-rpms-online.sh는 검토한 정확 NEVRA 목록을 읽고 dnf download --resolve --alldeps로 수집한다. tools/rpm_manifest.py는 각 파일의 정확한 이름과 SHA256을 기록한다. 준비 VM의 의존 패키지를 이미 설치했다는 이유로 반입 목록에서 빠뜨리지 않는다. DNF 다운로드 기준

온라인망에서도 다운로드를 마친 승인 파일을 고정해서 배포한다. 폐쇄망에서는 같은 RPM 전체, manifest, 서명 키와 검증 기록, Tomcat archive를 조직의 반입 절차로 전달한다. 두 경우 모두 적용 플레이북은 외부 repository를 끄고 로컬 RPM 경로를 사용한다. 누락된 dependency나 잘못된 서명은 중단 사유다. Minimal ISO와 기존 Agent RPM만으로 새 커널·Apache·JDK의 모든 파일이 준비되는 것은 아니다. 새 Apache를 받는 동시에 변경되는 기존 의존 패키지의 이전 RPM도 확보해야 복구를 준비했다고 할 수 있다.

ZIP의 README에서 repository 설정·다운로드·manifest 생성·폐쇄망 반입·복구 명령을 순서대로 확인한다. vars/kernel.yml, vars/httpd.yml의 CHOOSE는 해당 서버에서 확인한 정확한 값으로 바꾼다. 예제는 존재 여부를 확인하지 않은 Rocky RPM 버전 숫자를 임의로 채워 넣지 않는다.

2. DEV 한 대를 사전 점검한다

RPM의 SHA256 일치와 실제 서명 존재는 별도로 검사한다. 검증 도구는 rpm --checksig --verbose의 실제 Signature …: OK를 요구하고 unsigned/digest-only, NOKEY, BAD를 거부한다. 적용용 DNF config에 gpgcheck=True, localpkg_gpgcheck=True를 명시하고 dnf task가 그 config를 사용한다. 로컬 RPM의 서명 검사는 기본 설정만 믿지 않는다. DNF 로컬 패키지 서명 설정

실행은 02에서 구성한 Linux 관리 노드 또는 AWX Execution Environment에서 한다. 대상 SSH 키, sudo 방식, Bastion 경로와 승인된 SSH host key가 먼저 준비되어야 한다. vars/change.yml을 만들고 아래처럼 입력한다. 기본값은 사전 점검용이다. 실제 변경은 승인 후 boolean을 true로 바꾼다. 암호와 토큰은 이 파일에 넣지 않는다.

maintenance_targets: [fml-dev-app-01]
change_id: DEV-MAINT-001
maintenance_approved: false
outage_approved: false

cd /opt/fullmoon-lab/automation/maintenance
# 02에서 준비한 archive checksum을 확인한 뒤 Docker에도 EE를 load한다.
sudo docker load -i /opt/fullmoon-lab/offline/images/fullmoon-ee-r2.tar
run_maintenance() {
  sudo docker run --rm --pull never --network host --user 0 \
    -v /opt/fullmoon-lab/automation:/runner/project:ro,z \
    -v /opt/fullmoon-lab/private/automation_ed25519:/root/.ssh/id_ed25519:ro,Z \
    -w /runner/project/maintenance \
    -e ANSIBLE_CONFIG=/runner/project/ansible.cfg \
    -e ANSIBLE_PRIVATE_KEY_FILE=/root/.ssh/id_ed25519 \
    localhost/fullmoon-ee:24.6.1-netbox3.23.0-r2 "$@"
}
run_maintenance ansible-inventory -i ../inventory/bootstrap.yml --host fml-dev-app-01
run_maintenance ansible-playbook -i ../inventory/bootstrap.yml preflight.yml \
  --limit fml-dev-app-01 -e @vars/change.yml -e change_id=DEV-KERNEL-001 -e maintenance_kind=kernel

maintenance_kind는 kernel, httpd, tomcat 중 작업에 맞게 선택한다. 사전 점검은 대상 이름/IP, OS, SSH, 기본 서비스, 파일 해시를 읽는 단계다. 패키지 설치·dependency 해석·업무 서비스 호환성 검증 결과를 뜻하지 않는다. 적용 플레이북에는 serial: 1, max_fail_percentage: 0, any_errors_fatal: true가 들어 있고, Limit과 승인 대상 목록이 정확히 일치하는지 검사한다.

새 ops01에 native Ansible이 있다고 가정하지 않고 02에서 준비한 EE image를 Docker에서 실행한다. K3s import와 Docker load는 각각 필요하다. 위 함수는 read-only 프로젝트와 개인키를 EE에 연결하고 대상 SSH와 ProxyCommand의 Bastion SSH가 같은 기본 identity를 사용하게 한다. 개인키 내용은 출력하지 않는다. 각 작업은 DEV-KERNEL-001, DEV-HTTPD-002, DEV-TOMCAT-003처럼 고유한 변경 번호를 사용하며, 실제 번호로 바꿔 기록한다.

3. 커널을 설치하고 실제 재부팅 결과를 확인한다

대상의 Ansible Python에는 python3-rpm 바인딩이 미리 있어야 한다. 온라인 초기 준비 또는 폐쇄망의 승인 RPM·의존 파일 반입 단계에서 구성하고 preflight로 import를 확인한다. 새 kernel-core 파일과 현재 실행 커널의 설치 RPM header를 읽어 Epoch·Version·Release 전체를 rpm.labelCompare로 비교하며, 같은 EVR이나 낮은 EVR이면 중단한다. 커널은 install-only 패키지이므로 allow_downgrade: false만으로 낮은 커널 선택을 막을 수 없다.

vars/kernel.yml에 정확한 kernel_target_release를 입력하고, 변경 변수에 reboot_approved: true, console_recovery_confirmed: true를 추가한다. 이전 실행 커널의 파일과 boot entry를 남기고, /boot 공간과 백업 공간, 외부 드라이버·Secure Boot 서명을 확인한다. 백업과 VirtualBox 콘솔을 준비하지 않은 상태에서 재부팅하지 않는다.

run_maintenance ansible-playbook -i ../inventory/bootstrap.yml kernel-upgrade.yml \
  --limit fml-dev-app-01 -e @vars/change.yml -e change_id=DEV-KERNEL-001

플레이북은 기존 커널과 기본 boot entry를 기록하고 /boot를 백업한다. 새 RPM을 설치한 뒤 새 커널과 이전 커널의 boot entry를 검사하고, grubby로 정확한 새 커널을 선택한다. 재부팅과 SSH 재접속 후 uname -r가 목표와 같은지 확인한다. sshd·chronyd·firewalld·zabbix-agent2가 active이며 SELinux가 Enforcing이어야 한다. Ansible reboot 동작

운영자는 이어서 Zabbix Latest data의 system.uptime과 실제 값이 다시 갱신되는지, 업무 앱의 주요 요청이 정상인지 확인한다. SSH가 돌아오지 않으면 뒤의 대상을 중단하고 VirtualBox 콘솔에서 이전 커널로 부팅한다. 이전 실행 버전은 /var/backups/fullmoon-maintenance/변경번호/호스트명/kernel-before.json에 기록되어 있다. 부팅 실패 상태에서 AWX가 자동으로 모든 복구를 수행한다고 가정하지 않는다.

4. Apache 설정과 VirtualHost 응답을 확인하며 패치한다

httpd-upgrade.yml은 Rocky RPM으로 설치된 기존 Apache의 패치 변경 예제다. 먼저 rpm -q httpd, 추가 모듈, systemctl cat httpd, httpd -t로 기존 설치를 확인한다. vars/httpd.yml에 현재/목표 release와 실제 VirtualHost의 Host 헤더, health URL, 기대 문자열을 입력한다. 기본 예제는 http://127.0.0.1/healthz.txt가 HTTP 200과 FULLMOON_HTTPD_OK를 반환하는 DEV 서비스를 전제로 한다. 실제 앱의 health endpoint가 있으면 그것을 사용한다.

run_maintenance ansible-playbook -i ../inventory/bootstrap.yml httpd-upgrade.yml \
  --limit fml-dev-app-01 -e @vars/change.yml -e change_id=DEV-HTTPD-002

현재 버전과 변경 전의 정상 응답을 확인하고, Apache를 중단한 뒤 /etc/httpd와 /var/www를 백업한다. 다른 프로세스가 쓰는 콘텐츠는 그 쓰기도 별도로 정지한다. 승인 RPM을 설치하고 정확한 설치 NEVRA를 대조한 뒤 httpd -t와 시작 후 health 응답을 확인한다. 추가 DocumentRoot, 환경 파일, 인증서, 외부 DB는 별도 백업 목록에 넣는다. 단순 정적 파일 응답 외에 로그인·DB 연결 같은 주요 업무 요청도 확인한다. Apache 설정 검사 기준

실패하면 서비스를 멈추고 Job을 실패 처리한다. 이전 RPM 목록과 설정 tar를 대조해 승인된 downgrade·설정 복원 절차를 수행하고, 이전 버전의 설정 검사와 같은 요청을 다시 확인한다. 복구용 RPM이 없으면 dnf history undo만으로 되돌아간다고 약속할 수 없다. 파일 복원은 새로 생긴 파일을 자동 삭제하지 않으므로 .rpmnew, .rpmsave와 모듈 파일도 확인한다.

5. Tomcat은 바이너리와 애플리케이션 영역을 나누어 교체한다

Tomcat 예제 목표는 공식 배포에서 확인한 10.1.60이며, 같은 10.1 계열의 더 높은 패치로만 이동한다. 기존 CATALINA_HOME은 /opt/tomcat/current 링크, CATALINA_BASE는 /var/lib/tomcat/fullmoon 외부 디렉터리로 분리한다. 설정·WAR·JDBC 파일은 base에 있고 바이너리는 버전별 release 디렉터리에 둔다. 기존 설치가 다른 구조라면 먼저 unit·경로와 정상 응답을 검토한다. Tomcat HOME/BASE 분리 구성

공식 SHA512와 OpenPGP 서명을 확인한 archive의 SHA256을 vars/tomcat.yml에 고정한다. JDK 경로와 systemd unit을 확인하고 tomcat_compatibility_approved: true, tomcat_config_reviewed: true를 추가한다. Tomcat 10.1은 Java 11+, Tomcat 11은 Java 17+가 필요하며, Tomcat 9의 javax.* 앱을 10/11의 jakarta.*로 옮기는 작업은 앱 수정과 별도 호환성 검증이 필요하다. 이 예제로 major 전환과 JDK 변경을 함께 처리하지 않는다. Tomcat 버전별 요구 조건, 공식 이행 가이드

DEV 데모의 webapps/ROOT/healthz.jsp에는 다음 응답을 둘 수 있다. 실제 앱에는 앱의 준비 상태와 주요 업무 요청을 별도로 확인한다.

<%@ page contentType="text/plain; charset=UTF-8" %>
FULLMOON_TOMCAT_OK
TOMCAT=<%= application.getServerInfo() %>
JAVA=<%= System.getProperty("java.version") %>

run_maintenance ansible-playbook -i ../inventory/bootstrap.yml tomcat-upgrade.yml \
  --limit fml-dev-app-01 -e @vars/change.yml -e change_id=DEV-TOMCAT-003

archive 경로와 해시를 검사한 뒤 새 release 디렉터리에 해제한다. Tomcat을 중단하고 외부 base를 백업한 후 current 링크를 교체한다. 같은 JDK/base로 catalina.sh configtest, 시작, 실제 JSP 응답을 확인하며 목표 Tomcat 버전까지 대조한다. 실패하면 이전 HOME 링크로 복귀해 다시 시작하고 응답을 확인한다. 복귀했어도 변경 Job은 실패로 남긴다. WAR·base 설정·DB schema까지 변경했다면 링크 원복만으로 되돌릴 수 없으므로 해당 데이터 복구 절차가 필요하다.

6. AWX에서 승인한 운영 작업으로 등록한다

1. Git 코드·변수·manifest를 검토해 커밋하고 AWX Project를 동기화한다. SCM revision을 변경 기록에 남긴다.
2. Resources → Templates → Add → Job Template에서 커널·Apache·Tomcat별 Template을 만들고 기존 Project, FullMoon approved bootstrap Inventory, SSH/become Credential, maintenance/*-upgrade.yml을 연결한다.
3. Job Type=Run, Limit=fml-dev-app-01, Forks=1, Job Slicing=1로 저장하고 동시 실행은 끈다. 변경 번호와 정확한 버전, 승인 boolean을 검토한 Extra Variables로 입력한다.
4. binary를 Git에서 제외했다면 실제 Execution Environment의 /runner/project/maintenance/artifacts/에서 읽을 수 있게 승인된 산출물 전달 절차를 마련한다. control VM의 디스크에 있는 파일과 execution pod에서 읽는 파일을 혼동하지 않는다. 이 경로가 아직 준비되지 않았다면 CLI로 DEV 한 대를 먼저 시험한다.
5. 별도 maintenance/preflight.yml Template을 실행한 뒤 승인한 적용 Job을 실행한다. Workflow는 Project sync → Preflight → Approval → Upgrade → Verify와 앱 확인 순서로 연결할 수 있다. boolean 가드는 권한 분리나 사람의 변경 승인을 대신하지 않는다.
6. 호스트별 이전/목표 버전, 백업 경로, 실행 결과, health 응답과 모니터링 재수집을 확인하고 점검 기간을 종료한다. 같은 조건의 STG를 승인한 다음 PROD로 진행한다.

AWX Job Template 공식 문서. 단순 Check 모드나 상위 Workflow의 초록색 상태만으로 커널 재부팅과 업무 정상 여부를 확인했다고 기록하지 않는다.

운영 작업 완료 체크리스트

• 정확한 기존/목표 버전과 Git 커밋, RPM 의존 파일, checksum·서명을 기록했다.
• DEV 한 대 Limit, 대상 이름/IP, Bastion 접속 경로, 점검 기간과 중단 승인이 맞다.
• 백업·이전 RPM·콘솔 복구 경로를 준비하고 동일 조건의 복구 시험을 했다.
• OS 또는 서비스의 실제 버전, 기본 서비스, 앱 응답, 로그 오류와 Zabbix 값 재수집을 확인했다.
• DEV 결과를 검토하고 STG·PROD 각각의 적용 승인과 결과를 남겼다.

이 체크리스트는 예제를 실행할 때 기록할 항목이며, 현재 실습에서 완료된 결과로 표시하지 않는다.

11. NetBox: 자산 종류·환경·주소를 구분하는 방법

NetBox는 “지금 응답하는 서버 목록”보다 자산과 주소의 기준 정보를 관리하는 역할에 가깝다. 살아 있는지 여부는 Zabbix에서 보고, 자산이 어떤 환경에 속하고 어떤 주소와 역할을 가져야 하는지는 NetBox에서 확인한다.

11-1. 물리 장비와 VM을 다른 객체로 관리한다

VM을 물리 Device로 중복 등록하거나 모든 정보를 메모에만 몰아넣지 않는다. VM은 Virtual Machine 모델, 물리 자산은 Device 모델을 사용한다. HCI를 추가한다면 물리 호스트는 Device, 가상화 단위는 Cluster, 게스트는 VM으로 구분해 관계를 표현한다.

등록 결과는 PROD·DEV·STG의 VM 세 대다. 이름, 활성 상태, Site, 가상 CPU, 메모리, 디스크, 관리 IP를 한 목록에서 확인한다. Cluster와 Rack은 이번 실습에서 채우지 않은 항목이므로 실제로 연결된 것처럼 설명하지 않는다.

11-2. 환경과 역할은 섞지 않는다

현재 기본 Role은 Server, Platform은 Rocky Linux 10, Site는 FullMoon Lab이다. PROD·DEV·STG는 환경 구분이며, DB·WEB·WAS 같은 서비스 역할과 다르다. 현재 코드에서는 서비스 탐지 결과가 service_role Custom Field에 기록된다. 서비스 소유팀이나 업무 이름은 별도 검토 필드로 추가할 수 있다.

env_type=PROD와 수집 완료 상태, 빈 오류 목록을 확인한다. backup_enabled=False는 수집기가 백업 제품 흔적을 찾지 못했다는 의미이며, 백업 정책 준수 여부를 대신 판정하지 않는다.

수집값인 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 주소 필드와 자유 형식 메모에 적힌 주소가 서로 다르면 메모를 기준으로 접속하지 않는다.

대표 주소는 VM 상세의 Primary IPv4에서 확인한다. CPU 모델과 메모리 등은 게스트가 인식한 수집값이므로 VirtualBox 호스트 PC의 전체 사양과 구분한다.

관리 NIC enp0s3에 10.77.20.101/24가 연결돼 있다. 자산 이름만 있는 목록을 만드는 데서 끝내지 않고, VM → 인터페이스 → 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의 원본을 수정한다.

동기화 후 AWX에는 같은 세 호스트와 tag_auto, tag_vm, 환경별 그룹이 표시된다. imported는 소스로부터 가져왔다는 뜻이다. NetBox에서 승인 정보를 수정한 뒤 source sync를 거쳐 이 목록과 호스트 변수를 확인한다.

12-2. 신규 자산 등록

새 대상은 승인 목록과 신원 확인 후 Onboard Workflow로 등록한다. 물리 장비의 구매·랙 배치 정보를 미리 관리하려면 NetBox에 계획 자산을 만들 수 있지만, 자동 등록과 동일 이름·식별자·IP를 사용하는지 대조해야 한다. 장비 등록 폼에 이름만 적었다고 PXE 설치나 방화벽 허용까지 수행되지는 않는다.

12-3. IP 변경과 서버 교체

IP 변경은 NetBox 값 하나만 바꾸는 작업이 아니다. 승인 inventory, 대상 OS, Bastion PermitOpen, Zabbix 경로, SSH 신원을 함께 검토한다. 현재 자동화는 기존 IP·Proxy 경로가 다르면 중단하므로 계획된 변경 절차로 처리한다. 재설치로 machine ID가 달라진 경우도 자동 등록을 억지로 통과시키지 않고 같은 자산을 교체한 것이 맞는지 승인한다.

12-4. 퇴역·운영 제외

1. 담당자와 데이터 보존·백업 필요 여부를 확인하고 변경 기록을 만든다.
2. 대상에 실행될 AWX 예약 작업과 설치 완료 컨트롤러의 승인 목록을 검토해 신규 작업을 막는다.
3. Zabbix 대상 모니터링을 계획에 따라 비활성화하고 기존 장애 기록은 보존한다.
4. NetBox의 상태·설명에 운영 제외를 반영하고, 필요하면 자동화 대상 태그를 정리한다.
5. NetBox inventory source를 동기화하고 AWX 실행 대상에서 제외됐는지 확인한다.
6. 서비스와 주소 사용이 끝난 것을 확인한 뒤 IP·계정·인증서·장비 처분을 각각 처리한다.

NetBox 상태 변경은 Zabbix 호스트 삭제나 VM 삭제를 자동으로 수행하지 않는다. 장비를 먼저 삭제해 이력을 잃거나, 실제 서버가 아직 사용하는 주소를 바로 재할당하지 않는다.

13. 일일·주간·월간 운영 루틴과 보고 양식

일일 보고는 다음 틀로 작성하면 된다. 정확한 시각은 장애 경과를 설명하는 데 필요한 경우에만 추가한다.

대상 기간 / 작성자:
운영 상태: 정상 또는 영향 서비스 명시
주요 문제: 현상 / 영향 범위 / 원인 또는 조사 상태
완료한 조치: 작업 내용 / Git 커밋 또는 AWX Job / 확인 결과
미완료 항목: 담당자 / 다음 조치 / 예정일
자산 변경: 신규 / 주소 변경 / 운영 제외
다음 작업: 승인 여부 / 대상 / 되돌릴 방법

주간에는 같은 문제가 반복되는 원인과 자동화 개선을, 월간에는 용량·지원 종료·복원 가능성을 추가한다. 평균 수치만 나열하지 말고 “어떤 판단과 작업으로 이어지는가”를 적는다. 알려진 장애가 사라졌는지, 수집 자체가 끊겨서 보이지 않는지도 구분한다.

14. 운영 장애별 첫 점검과 인수인계 기준

관리 경로에서 확인할 수 있는 최소 명령은 다음과 같다. 컨테이너 이름과 파일 위치는 이 실습 기준이며, 실제 설치 위치와 일치하는지 확인한다.

# 중앙 노드: 서비스 준비 상태
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·실제 수신 확인, 백업과 격리 복원 결과 확인, 담당자·승인·실패 대응 경로 확인. 이 항목을 실제로 수행한 뒤 결과를 기록해야 하며, 매뉴얼의 예시를 읽은 것만으로 완료 처리하지 않는다.