운영을 잇다 01 — Zabbix·NetBox·AWX 통합 인프라 설계
EdwardMoon
이 글에 자주 나오는 용어
- PROD·DEV·STG: 각각 운영·개발·검증 환경입니다.
- HA(고가용성): 일부 서버가 고장 나도 다른 서버가 역할을 이어받도록 구성하는 방식입니다. 실제 전환 시간과 남는 장애 지점은 별도로 확인합니다.
- Proxy·Bastion: Proxy는 모니터링 데이터를 모아 전달하는 중계 서버, Bastion은 관리자가 SSH로 접속할 때 거치는 경유 서버입니다.
- 인벤토리·Workflow·Job: 각각 자동화 대상 서버 목록, 여러 작업을 연결한 실행 흐름, 개별 실행 작업입니다. 뒤의 번호는 실행 기록을 찾는 식별 번호입니다.
- VIP·IPAM·쿼럼: VIP는 서비스 접속용 공용 가상 IP, IPAM은 IP 주소와 자산의 관계 관리, 쿼럼은 여러 노드가 과반수로 장애와 역할을 판단하는 기준입니다.
서버 한 대를 설치하는 일은 운영 준비의 일부다. 누가 어떤 환경에 배치했는지, 어떤 소프트웨어가 실행 중인지, 어디로 접속해야 하는지, 장애를 어떻게 발견하고 복구할지까지 이어져야 운영 가능한 서버가 된다.
이 프로젝트는 Rocky Linux 서버의 설치부터 기본 설정, 상세 자산 등록, 자동화 인벤토리 갱신, 실제 모니터링 값 수신까지 연결하는 인프라 실습이다. Oracle VirtualBox 위에 중앙 운영망과 PROD·DEV·STG를 나누고, Zabbix·NetBox·AWX·Git·PXE를 하나의 운영 흐름으로 구성했다.
실습 환경은 개인 PC 한 대의 VM이다. 서비스와 VM 장애를 시험하는 환경이며, 물리 호스트나 스토리지까지 이중화한 운영 시스템은 아니다. 검증 결과는 별도 검증 프로젝트의 실행 기록과 관측값을 기준으로 구분한다.
이 글의 순서
- 1. 프로젝트 개요
- 2. 해결하려는 운영 문제
- 3. 서버 구성과 네트워크
- 4. 한 서버가 운영에 합류하는 과정
- 5. 첨부 자산 수집 YAML을 어떻게 반영했는가
- 6. 왜 이렇게 설계했는가
- 7. 장애 시나리오와 가용성의 경계
- 8. 온라인망과 폐쇄망을 함께 고려한 운영
- 9. 이 프로젝트에서 보여주려는 역량
- 10. 이어서 읽기와 기술 근거
- 함께 읽기와 구성 자료
1. 프로젝트 개요
| 항목 | 내용 |
|---|---|
| 주제 | 서버 프로비저닝과 자산·구성·관제의 연결 |
| 목표 직무 | 시스템 운영자, 서버 관리자, 시스템 엔지니어 |
| 구축 방식 | Oracle VirtualBox 7.2.18, Rocky Linux 10.2 |
| 중앙 서비스 | Zabbix 7.0 LTS HA, NetBox 이중 애플리케이션, AWX |
| 자동화 기반 | Git 관리 플레이북, AWX 자동화 실행 흐름(Workflow), NetBox API/IPAM, Zabbix API |
| 환경 분리 | CORE / PROD / DEV / STG의 네 내부망과 명시적 라우팅 |
| 설치 대상 | 빈 디스크를 가진 승인된 VM. 물리 서버 확장 경로는 별도 설명 |
| 문서 구성 | 01은 설계와 판단, 02는 구축 절차, 03은 실제 시험과 한계, 04는 일상 운영과 변경 작업 |
도구별 설치 완료보다 한 서버의 식별자와 관리 IP가 설치·자산·자동화·관제를 거치며 일치하는지를 완료 기준으로 삼았다. API가 정상 응답(HTTP 200)을 반환하더라도 인벤토리에 대상이 없거나 Zabbix 최신 값이 들어오지 않으면 서버 등록·운영 준비 성공으로 처리하지 않는다.
PROD·DEV·STG 세 대상의 실제 서버 등록과 운영 준비를 완료했다. AWX 자동화 실행 흐름(Workflow) 22·30·38에서 자산 등록·인벤토리 갱신·최신 관제 값 확인까지 성공했다. 중앙 노드 양방향 전원 손실, Proxy 전송 단절과 지연 데이터 복구, 자산 충돌 거부, 별도 DB 복원도 시험했다. 각 성공의 조건과 미검증 범위는 검증 글에 남겼다.
2. 해결하려는 운영 문제
OS 설치, 엑셀 자산대장 갱신, Ansible 호스트 추가, 모니터링 등록을 따로 수행하면 누락과 불일치가 생긴다. 재설치한 서버가 이전 자산에 덮어써지거나, NAT 주소가 관리 IP로 등록되거나, 관제에 호스트만 있고 데이터가 없는 상태도 발생한다.
이를 줄이기 위해 승인된 호스트명·환경·관리 IP를 입력 기준으로 정하고, 실제 게스트에서 읽은 hostname·운영체제 고유 식별값(machine ID)·인터페이스와 비교한다. NetBox에는 문자열 IP뿐 아니라 VM/Device → Interface → IPAddress → primary_ip4 관계를 만들고, AWX는 그 관계에서 인벤토리를 가져온다. 재등록 시 NetBox의 machine ID와 IP 할당 관계를 확인하고, Zabbix에서는 자동화 관리 태그와 기존 수집 경로를 검사한다. NetBox에 같은 이름의 수동 자산이 먼저 있으면 관리자가 식별 정보와 관리 책임을 확인한 뒤 자동화 대상으로 편입한다.
두 번째 과제는 장애 범위를 설명하는 것이다. Zabbix Server 두 개가 있다는 사실만으로 DB까지 HA가 되는 것은 아니다. NetBox Web 두 개 역시 PostgreSQL·Redis·공유 미디어·접속 주소가 함께 동작해야 의미가 있다. 각 계층의 전환 조건과 남는 단일 장애점을 따로 표시했다.
인터랙티브 아키텍처 — 전체 구조와 운영 흐름
3. 서버 구성과 네트워크
실제 PC는 Windows 11 Pro, Intel Core Ultra 9 185H(16코어/22논리 프로세서), OS가 인식한 총메모리 약 31.4GiB, 2TB SSD다. VM에는 필요한 만큼만 메모리를 배분하고 PXE 설치 대상은 순차 실행한다. 설치할 때 4GiB가 필요한 대상도 설치 후에는 1GiB로 줄인다.
| 호스트명 | 주소 | vCPU / 메모리 | 배치한 역할 |
|---|---|---|---|
| fml-ops-01 | 10.77.10.11 | 4 / 7GiB | NetBox App·Worker, Zabbix Server·Web, PostgreSQL/Patroni, Redis/Sentinel, etcd, HAProxy/Keepalived, K3s/AWX |
| fml-ops-02 | 10.77.10.12 | 1 / 3GiB | 중앙 1호기의 이중화 서비스, Git 원격 저장소(bare repository), PDF 보고 생성 서비스·실습 내부 메일 수신함 |
| fml-quorum-01 | 10.77.10.13 | 1 / 768MiB | 세 번째 etcd·Sentinel, NetBox 미디어 NFS |
| fml-gateway-01 | 10.77.10.1 및 환경별 .1 | 2 / 512MiB | 네 내부망 라우팅, 환경별 접근 정책 |
| fml-provision-01 | 10.77.10.20 및 환경별 .20 | 1 / 1GiB | DHCP, DNS, HTTP 저장소, PXE/Kickstart, NTP |
| fml-edge-prod-01 | 10.77.20.10 | 1 / 768MiB | PROD Zabbix Active Proxy + SSH Bastion |
| fml-edge-dev-01 | 10.77.30.10 | 1 / 768MiB | DEV Zabbix Active Proxy + SSH Bastion |
| fml-edge-stg-01 | 10.77.40.10 | 1 / 768MiB | STG Zabbix Active Proxy + SSH Bastion |
| fml-prod-app-01 | 10.77.20.101 | 1 / 설치 4GiB·운영 1GiB | PROD 설치·자동화·모니터링 대상 |
| fml-dev-app-01 | 10.77.30.101 | 1 / 설치 4GiB·운영 1GiB | DEV 설치·자동화·모니터링 대상 |
| fml-stg-app-01 | 10.77.40.101 | 1 / 설치 4GiB·운영 1GiB | STG 설치·자동화·모니터링 대상 |
호스트 이름에서 ops는 운영 서비스, quorum은 장애 판정, edge는 환경 진입점, provision은 설치 기반을 뜻한다. 운영체제가 인식하는 FQDN은 호스트명.fullmoon.test다. 공개 사이트 도메인과 실습 DNS를 구분했다.
| 네트워크 | VirtualBox Internal Network | 목적 |
|---|---|---|
| 10.77.10.0/24 | fml-core | 중앙 서비스·API·데이터 계층 |
| 10.77.20.0/24 | fml-prod | 운영 환경 실습 |
| 10.77.30.0/24 | fml-dev | 개발 환경 실습 |
| 10.77.40.0/24 | fml-stg | 검증 환경 실습 |
환경별 PXE 대상에는 NAT나 브리지 NIC를 붙이지 않는다. 중앙에서 대상 서버로 가는 SSH는 해당 환경의 Bastion을 거친다. 환경 간 통신은 기본 차단하고 필요한 소스·목적지·포트를 명시한다. 초기 패키지 반입에 사용한 관리 VM의 NAT와 내부 서비스 경로는 구축 글에서 구분한다.
4. 한 서버가 운영에 합류하는 과정
| 단계 | 수행 내용 | 다음 단계로 넘기는 기준 |
|---|---|---|
| 승인·설치 | MAC allowlist, 빈 디스크 검사, iPXE/Kickstart로 Rocky 설치 | 승인된 hostname·IP, SSH host key, 설치 완료 표식 |
| Git·AWX | Git main 동기화와 승인 인벤토리 사용, 실행에 사용한 커밋 기록 | Git 소스 동기화와 대상 식별 확인 |
| 기본 설정 | Bastion 경유 SSH, 실습 CA, 내부 RPM 저장소, Agent 2와 PSK 설정 | 인증서·RPM 서명 검증, 서비스 실행 |
| 자산 등록 | 실제 Linux 정보 수집, NetBox VM/Device와 IPAM 연결 | 자산 ID·인터페이스·primary_ip4 일치 |
| 인벤토리 갱신 | NetBox 대상 서버 목록 연동 기능(inventory plugin)으로 AWX 대상 서버 목록 갱신 | 관리 IP·환경 변수를 가진 호스트 생성 |
| 관제 검증 | 환경 Proxy·템플릿을 지정해 Zabbix API 등록 | 서버의 최근 가동 시간(system.uptime) 값과 수집 시각 확인 |
원격 서버에 NetBox 관리자 암호를 배치하지 않는다. 원격 수집은 필요한 범위에서 관리자 권한으로 실행하고, API 요청은 AWX Execution Environment에서 자격 증명을 주입받아 실행한다. SSH 개인키는 Bastion에 복사하지 않는다.
AWX의 인벤토리 자동 추가는 구현 가능한 기능이다. NetBox 공식 Ansible inventory plugin을 SCM inventory source로 연결하고, 등록 작업이 성공한 뒤 Workflow가 대상 서버 목록 동기화와 검증 작업을 이어서 실행하도록 구성했다. NetBox 토큰은 자산 쓰기와 인벤토리 읽기 용도를 분리했다.
PXE 이후의 연결은 중앙의 설치 완료 컨트롤러가 맡는다. 승인된 SSH host key와 설치 완료 표식·hostname·운영체제 고유 식별값(machine ID)을 확인한 뒤 해당 서버의 Workflow를 시작한다. 최초 서버 신원 승인은 관리자의 확인 단계로 남기고, 승인 후에는 자산·인벤토리·관제 등록을 연속 실행한다. 등록을 다시 요청했을 때 기존 machine ID와 새 값이 다르면 덮어쓰기를 거부한다. 성공 이력이 있는 대상은 컨트롤러가 계속 재검사하지 않으므로, 재설치 때에는 새 SSH 신원과 machine ID를 관리자가 확인한 뒤 해당 대상의 재등록 상태를 준비한다.
5. 첨부 자산 수집 YAML을 어떻게 반영했는가
첨부 YAML은 단순한 hostname 등록기가 아니다. 실행 중인 Linux 프로세스와 /proc 정보를 출발점으로 OS·CPU·디스크·네트워크·제품·가상화·백업 에이전트 흔적을 수집하는 자산 대장이다. 이 의도를 유지하고 원본 Custom Field 34개에 수집 상태·시각·오류·운영체제 고유 식별값(machine ID) 네 항목을 추가했다.
| 수집 영역 | 유지한 정보 | 해석 시 주의할 점 |
|---|---|---|
| OS | 배포판, 커널, 주요 버전 지원 종료일 | Rocky 10의 EOL과 개별 minor release의 갱신 정책은 다름 |
| CPU·메모리 | 모델, 소켓, 코어, 논리 CPU, 클럭, 메모리 | VM 내부에서 관측한 값이며 물리 PC 전체 사양이 아님 |
| 저장장치 | 총 bytes/GiB, lsblk 파티션 구조, fdisk 결과 | NetBox 필드 단위에 맞게 변환하고 반올림 손실 최소화 |
| 네트워크 | 주소·프리픽스·마스크·게이트웨이·인터페이스 | 관리 NIC/IP를 명시해 NAT·컨테이너 주소 오선택 방지 |
| 제품·역할 | 실행 DB/WEB/WAS/Java와 경로·버전 근거 | 설치 패키지만으로 실행 서비스를 단정하지 않음 |
| 백업 | NetBackup vnetd 등 에이전트 감지 | 에이전트 존재는 백업 성공·복원 가능의 증거가 아님 |
| 식별·품질 | 운영체제 고유 식별값(machine ID), 수집 시각, 수집 완료/일부 수집 실패, 오류 | 실패한 수집값으로 기존 정상값을 0·빈 배열로 덮어쓰지 않음 |
원본의 현장 주소·Site·환경 판정 규칙은 이 실습의 PROD/DEV/STG와 명시적 대상 서버 목록의 변수로 바꿨다. primary_ipv4 문자열만 저장하던 부분에 NetBox 네이티브 IPAM 관계를 추가했다. 기존 승인 Site·역할·Platform·사용자 태그는 수집 결과로 무조건 대체하지 않는다.
모든 상용 DB/WAS의 버전 탐지를 설치 검증한 것은 아니다. 실행 파일의 소유권·허용 목록·namespace를 확인하고, 불확실한 시작 스크립트를 root로 실행하지 않는다. 확인하지 못한 버전은 미확인으로 남긴다. 컨테이너 내부 제품 수집도 호스트 자산 수집과 별도 과제로 구분한다.
6. 왜 이렇게 설계했는가
중앙 두 VM에 여러 서비스를 배치한 이유
운영 환경에서는 역할별 자원·보안·장애 격리를 고려해 서버를 나누는 편이 유리하다. 이 실습은 32GB PC 안에서 서비스 간 연동과 장애 전환을 검증해야 하므로 중앙 두 VM에 역할을 모았다. NetBox·Zabbix·데이터 서비스는 Compose 프로젝트와 볼륨·계정으로 구분하고, AWX는 공식 Operator의 설치·관리 구조를 따르도록 K3s에 배치했다.
다만 컨테이너를 나눴다고 VM 장애까지 격리되지는 않는다. 다수 서비스는 host network를 사용하고, CPU·메모리·디스크 I/O·커널·VM 재시작 영향을 공유한다. 메모리 제한과 작업 동시성 제한은 이 조건에서의 자원 관리 수단이다.
Zabbix Server HA와 Proxy를 나눈 이유
중앙 Server 두 개는 Native HA로 활성 서버와 예비 서버 역할(Active/Standby)을 나누고 공통 DB를 사용한다. 환경별 Active Proxy는 로컬 Agent의 데이터를 모아 중앙으로 전달한다. 중앙 연결 단절 시 Proxy의 디스크 버퍼가 수집을 이어갈 수 있지만, Proxy VM 자체가 중단되면 그 기능도 사라진다. Agent→Proxy와 Proxy→Server는 각각 PSK로 인증한다.
NetBox HA를 데이터 계층까지 나눈 이유
NetBox App·Worker를 두 중앙 노드에 배치하고 PostgreSQL은 Patroni, Redis는 Sentinel, 접속 주소는 Keepalived/HAProxy로 구성했다. NetBox 두 노드는 같은 SECRET_KEY와 토큰 pepper를 사용하며, 미디어는 공통 NFS를 참조한다. 세 번째 etcd/Sentinel은 두 중앙 노드 중 한 대를 잃었을 때의 과반수를 확보한다.
NFS 자체는 단일 노드다. 따라서 이 구성의 NetBox HA 범위는 중앙 노드 한 대 장애를 중심으로 정의한다. 미디어 저장소 장애까지 견디는 완전한 스토리지 HA라고 표현하지 않는다. PostgreSQL은 synchronous mode를 사용하지만 strict mode가 아니므로 모든 장애에서 데이터 손실이 전혀 없다는 보장(RPO 0)을 할 수는 없다.
Proxy와 Bastion을 함께 둔 이유
각 환경의 관제 수집점과 자동화 진입점을 한 VM에 모아 작은 실습의 자원 사용을 줄였다. Bastion은 승인된 대상의 SSH 포트로만 forwarding하고 대화형 셸·agent forwarding을 제한한다. 이 배치는 Proxy/Bastion 한 대 장애가 관제와 신규 자동화에 함께 영향을 주는 대가가 있다. 실제 운영에서는 규모와 보안 경계에 따라 분리할 수 있다.
Git과 AWX를 둔 이유
플레이북 파일이 있다는 것과 같은 설정을 재현할 수 있다는 것은 다르다. Git 소스 버전 식별값(커밋), AWX의 Git 소스 동기화, 작업 번호, 대상 서버 목록, Execution Environment 버전을 연결하면 어떤 코드로 무엇을 변경했는지 추적할 수 있다. NetBox를 실제 자산의 기준으로 사용하면서 최초 설치의 승인 목록은 별도 최초 설치용 승인 서버 목록으로 유지한다.
현재 자동화는 실행 전에 main을 동기화하고 실제 사용한 커밋을 AWX 실행 기록에 남긴다. 변경 승인이 필요한 운영 작업은 검토한 커밋이나 이동하지 않는 태그를 지정한다. Zabbix Native HA는 관제 Server 역할을 전환하지만, 중앙 2호기만의 PDF 생성 서비스·내부 메일 수신함까지 자동 승계하지 않는다.
7. 장애 시나리오와 가용성의 경계
| 장애 | 기대하는 생존 범위 | 중단 또는 추가 확인이 필요한 기능 |
|---|---|---|
| 중앙 1호기 중단 | 중앙 2호기의 NetBox/Zabbix Web, 데이터 계층과 Zabbix 역할 전환 | AWX·K3s는 1호기 단일 구성이라 자동화 실행 중단 |
| 중앙 2호기 중단 | 중앙 1호기 서비스와 데이터 계층 생존 조건 확인 | Git 소스 동기화와 PDF 보고 생성·내부 수신 중단. 관제 Server 역할 전환과 보고 기능의 가용성을 따로 확인 |
| PROD↔중앙 단절 | PROD Proxy가 로컬 수집을 버퍼링하는지 확인 | 중앙 최신 값과 Bastion 원격 작업 갱신 지연 |
| PROD Edge 중단 | DEV/STG 경로의 독립성 확인 | PROD Proxy 수집과 Bastion 경유 신규 작업 중단 |
| quorum/NFS 중단 | 두 중앙 노드가 모두 생존하면 etcd/Sentinel 과반수 유지 가능 | 미디어 읽기·쓰기와 관련 작업 영향, 추가 노드 장애 여유 상실 |
| DB 두 노드 중단 | Proxy 버퍼의 유효 범위 확인 | NetBox·Zabbix·AWX의 DB 의존 기능 중단 |
| Gateway/PXE 중단 | 기존 서비스와 설치·라우팅 의존성을 구분 | 대역 간 경로 또는 신규 설치/DNS/NTP 의존 기능 영향 |
| 물리 PC 중단 | 이 실습 안에는 대체 물리 호스트 없음 | 모든 VM 중단 |
이 표는 설계상의 예상 범위다. 실제 실시한 장애, 수집 공백, 복구 시각, 데이터 보존 여부는 검증 글에서 별도로 판정한다. 화면의 장애 애니메이션은 실제 서버 상태를 조회하거나 명령을 실행하지 않는다.
8. 온라인망과 폐쇄망을 함께 고려한 운영
온라인망에서는 공식 저장소에서 검증한 버전을 내려받고 이미지 digest·RPM 서명·Git 소스 버전 식별값(커밋)을 기록한다. 폐쇄망에서는 같은 버전의 RPM과 의존성, 컨테이너 이미지, K3s 이미지, AWX 작업 실행환경(EE), Ansible collection, Git bundle, OS 설치 트리를 반입한다. CA·DNS·NTP도 내부에서 제공해야 한다.
인터넷이 없는 대상 서버에는 내부 HTTP 저장소로 서명된 RPM을 제공하고, API는 실습 CA로 검증한 HTTPS를 사용한다. 내부 RPM 저장소의 HTTP 전송과 API의 HTTPS 인증은 구분한다. 데이터 계층의 내부 평문 연결은 현재 실습의 한계이며 운영 적용 시 TLS·비밀 관리·접근 감사를 보강해야 한다.
9. 이 프로젝트에서 보여주려는 역량
이 실습의 핵심은 도구의 수가 아니라 운영 결과를 연결하는 능력이다. 설치 단계의 식별자를 NetBox와 Zabbix까지 이어가고, 재실행과 부분 실패를 고려하며, 정상 상태뿐 아니라 장애 후 무엇이 유지되고 무엇이 멈추는지 검증한다.
구축 과정에서 확인한 저장소 경로 오류, AWX 설치·실행환경 문제, HAProxy 상태 검사와 NetBox 장애 후 응답 지연은 증상·원인·수정 방법·확인 결과를 담아 블로그 글로 발행했다. NetBox API 스키마와 토큰 방식은 호환성 점검 기록으로 정리했다. VirtualBox 펌웨어·가상 CPU·설치 메모리 문제도 별도의 블로그 글에 기록했다.
향후 운영 환경으로 확장할 때에는 물리 호스트와 스토리지 이중화, AWX/Git 가용성, 전 구간 암호화, 외부 비밀 저장소, 백업 정책과 정기 복원 시험을 우선한다. 실제 물리 서버의 UEFI PXE·NIC 드라이버·RAID·BMC 연동은 이 VM 시험과 별도로 검증해야 한다.
10. 이어서 읽기와 기술 근거
구축 절차와 검증 결과는 같은 포트폴리오의 프로젝트 시리즈로 연결한다. 각 글의 상태와 범위는 실제 시험 기록을 기준으로 갱신한다.
Zabbix Native HA, Zabbix 릴리스 수명주기, NetBox 필수 설정과 Redis Sentinel, AWX Operator 설치, NetBox Ansible inventory plugin, Rocky Linux 지원 주기.
함께 읽기와 구성 자료
포트폴리오 원문 · 온라인망·폐쇄망 구축 가이드 · 장애 시나리오·검증 기록
실습 설정·자동화 소스 ZIP · ZIP 무결성 확인값(SHA-256)
공개 ZIP에는 구성 템플릿과 자동화 소스를 담았습니다. OS·RPM·컨테이너 이미지와 자격 증명은 포함하지 않습니다. 자신의 주소·공개 CA·승인 SSH 키·비밀 저장소로 구성한 뒤 적용합니다.