nixos-is-making-me-less-afraid.jpg
얼마 전에 재미있는 일이 생겼다. FreshRSS에 대해 읽었는데, 괜찮아 보여서 서버에 설치하고 사용하기 시작했다. 1년 전이었다면 이런 일은 일어나지 않았겠지만, 그렇다고 해도 1년 전에는 NixOS 서버가 없었다.
지난 몇 년 동안 내 RSS 피드는 오직 휴대폰 로컬에만 존재해 왔다. 여기에는 나중에 컴퓨터에서 떨어져 있을 때 시간을 들여 읽을 수 있다는 좋은 아이디어가 있었지만, 실제로 구현하기는 어려웠다. 첫째로, 많은 것을 더 큰 화면으로 읽는 것이 더 쉽다. 하지만 또한 100개의 피드에 걸친 수천 개의 기사의 읽음/안 읽음 상태를 관리하는 휴대폰 앱을 신뢰하는 것은 불안정했다. 특히 다른 휴대폰으로 바꿀 때 모든 피드를 옮길 수는 있었지만, 읽음/안 읽음 상태는 그 과정에서 손실되었다. 내가 정말 원했던 것은 서버 측(server-side) 피드 애그리게이터였다. 이것은 서버에서 실행되며 RSS 피드를 관리하고, 사용자는 웹 인터페이스나 클라이언트 애플리케이션을 통해 해당 RSS 피드를 읽을 수 있는 소프트웨어다. 오랫동안 원했지만, 배포를 유지 관리해야 할 또 하나의 사이드 프로젝트가 될 것이기 때문에 시도해 본 적이 없었다.
하지만 이제 NixOS 경험 덕분에 작동하는 FreshRSS 설정(백업 포함)을 추가하는 것은 9줄의 Nix 코드3와 nginx 리버스 프록시 설정을 위한 12줄 정도만 필요했다. 특정 location 블록에서 proxy_pass를 해야 했기 때문에 쿠키 경로 재작성(rewriting cookie paths)이 필요해서 조금 복잡해졌다. 하지만 그것은 나만의 문제이지, NixOS의 문제가 아니다. 그 설치는 지난 몇 달 동안 손쉽게 작동했다. 만약 서버가 고장나거나 할 경우, 정확히 같은 구성을 가진 새 서버를 아마 15분 정도 안에 띄울 수 있다. 이런 것이 가능하다면, 새로운 소프트웨어를 시도하지 않을 이유가 문자 그대로 없다.
이것을 NixOS 외부에서 FreshRSS를 설치하는 방식과 비교해 보라. 그러면 우리는
- 아카이브를 다운로드하여 적절한 위치에 압축 해제하고;
- 지침에 따라 권한을 구성하며;
- 서버에 nginx와 php-fpm을 필요한 추가 종속성(dependencies)과 함께 설치하고;
- php-fpm 풀(pools)을 구성하고 nginx가 요청을 php-fpm으로 전달하도록 설정하며;
- Let’s Encrypt 인증서를 설정하고;
- 백업을 설정하는 것입니다.
그리고
- 만약 무언가 고장 나거나 나중에 새 서버 또는 업그레이드된 서버에 FreshRSS를 다시 설치해야 할 때, 위 모든 과정을 어떻게 해야 하는지 기억할 수 있기를 바랍니다.
물론, FreshRSS 프로젝트에서는 이 과정을 조금 단축시켜 줄 컨테이너 이미지(container image)를 제공합니다. 이 이미지는 Apache와 mod_php를 설정하고 올바르게 구성하는 역할을 한다고 합니다. 그러면 우리는 백업을 구성하고, 컨테이너를 실행하는 systemd 서비스를 만들고, 그리고 그 앞에 nginx를 TLS 터미네이팅 리버스 프록시(reverse proxy)로 관리하기만 하면 됩니다. 왜냐하면 이 컨테이너 이미지는 합리적으로 TLS 지원이 되어 있지 않기 때문입니다. 이것 역시 기억해야 할 것들이 많으며, 우리가 다운로드한 정확한 컨테이너 이미지 이름을 기록하지 않는 한, 6개월 후에 다시 설치할 때 같은 것이 작동한다는 보장도 없습니다. 소스(source)로부터 컨테이너 이미지를 빌드하는 것은 도움이 되지 않습니다. 왜냐하면 동일한 Dockerfile로 만든 두 개의 빌드는 시간 간격에 따라 상당히 다른 컨테이너 이미지를 초래할 수 있기 때문입니다.
이전에 제가 사이드 프로젝트를 유지 관리하는 것을 얼마나 싫어하는지 말씀드렸습니다. 여기에는 제 자신의 코드뿐만 아니라 다른 사람이 개발한 셀프 호스팅 서비스도 포함됩니다. 저는 가끔 몇 분 정도의 유지 관리는 괜찮지만, 무언가를 업그레이드하기 위해 몇 시간 동안 중단 없는 작업을 계획하거나, 긴급 유지 보수에 어떤 시간이라도 쓰는 것은 컴퓨터로 작업하고 싶은 욕구를 정말 죽입니다.
제 성향이라면 설정 관리(configuration management), 컨테이너 오케스트레이션(container orchestration) 중 하나 또는 둘 다에 깊이 빠져있을 거라고 생각할 겁니다. 하지만 그렇지 않습니다. CFEngine, Ansible, podman, k3s를 가지고 진지하게 시도해봤지만, 어느 것 하나 (a) 신중하게 기록하는 것보다, 그리고 때로는 (b) 그 신중한 메모들을 일련의 ssh 명령을 수행하는 셸 스크립트로 변환하는 것보다 제 설치/설정/배포 경험을 눈에 띄게 개선해주지 못했습니다. 네, 이것은 본질적으로 Ansible을 재창조하는 것이지만 – 더 취약하지는 않습니다. 다음에 누군가 pip를 옆에서 흘깃 볼 때 깨지는 일은 없을 겁니다. 셸 스크립트의 단점은 종종 시간이 지나면서 무효화되거나 다른 환경에서 사용될 때 유효하지 않은 가정에 의존하게 된다는 것입니다. NixOS 설정은 저 자신에게 주는 신중한 지침서와 매우 흡사하지만, 실행 가능하고 매번 동일한 결과를 만들어낸다는 점이 다릅니다.
