초보자가 처음부터 작성하는 Guix 서비스 — Caddy 리버스 프록시 실습

본문

NixOS에서 Guix로 머신을 옮기고 있는 저자가 VPS 마이그레이션의 일환으로 Caddy 리버스 프록시용 커스텀 서비스를 처음부터 만들어가는 과정을 기록한 글입니다. Caddy는 Guix 공식 채널에 서비스가 없기 때문에 직접 정의해야 했고, '데몬 사용자 생성 → 설정 파일 배치 → Shepherd 데몬 등록'이라는 세 단계가 대부분의 홈서버 서비스와 공통 패턴이므로 첫 커스텀 서비스로 적합했다고 설명합니다.

서비스의 정의와 service-type

Guix 문서는 서비스를 '운영체제의 기능을 확장하는 것'으로 정의합니다. 백그라운드 데몬뿐 아니라 계정 생성이나 파일 복사 같은 일회성 작업, cron job 같은 반복 작업도 모두 서비스이며, 시스템을 선언적으로 구성하는 기본 단위입니다. 서비스는 service-type이라는 일종의 청사진(클래스와 인스턴스 관계에 비유됩니다)으로 정의되고, (service my-service-type my-service-value) 형태로 인스턴스화됩니다. <service-type> 레코드는 name과 extensions를 필수로 갖고, compose, extend, default-value, description 등을 선택 필드로 가집니다. 저자는 extensions를 빈 리스트로 둔 최소한의 caddy-service-type을 만들어 reconfigure에 성공하는 것으로 시작합니다.

extensions — 직관과 반대로 동작하는 확장

저자가 가장 혼란스러워한 지점은 extensions 필드의 방향입니다. 자기 서비스에 기능을 '추가'하는 것이 아니라, 대상 서비스(예: account-service-type)를 '수정해서' 자신을 위한 작업을 하도록 만드는 구조입니다. caddy-service-type이 account-service-type을 확장하면, 서비스가 활성화될 때 Guix가 caddy 사용자와 그룹을 생성합니다. 저자는 이를 제어 역전(Inversion of Control) 원리에 빗대어 설명하며, 모든 서비스가 서로를 확장하는 연쇄가 최종적으로 루트인 system-service-type에 수집된다고 정리합니다.

compose와 extend 필드

compose는 여러 서비스가 같은 서비스를 확장할 때 각각의 값을 어떻게 합칠지를 정의합니다. account-service-type은 concatenate를 사용해 모든 확장 값을 연결하고, 가상의 포트 관리 서비스처럼 상충하는 값이 올 수 있는 경우 우선순위 규칙을 넣을 수도 있습니다. extend는 compose로 합성된 확장 값이 서비스 자체의 값과 어떻게 결합할지를 정의하며, 계정 서비스는 append를 사용해 확장으로 받은 계정과 자체 값을 모두 생성합니다.

실습: 사용자 생성과 G-expression

실제로는 <user-account>와 <user-group> 레코드로 caddy 시스템 계정을 정의하고, service-extension에 (const %caddy-accounts)를 넘겨 reconfigure 후 id caddy로 확인합니다. 설정 파일 배치에는 임의 코드를 활성화 시점에 실행하는 activation-service-type을 사용하는데, 이때 넘기는 값이 G-expression(gexp)입니다. #~ 매크로로 감싼 코드는 호스트 환경이 아니라 Guix 데몬의 빌드 '컨테이너' 환경에서 나중에 평가되며, #$로 값을 언갭싱하고 with-imported-modules로 빌드 측 모듈을 가져옵니다. 저자는 문서만으로는 부족한 부분을 gnu/services.scm, shadow.scm 등 소스 코드의 파일:라인을 직접 참조해가며 배우는 방식을 권합니다.

Lobsters 반응

• @aloys — 저자 본인이 직접 등장해 'Guix를 막 시작한 입장이라 제안이나 지적을 환영하며, Guix 여정을 시작하는 분들께 도움이 되길 바란다'고 댓글을 남겼습니다.

원문: Lobsters / 번역·요약: Trawling