소개

i3wm을 선택한 이유 i3 윈도우 매니저(i3wm)는 효율성과 생산성에 초점을 맞춘 타일링 윈도우 매니저다. 2009년 독일의 개발자 Michael Stapelberg가 기존 wmii 윈도우 매니저의 한계를 보완하기 위해 개발했으며, 이름은 “improved tiling wm"에서 따왔다. C 언어로 작성된 i3는 약 10,000줄 규모의 비교적 작은 코드베이스로 이루어져 있으며, 마우스보다 키보드 중심의 워크플로우를 선호하는 개발자, 시스템 관리자, 파워 유저 사이에서 널리 쓰인다. Arch Linux, Gentoo, NixOS 사용자층에서도 자주 언급되는 편이다. i3는 전통적인 X Window System(X11) 환경에서 동작하며 디스플레이 매니저와 독립적으로 실행되기 때문에 LightDM, GDM, SDDM 같은 로그인 매니저와 함께 사용할 수 있다. 최근에는 Wayland를 지원하는 호환 구현인 Sway(i3-compatible Wayland compositor)도 널리 쓰이며, i3의 설정과 키 바인딩을 상당 부분 그대로 활용할 수 있다. i3는 “do one thing and do it well"이라는 Unix 철학에 가깝게 불필요한 시각 효과를 줄이고 화면 공간을 작업 콘텐츠에 집중하도록 설계되었다. 여기에 다중 모니터 지원, 효율적인 창 관리, 텍스트 기반 설정 파일을 통한 사용자 정의 기능을 제공한다. ...

메모리가 모자라면 리눅스는 잘 안 쓰는 페이지를 스왑으로 내보낸다. 문제는 그 스왑이 보통 디스크라는 점이다. 디스크 스왑이 활발해지는 순간 시스템은 눈에 띄게 버벅인다. zram은 이 스왑을 디스크가 아니라 압축된 RAM에 둔다. 페이지를 디스크에 쓰는 대신 RAM 안에서 압축해 보관한다. 거래는 단순하다. CPU를 조금 더 써서 압축·해제하는 대가로 디스크 I/O를 RAM 접근으로 바꾼다. 텍스트성 데이터는 보통 2:1~4:1로 압축되므로, 스왑으로 나간 만큼의 물리 RAM을 절반 이하로 되돌려 받는 효과가 있다. 현재 스왑 확인 zram이 무엇을 대체하는지 보려면 현재 스왑이 어디에 있는지부터 확인한다. ...

ARP는 응답을 받은 호스트가 그 응답이 진짜인지 확인하지 못한다. “게이트웨이 192.168.1.1의 MAC은 무엇인가?“라고 브로드캐스트로 물으면 누가 대답하든 그 값을 그대로 캐시에 적는다. 인증도 무결성 검사도 없다. 묻지 않았는데 날아온 응답(Gratuitous ARP)도 받아 기존 캐시를 덮어쓴다. 공격자는 이 틈에 거짓 응답을 넣는다. 피해자에게는 “게이트웨이 MAC은 내 것"이라고, 게이트웨이에게는 “피해자 MAC은 내 것"이라고 동시에 속이면 둘 사이의 모든 트래픽이 공격자를 경유한다. 전형적인 중간자(MITM) 공격이며, 아래에서 격리된 환경에 재현한다. 교육 목적 / 윤리적 사용 ...

개요 이전 글에서는 Helm 차트 기반 프로젝트 템플릿과 ArgoCD ApplicationSet을 활용해 내부 개발자 플랫폼(IDP) 구조를 정리했다. 이번 글에서는 홈랩 쿠버네티스 클러스터를 모니터링하기 위해 Prometheus와 Grafana로 메트릭을 수집하고 시각화하는 방법, Loki로 로그를 중앙에서 수집하고 분석하는 방법을 정리한다. 모니터링의 필요성 홈랩 쿠버네티스 클러스터를 운영하다 보면 주기적으로 확인해야 할 정보가 많다. 노드와 파드의 상태, CPU와 메모리 같은 리소스 사용량, 애플리케이션의 정상 작동 여부, 문제 발생 시 원인 파악을 위한 로그 데이터가 대표적이다. 이런 정보를 시각적으로 모니터링하기 위해 다음과 같은 도구들을 사용한다. ...

개요 이전 글에서는 IDP의 기반이 되는 Harbor 컨테이너 레지스트리, Argo Events, Argo Workflows를 설치했다. 이번 글에서는 이 구성 요소들을 ArgoCD와 통합하고 Helm 차트 기반의 프로젝트 템플릿을 설계하여 YAML 파일 하나로 프로젝트를 배포할 수 있는 내부 개발 플랫폼(Internal Developer Platform, IDP) 구조를 정리한다. 내부 개발 플랫폼이란 내부 개발 플랫폼(IDP)이란? 내부 개발 플랫폼(Internal Developer Platform)은 개발자가 인프라와 배포 파이프라인을 직접 구성하지 않고도 애플리케이션을 배포하고 운영할 수 있도록 추상화된 셀프서비스 인터페이스를 제공하는 시스템이다. 플랫폼 엔지니어링의 핵심 결과물로, 개발자 경험을 향상시키고 표준화된 배포 프로세스를 통해 운영 부담을 줄이는 것을 목표로 한다. ...

개요 이전 글에서는 HashiCorp Vault를 설치하여 안전한 시크릿 관리 시스템을 구축했다. 이번 글에서는 내부 개발 플랫폼(IDP)을 만들기 전에 먼저 필요한 기반 구성 요소로 Harbor 컨테이너 레지스트리, Argo Events, Argo Workflows를 설치하고 기본 구성을 정리한다. IDP 기반 구성 요소 내가 구상한 IDP에서는 먼저 다음과 같은 기반 구성 요소가 필요했다: 컨테이너 레지스트리: 빌드된 컨테이너 이미지를 저장하고 배포하는 중앙 저장소로, Docker Hub와 같은 퍼블릭 레지스트리에 의존하지 않고 자체적으로 이미지를 관리할 수 있게 한다. 이벤트 처리 시스템: Git 저장소의 코드 변경, 웹훅 수신 등 다양한 이벤트를 감지하고 이에 반응하여 후속 작업을 트리거하는 역할을 담당한다. 워크플로우 엔진: 코드 빌드, 테스트 실행, 컨테이너 이미지 생성 등 실제 CI/CD 작업을 정의하고 실행하는 엔진이다. GitOps 배포 시스템: Git 저장소에 정의된 원하는 상태를 클러스터에 자동으로 동기화하는 시스템으로, 이전 시리즈에서 설치한 ArgoCD가 이 역할을 담당한다. 이번 글에서는 컨테이너 레지스트리, 이벤트 처리 시스템, 워크플로우 엔진을 각각 Harbor, Argo Events, Argo Workflows로 구성한다. 다음 글에서는 이 기반 위에 ArgoCD와 템플릿 구조를 더해 실제 IDP 형태로 정리한다. ...

개요 이전 글에서는 DDNS와 포트포워딩을 구성하여 홈랩 쿠버네티스 클러스터의 서비스를 외부 인터넷에서 접근할 수 있도록 했다. 이번 글에서는 쿠버네티스 클러스터에서 비밀번호, API 키, 인증서 같은 민감한 정보를 안전하게 관리하기 위해 HashiCorp Vault를 설치하고 구성하는 방법을 알아본다. 기본 쿠버네티스 시크릿의 한계 GitOps 방식으로 홈랩 환경을 구성하면서 시크릿 관리가 가장 큰 난제였으며, 기본 쿠버네티스 Secret을 사용해보니 여러 가지 한계점이 명확하게 드러났다. 첫째, GitOps와의 통합 문제가 있다. Git 저장소에 시크릿을 그대로 저장할 수 없고, base64로 인코딩해도 단순한 디코딩으로 원본 값을 복원할 수 있어 보안에 취약하다. Sealed Secrets나 SOPS 같은 도구도 검토했으나, 단순 암호화를 넘어선 종합적인 시크릿 관리 솔루션이 필요했다. ...

개요 이전 글에서는 Traefik 인그레스 컨트롤러를 설치하고 내부와 외부 서비스를 분리하여 관리 인터페이스에 안전하게 접근할 수 있도록 구성했다. 이번 글에서는 홈랩 쿠버네티스 클러스터의 서비스를 외부 인터넷에서 접근할 수 있도록 DDNS와 포트포워딩을 구성하는 방법을 알아본다. 네트워크 아키텍처 요약 먼저 이전 글에서 구성한 네트워크 아키텍처를 간략히 요약한다: 내부용 로드밸런서(192.168.0.200): ArgoCD, Longhorn, Traefik 대시보드 같은 관리 인터페이스만 노출하며 내부 네트워크에서만 접근 가능하다. 외부용 로드밸런서(192.168.0.201): 블로그, 개인 프로젝트 등 공개 서비스만 노출하며 라우터 포트포워딩을 통해 외부 인터넷에서 접근 가능하다. ...

개요 이전 글에서는 Longhorn 분산 스토리지 시스템을 설치하여 파드가 재시작되거나 다른 노드로 이동해도 데이터가 유지되는 영구 스토리지 환경을 구축했다. 이번 글에서는 홈랩 쿠버네티스 클러스터에 Traefik 인그레스 컨트롤러를 설치하고, 내부 네트워크에서 관리 인터페이스에 안전하게 접근할 수 있도록 구성하는 방법을 알아본다. 인그레스 컨트롤러 선택 홈랩 환경에서 쿠버네티스 서비스를 외부에 노출하는 방법은 여러 가지가 있다: NodePort: 각 노드의 특정 포트(30000-32767 범위)를 통해 서비스에 접근하는 방식으로 설정이 간단하지만 포트 번호를 기억해야 하는 불편함이 있고, 표준 HTTP/HTTPS 포트를 사용할 수 없다. ...

개요 이전 글에서는 ArgoCD를 설치해 GitOps 환경을 구축했다. 이번 글에서는 홈랩 쿠버네티스 클러스터에 Longhorn 분산 스토리지를 설치하고 구성한 과정을 정리한다. 영구 스토리지가 필요한 이유와 여러 스토리지 솔루션을 검토하며 얻은 판단 기준도 함께 공유한다. 홈랩 환경의 스토리지 고민 홈랩 쿠버네티스를 구축하면서 가장 크게 고민한 부분 중 하나는 스토리지였다. 데이터베이스, 모니터링 도구, 백업 시스템처럼 실제로 운영할 만한 애플리케이션 대부분은 파드가 재시작되거나 다른 노드로 이동해도 데이터가 유지되는 영구 스토리지를 필요로 한다. ...