cola16k

사실 이 파이프라인을 세팅해 둔 지는 꽤 되었습니다. 그런데 왜 이제서야 블로그에 글을 남기느냐고요?

진정한 홈랩(Homelab) 인프라 관리자라면, 내가 만든 자동화 로직이 ‘실제로 리눅스 커널 버전이 올라가고, 원본 i915 소스가 업데이트되는 실전 상황’에서 완벽하게 작동하는지 두 눈으로 검증하기 전까지는 섣불리 성공을 외칠 수 없기 때문입니다. ㅎㅎ

그리고 마침내 최근, 이 파이프라인의 진가를 증명할 ‘진짜 위기이자 기회’가 찾아왔습니다.

아시다시피 openSUSE Tumbleweed는 커널 업데이트가 무섭게 빠른 롤링 릴리즈(Bleeding-edge) 배포판입니다. 지난 3월 4일, Tumbleweed 커널이 6.19.4로 훌쩍 넘어가면서 기존 드라이버 소스와 API 충돌이 발생했고, 제 OBS 빌드 모니터에 시뻘건 ‘Failed’가 떴습니다.

하지만 제가 직접 코드를 까보거나 수동으로 개입할 필요는 없었습니다. 바로 다음 날인 3월 5일, 개발자(strongtz)의 GitHub에 6.19.4 커널 대응 릴리즈가 올라왔죠.

그리고 자동화 된 제 파이프라인이 알아서 새 태그를 물고 와 재빌드를 돌려 ‘초록불(Success)’을 띄워놓은 것을 확인했거든요!

빌드 에러 발생부터 대응 소스 감지, 완벽한 RPM 패키징까지 제가 건드린 부분은 “0”이었습니다. 이 짜릿한 완전 자동화 파이프라인이 스스로 돌아가는 것을 두 눈으로 목격하고 나서야, 확신에 차서 이 구축기를 작성하게 되었습니다.

🚨 진짜 문제: “MicroOS는 DKMS를 모릅니다”

최근 클러스터에 Intel Core Ultra 5 235H (Arrow Lake) 기반의 미니 PC들을 도입하면서 가장 먼저 세팅한 핵심 기능은 단연 iGPU SR-IOV (단일 루트 I/O 가상화)였습니다.

보통은 이 드라이버를 외부 저장소에서 가져와 DKMS(Dynamic Kernel Module Support) 방식으로 설치합니다. 하지만 제가 운영하는 7개 노드 클러스터의 환경은 일반적인 OS가 아니라 openSUSE MicroOS였습니다.

불변(Immutable) OS인 MicroOS는 시스템 단에서 DKMS를 이용한 커널 모듈 동적 컴파일 자체가 불가능합니다. 즉, 애초에 기존 방식으로는 자동화가 원천적으로 차단된 상태였던 거죠.

물론 제 노드들의 베이스인 Slowroll 환경 자체는 업데이트가 충분히 느려서 드라이버 빌드가 터지는 일이 거의 없습니다. 빌드가 터지는 건 언제나 카나리아 역할을 하는 Tumbleweed 쪽이죠. 하지만 MicroOS의 특성상 DKMS를 쓸 수 없으니, “OS에 딱 맞는 바이너리 패키지”를 외부에서 만들어 공급해 주는 수밖에 없었습니다.

🛠️ 해결책: OBS(Open Build Service)를 이용한 나만의 KMP 레포지토리

이 구조적 한계를 돌파하기 위해, 오픈수세의 공식 빌드 시스템인 OBS(Open Build Service)를 활용해 나만의 전용 패키지 저장소를 만들었습니다.

단순히 소스를 다운받는 것을 넘어, 아예 운영체제에 딱 맞는 KMP (Kernel Module Package) 형태의 RPM으로 직접 빌드해서 배포하는 자동화 파이프라인(home:cola16/i915-sriov-kmp)을 구축한 것입니다.

파이프라인의 동작 원리

1. 소스 감시 (Watchdog): 제 LXC 컨테이너에 심어둔 스크립트가 주기적으로 원본 저장소의 새로운 릴리즈 Tag를 감시합니다.
2. 자동 트리거: 이번 3월 5일처럼 새 태그가 감지되면, 스크립트가 osc service remoterun 명령을 통해 OBS 서버에 빌드를 지시합니다.
3. 클린 빌드: 인터넷이 차단된 안전한 OBS 빌드 워커들이 .obscpio 소스를 풀고, Tumbleweed 및 Slowroll 커널 환경에 맞춰 RPM 패키지를 생성합니다.

🚀 레포 추가만 하면 끝: zypper install조차 필요 없는 하드웨어 자동 인식

파이프라인이 뒤에서 열심히 일해주니, 실제 노드에서 드라이버를 설치하고 업데이트하는 과정은 허무할 정도로 쉽습니다. 제 레포지토리를 추가하고 시스템 업데이트만 때려주면 끝납니다. 심지어 굳이 귀찮게 zypper install i915-sriov-kmp-default 같은 설치 명령어를 칠 필요조차 없습니다.

일반 openSUSE (Tumbleweed / Slowroll) 환경:

Bash

sudo zypper ar -f https://download.opensuse.org/repositories/home:/cola16/openSUSE_Slowroll/ cola16_obs_sriov
sudo zypper dup

MicroOS 환경:

Bash

sudo transactional-update dup

“아니, install 패키지 명시도 안 했는데 어떻게 드라이버가 깔리나요?” 이게 바로 오픈수세 KMP 패키징의 묘미입니다. 빌드된 KMP 패키지 내부에는 해당 드라이버가 지원하는 하드웨어 정보(modalias)가 포함되어 있습니다. 따라서 시스템에 Intel iGPU가 장착되어 i915가 필요한 환경이라면, 레포지토리만 추가해도 OS가 하드웨어를 감지하고 알아서 패키지를 당겨와 설치해 버립니다. 재부팅 한 번이면 새 커널에 딱 맞는 SR-IOV 드라이버가 깔끔하게 올라옵니다. ㅎㅎ

🛡️ 진정한 무기: ‘ksym’ 의존성을 이용한 커널 보호막

사실 이 파이프라인의 숨겨진 진가는 시스템의 절대적인 안정성 확보에 있습니다. 오픈수세의 KMP는 빌드될 때 커널 내부 함수들의 고유한 해시값인 Kernel Symbols (ksym)을 의존성으로 꽉 물고 있게 됩니다.

만약 제 Slowroll 노드들에 새로운 커널이 배포되었는데, 제 파이프라인이 아직 새 커널의 ksym을 지원하는 드라이버를 빌드해내지 못했다면 어떻게 될까요?

zypper (또는 transactional-update)는 업데이트를 시도하다가 “어? 새 커널을 깔면 지금 설치된 i915 드라이버랑 지문(ksym)이 안 맞네? 의존성이 깨지니까 커널 업데이트 중단할게!” 라며 알아서 방어막을 쳐버립니다.

즉, 드라이버가 완벽하게 준비되지 않으면 시스템 커널 자체가 업데이트되지 않는 ‘절대 자물쇠’가 채워진 것입니다.

맺음말

인프라의 규모가 커질수록 수동 관리는 재앙이 됩니다. 이번 OBS 기반의 KMP 자동 빌드 파이프라인 구축은 단순한 패키지 관리를 넘어, MicroOS의 한계를 극복하고 운영체제의 의존성 메커니즘을 역이용해 서비스의 가용성까지 지켜낸 뜻깊은 프로젝트였습니다.

특히 3월 4일의 Tumbleweed 6.19.4 커널 쇼크를 파이프라인이 혼자 힘으로 방어하고, 다음 날 새 소스를 물고 와서 스스로 복구해 내는 모습을 보며 “이 맛에 인프라 자동화하는구나” 싶었습니다.

혹시 MicroOS나 오픈수세 환경에서 Intel SR-IOV를 세팅하며 고통받고 계신 분들이 있다면, OBS를 적극 활용해 보시길 강력히 추천합니다!