1nfratech1nfra Tech

LMS의 DB는 Kubernetes로 옮기지 않고 VM으로 남겼습니다. 대신 다른 호스트에 복제본 VM을 만들어 PostgreSQL 스트리밍 복제로 실시간 사본을 두고, 앱은 primary에만 붙는 VIP로 접속하게 했습니다. 이 글에서는 이중화 방식 선택, 복제 설정과 검증, VIP, 백업과 모니터링을 정리합니다. 홈랩 재구성 시리즈 8편이며, 이전 글은 Docker 컨테이너와 LMS를 Kubernetes로 옮기기입니다.이전을 마친 구성입니다. 요청은 Gateway를 거쳐 Pod로 가고, 앱은 primary에만 붙는 DB VIP로 접속합니다1. 이중화 방식 고르기LMS DB는 호스트 1의 PostgreSQL 15 VM 1대에서 실행되고 있었습니다. 실시간 사본이 없어 호스트가 멈추면 DB도 함께 멈추는..

이번에는 Docker VM에서 돌던 작은 서비스 3개와 LMS(학습 관리 시스템)를 옮겼습니다. 이미 컨테이너로 돌던 서비스라 VM에서 쓰던 컨테이너 이미지를 그대로 썼습니다. 가장 신경 쓴 점은 노드 하나가 멈춰도 다른 워커에서 계속 동작하게 하는 것입니다. 이 글에서는 Docker 서비스를 옮긴 방법, 두 곳에서 동시에 돌면 안 되는 알림 봇을 옮기는 순서, LMS를 노드 장애에 견디게 만든 설계와 전환 과정을 정리합니다. 홈랩 재구성 시리즈 7편이며, 이전 글은 Zabbix 5.4를 7.0 LTS로 옮기고 Kubernetes까지 모니터링하기입니다.7편을 마친 시점의 구성입니다. Docker 서비스와 LMS를 옮기고, 노드가 멈춰도 다른 워커에서 다시 실행되게 했습니다1. Docker VM의 서비스 ..

홈랩의 모니터링 서버에서는 지원이 끝난 Zabbix 5.4를 사용했습니다. Zabbix 7.0은 더 새로운 MySQL과 PHP가 필요해서, 제자리 업그레이드 대신 새 VM을 만들어 DB를 옮기는 방식으로 이전했습니다. 모니터링이 멈춘 시간은 약 18분이었고, 이전한 뒤에는 Zabbix의 공식 연동으로 Kubernetes 클러스터까지 한 화면에서 확인할 수 있게 했습니다. 이 글에서는 새 VM으로 옮긴 이유와 전환 순서, 주의할 점, Kubernetes 모니터링과 웹 감시 설정을 정리합니다. 홈랩 재구성 시리즈 6편이며, 이전 글은 PHP 사이트 6개와 MySQL을 옮기고 Gateway 하나로 합치기입니다.6편을 마친 시점의 구성입니다. Zabbix를 7.0 버전이 설치된 새 VM으로 옮기고, 로드밸런서 ..

두 번째 이관 대상은 VM 한 대에서 포트로 나눠 운영하던 PHP 사이트 6개와 MySQL이었습니다. 사이트마다 이미지를 따로 만들고 DB는 StatefulSet으로 옮겼으며, 입구는 Gateway 하나로 합쳐 호스트 이름으로 사이트를 나눴습니다. VM처럼 포트 리스너로 나누는 방식도 시도했지만, Cilium Gateway에서는 사이트가 서로 섞여서 호스트 이름 방식으로 정했습니다. 이 글에서는 이미지 설계, MySQL 이관, Gateway 통합과 호스트 이름 라우팅을 정리합니다. 홈랩 재구성 시리즈 5편이며, 이전 글은 Jenkins와 Argo CD로 홈랩 CI/CD 구성하기입니다.5편을 마친 시점의 구성입니다. 입구를 Gateway 하나로 합치고 호스트 이름으로 사이트를 나눴습니다1. 이관 대상 항목..

처음 서비스를 옮길 때는 이미지를 노드에 직접 넣었습니다. 지금은 앱 소스를 GitHub에 push하면 Jenkins가 이미지를 만들어 클러스터 안의 이미지 저장소에 올리고, 배포용 Git 저장소의 이미지 태그를 고쳐 커밋합니다. 그러면 Argo CD가 그 커밋대로 클러스터에 배포합니다. 이 글에서는 내부 이미지 저장소와 노드 설정, 저장소 두 개와 권한 나누기, Jenkins 파이프라인, 소스를 Git으로 옮길 때 확인한 것, 자동 동기화에서 데이터를 지키는 설정을 정리합니다. 홈랩 재구성 시리즈 4편이며, 이전 글은 웹 서비스 VM을 Kubernetes로 옮기고 검증하기입니다.4편에서 붙인 배포 흐름입니다. 앱 저장소에 push하면 Jenkins가 빌드하고 Argo CD가 클러스터에 반영합니다1. 왜..

VM에서 돌던 서비스를 컨테이너로 옮길 때 가장 중요한 것은 옮긴 뒤에도 기존과 똑같이 동작하는지 확인하는 일입니다. 첫 대상인 웹 사이트에서는 전환 전에 문제 네 가지를 찾았습니다. 기존 VM과 응답을 비교해 HTTP 200만으로는 보이지 않던 문제 세 가지가 나왔고, 쓰기 기능 시험에서 하나가 더 나왔습니다. 이 글에서는 첫 대상을 고른 기준, 서비스가 쓰는 데이터(상태)를 나눈 방법, 기존 VM과 응답을 비교해 검증한 과정, 전환과 되돌리기 계획을 정리합니다. 홈랩 재구성 시리즈 3편이며, 이전 글은 홈랩 Kubernetes 클러스터 설계와 노드 배치입니다.3편을 마친 시점의 구성입니다. 첫 웹 사이트로 들어오는 요청은 NAS 프록시에서 클러스터로 바로 전달되고, 기존 VM은 꺼 두었습니다1. 첫 ..

물리 호스트가 2대뿐인 홈랩에 Kubernetes 클러스터를 설계할 때 가장 먼저 부딪히는 문제는 마스터 노드를 몇 대 두고 어디에 놓느냐입니다. 저는 마스터 3대와 워커 4대로 클러스터를 만들고, API 주소를 처음부터 가상 IP로 정해 노드를 옮기거나 늘려도 주소가 바뀌지 않게 했습니다. 이 글에서는 마스터 수를 정한 기준, 두 호스트에 노드를 나눠 둔 방법, 노드 OS와 구성 요소를 고른 이유, 버전을 고르는 기준을 정리합니다. 홈랩 재구성 시리즈 2편이며, 이전 글은 홈랩 인프라 현황과 Kubernetes로 옮기는 이유입니다.2편을 마친 시점의 구성입니다. Kubernetes 노드 7대를 두 호스트에 나눠 만들었고, 서비스는 아직 VM에서 동작합니다1. 설계 조건 조건내용호스트ESXi 호스트 2대..

제 홈랩의 VM은 ESXi 호스트 2대에서 한때 약 68대까지 늘었고, 정리를 거쳐 지금은 24대입니다. 하이퍼바이저는 지원이 끝났고, 서비스 VM의 절반 이상이 지원이 종료된 OS를 썼으며, 실제로 쓰는 자원은 할당량의 4분의 1에도 못 미쳤습니다. 그래서 서비스 VM을 컨테이너로 바꿔 Kubernetes 클러스터로 옮기기로 했습니다. 이 글에서는 현재 인프라 상태와 문제점, Kubernetes를 고른 이유, 옮기기 전에 정리한 것과 이전 계획을 다룹니다. 홈랩 재구성 시리즈의 1편입니다.1편을 마친 시점의 구성입니다. 요청은 로드밸런서 VM을 거쳐 서비스마다 따로 있는 VM으로 갔고, 쓰지 않는 VM과 파일부터 정리했습니다1. 현재 홈랩 구성물리 서버는 ESXi 호스트 2대이고 vCenter 1대로 ..

EdgeRouter 4와 NETGEAR GS724Tv4를 새로 들여 홈 네트워크를 다시 구성했습니다. ER-4–스위치–메인 데스크톱 구간은 광케이블로 연결하고, 외부 서비스 구간과 내부 사용 구간을 나눴습니다.1. 구성도노트북 등 무선 기기는 빼고 패킷트레이서로 구성을 그렸습니다. 이전 버전과 비교해 ER-4 라우터와 NETGEAR 스위치가 추가되었습니다.홈 네트워크 V2 구성도 패킷트레이서에는 표현하지 못했지만, ER-4–GS724Tv4, GS724Tv4–메인 데스크톱 구간은 광케이블로 연결했습니다.2. 장비와 연결구간장비·구성라우터Ubiquiti EdgeRouter 4 (ER-4)스위치NETGEAR GS724Tv4ER-4 ↔ 스위치 ↔ 메인 PCSFP 모듈 + LC-LC 멀티모드 광케이블 사용한 SF..

학교 실습실 PC에 집에서 원격 데스크톱으로 접속하고 싶었지만, 학교 네트워크에서 쓰지 않는 포트를 막아 두어 포트포워딩이 불가능했습니다. 학교 PC가 집 공유기의 VPN에 접속하도록 하고, 집 공유기에서 포트포워딩해 원격 데스크톱 연결에 성공했습니다.1. 문제실습실에 공유기를 두고 포트포워딩을 해도 원격 데스크톱(RDP)이 되지 않았습니다. 학교처럼 관리되는 네트워크는 보안을 위해 사용하지 않는 포트를 막아 두기 때문에, 외부에서 안쪽으로 들어오는 연결이 차단됩니다.2. 아이디어밖에서 안으로 들어가는 연결이 막혀 있다면, 반대로 학교 PC가 먼저 집 공유기의 VPN에 접속하면 어떨까 생각했습니다. 학교 PC가 집 내부망의 일원이 되면 집에서 그 PC로 접근할 수 있습니다.3. 구성 순서집 공유기(ipT..