블로그를 Ubuntu 16.04에서 10년 동안 운영하다가 FreeBSD로 마이그레이션함

(crocidb.com)

1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개

Ubuntu 16.04 LTS 기반 DigitalOcean VPS는 지원 종료와 보안 부담이 있었지만, 종료 시점까지 1491일 업타임을 유지함
새 서버는 독일 Hetzner VPS와 FreeBSD 14.3으로 옮겼고, 기존 월 $13 서버보다 강한 사양을 월 6유로 미만에 사용함
Jails와 Bastille로 사이트별 격리 환경을 만들고, Caddy Jail이 SSL과 리버스 프록시를 맡아 각 nginx Jail로 전달함
부하 테스트에서 새 FreeBSD 서버는 10,000 동시 연결을 위해 kern.ipc.somaxconn을 조정한 뒤 요청 처리량이 3~11배 높게 나옴
전환에는 네트워킹과 FreeBSD 설정 학습이 필요했지만, 중앙화된 설정과 문서 품질 덕분에 예상보다 구성하기 쉬웠음

마이그레이션 배경

기존 블로그는 DigitalOcean VPS에서 10년 넘게 운영됐고, 뉴욕 데이터센터의 Ubuntu 16.04 LTS를 사용했음
- Ubuntu 16.04 LTS는 최소 5년 전부터 지원이 끝난 상태였고, apt 패키지 저장소 업데이트를 받을 수 없었음
- 오래된 시스템은 보안상 불리하며, 과거 별도 WordPress 블로그가 오래된 VPS에서 카지노·도박 링크 삽입 공격을 겪은 적이 있음
기존 서버는 블로그 외에도 몇 개의 사이트를 함께 제공했지만 대부분 정적 사이트였음
- 가장 인기 있는 블로그도 보통 월 몇천 페이지뷰 수준이었고, Hacker News에서 몇몇 글이 바이럴된 경우를 제외하면 트래픽은 많지 않았음
- 서버는 nginx/1.10.3로 정적 파일을 제공했고, 사이트별 설정은 /etc/nginx/sites-available에 있었음
- 블로그는 Hugo로 생성됐고, 기존 배포 절차는 로컬 작성 → 저장소 커밋·푸시 → 서버 SSH 접속 → 저장소 pull → hugo 실행이었음
기존 VPS는 초기에 테스트와 프로그래밍 용도로도 쓰여 오래된 소프트웨어가 많이 남아 있었음
- 그래도 정상적으로 동작했고, 종료 시점의 업타임은 1491일로 약 4년 동안 재부팅 없이 운영됨
새 서버는 독일의 Hetzner VPS로 옮겼고, 기존보다 사양이 높으면서 월 비용은 절반 이하였음
- 기존 DigitalOcean 서버는 RAM 2GB, vCPU 1개, 디스크 50GB, 월 트래픽 2TB, 월 $13였음
- Hetzner의 가장 저렴한 서버도 기존보다 메모리와 CPU가 두 배였고, 저장공간은 약간 적지만 트래픽은 10배였음
- 최종 선택한 Hetzner 구성은 월 6유로 미만의 더 강한 사양이었음

FreeBSD를 선택한 이유

FreeBSD는 새로운 시스템을 실제 운영 환경에서 시험해보고 싶어 선택됨
- 통합 설계, 안정성, 보안, Jails가 장점으로 꼽힘
Jails는 FreeBSD에 25년 넘게 포함된 가상화·컨테이너화 기능임
- 호스트 시스템에 접근하지 못하는 “미니 시스템”을 샌드박스처럼 실행할 수 있음
- Docker 같은 컨테이너 솔루션은 프로그램 패키징에 더 적합하고 일시적·불변적인 성격을 갖는 반면, Jails는 같은 커널을 공유하는 서브시스템이나 미니 VM에 가깝게 다뤄짐
ZFS도 서버용 파일시스템으로 매력적인 선택지였음
- 데이터 무결성과 스냅샷 기능이 있고, Linux 쪽의 Btrfs와 유사한 면이 있음
- ZFS는 Btrfs보다 훨씬 성숙한 것으로 평가됐고, 자주 스냅샷을 남기면 VPS 제공자의 유료 스냅샷·백업 시스템에 덜 의존할 수 있음
목표 구조는 사이트마다 하나의 Jail을 두고, 각 Jail 안에 필요한 빌드 도구와 nginx를 넣는 방식이었음
- 메인 웹 서버용 Jail은 외부와 연결되는 리버스 프록시를 맡음
- 특정 Jail이 침해되면 해당 Jail을 삭제하고 새로 만들 수 있는 구조를 의도함

FreeBSD 설치와 Bastille 도입

Hetzner의 VM 생성 화면에는 기본 OS 이미지가 제한적이어서 BSD가 바로 보이지 않았음
- FreeBSD 공식 YouTube 채널의 Hetzner 설치 영상을 참고함
- Hetzner는 FreeBSD ISO 이미지를 제공하지만, VM 생성 후 콘솔의 ISO Images 탭에서 마운트해야 했음
- 설치에는 FreeBSD 14.3 ISO가 사용됐고, 공식 영상의 설치 흐름을 따라 시스템을 구성함
Bastille은 Jails 관리를 쉽게 하기 위해 선택됨
- 수동 Jail 생성에 필요한 여러 단계를 bastille 명령으로 처리할 수 있음
- 예시 명령은 bastille list, bastille create, bastille console임
- 설치와 활성화는 Bastille 시작 문서 기준으로 진행됨

pkg install bastille
sysrc bastille_enable="YES"

네트워크와 리버스 프록시 구조

전체 스택은 Caddy Jail 하나가 모든 도메인과 SSL 인증서를 처리하고, 사이트별 Jail로 트래픽을 리버스 프록시하는 구조임
- 각 사이트 Jail은 사이트를 빌드하고 제공하는 데 필요한 도구만 포함함
- 같은 네트워크 안의 여러 가상 머신과 비슷한 구조로 볼 수 있음
내부 가상 네트워크 인터페이스는 bastille0로 만들었음

sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"

루프백 인터페이스를 복제해 bastille0라는 이름을 붙이고 10.0.0.1/24 네트워크를 할당함
Jail들은 이 네트워크 인터페이스에서 동작함
외부 HTTP·HTTPS 요청은 PF(Packet Filter) 규칙으로 Caddy Jail에 전달됨
- /etc/pf.conf에는 외부 인터페이스 vtnet0, 내부 인터페이스 bastille0, tailscale1이 설정됐음
- 80, 443 포트 트래픽은 Caddy 서버가 될 10.0.0.5로 리다이렉트됨

ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state

PF와 게이트웨이는 다음 명령으로 활성화됨

sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Caddy와 사이트별 Jail 구성

기존 서버는 nginx를 오래 사용했지만, 새 구성에서는 SSL 인증서 관리를 자동화하기 위해 Caddy를 선택함
- 기존 nginx 환경에서는 certbot으로 인증서를 주기적으로 갱신해야 했고, 갱신을 놓친 일이 여러 번 있었음
Caddy Jail을 만들기 전에 FreeBSD 릴리스를 Bastille에 부트스트랩함

bastille bootstrap 14.3-RELEASE

Caddy Jail은 10.0.0.5 IP로 생성됨

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

Jail 이름은 caddy, 릴리스는 14.3-RELEASE, 인터페이스는 bastille0임
bastille list로 실행 상태를 확인하고, bastille console caddy로 Jail 내부 셸에 들어갈 수 있음
Caddy 설치와 서비스 활성화는 Jail 내부에서 진행됨

pkg install caddy
sysrc caddy_enable="YES"
service caddy start

Caddy 설정 파일은 Jail 내부의 /usr/local/etc/caddy/Caddyfile에 있음
- 호스트에서 설정 파일을 관리하려면 호스트 디렉터리를 Jail 안으로 마운트할 수 있음
- 예시에서는 nullfs와 읽기 전용 ro 옵션으로 Caddy가 설정을 변경하지 못하게 마운트함

bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

사이트와 블로그 배포

첫 번째 배포 대상은 es.cro.to였고, 사이트 저장소는 GitHub 저장소로 관리됨
- 호스트의 /usr/local/www/escroto에 저장소를 두고, 사이트 Jail에는 해당 디렉터리를 읽기 전용으로 마운트함
- 모든 사이트는 호스트의 /usr/local/www 아래에 두는 방식으로 정리됨
escroto Jail은 nginx Bastille 템플릿으로 만들었음

bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx

IP는 10.0.0.11로 지정됨
nginx 기본 페이지는 FreeBSD 관례대로 /usr/local/www/nginx에서 제공됨
호스트의 사이트 디렉터리는 Jail에 읽기 전용으로 마운트됨

bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0

저장소의 .git 디렉터리가 웹으로 제공되지 않도록 배포 스크립트를 사용함

rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git

새 버전 배포는 호스트에서 저장소를 갱신한 뒤 Jail 안의 배포 스크립트를 실행하는 방식임

cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh

Caddy 설정은 cro.to를 es.cro.to로 영구 리다이렉트하고, es.cro.to를 10.0.0.11로 프록시함

cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}

블로그는 Hugo를 사용하며 GitHub 저장소로 관리됨
- 저장소는 호스트의 /usr/local/www/blog에 클론됨
- blog Jail은 escroto와 비슷하게 생성됐고, IP는 10.0.0.12로 지정됨

bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0

Hugo는 blog Jail 안에 설치됨

bastille pkg blog update
bastille pkg blog install gohugo

블로그 배포 스크립트는 nginx 웹 루트를 비우고 Hugo 출력물을 /usr/local/www/nginx에 생성함

rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx

DNS를 옮기기 전에는 기존 도메인 대신 crocidb.cro.to를 새 블로그 서버에 연결해 테스트함

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

벤치마크와 부하 테스트

DNS 레코드를 바꾸기 전에 기존 서버 crocidb.com과 새 서버 crocidb.cro.to의 부하 처리 능력을 비교함
- 블로그 방문자는 주로 북미, 그다음 유럽과 남미에서 오기 때문에 새 독일 서버의 지연시간이 일부 사용자에게 약간 길어질 수 있음
- 핵심 관심사는 정적 사이트 제공 속도와 큰 부하를 견디는 능력이었음
GTMetrix, Pingdom, WebPageTest 같은 무료 온라인 도구도 사용했지만, 두 서버의 차이는 대부분 지연시간 정도였음
HTTP 부하 벤치마크 도구로 wrk와 hey를 사용함
- 두 도구는 대량의 동시 요청을 생성하고 요청 지연시간, 오류 응답, 초당 전송량 등을 수집함
같은 Hetzner의 다른 VPS에서 wrk를 실행했을 때 새 서버가 크게 앞섰음

wrk -t4 -c100 -d30s --latency https://crocidb.com/

옵션은 4스레드, 100개 동시 연결, 30초 실행이었음
기존 서버는 평균 지연시간 89.63ms, 초당 요청 833.41, 전송량 8.29MB/s였음
새 서버는 평균 지연시간 6.75ms, 초당 요청 12260.10, 전송량 130.80MB/s였음
테스트 머신이 새 서버와 같은 데이터센터에 있어 공정한 비교는 아니었음
Proton VPN을 이용해 여러 지역에서 wrk를 돌리는 방식도 시도했지만 결과는 기대보다 낮았음
- 기존 서버 평균은 초당 약 300 요청, 새 서버 평균은 초당 약 800 요청으로 기록됨
- 최종적으로 일반 사용자용 VPN 대신 여러 지역의 실제 VPS를 만드는 방식으로 바뀜

Vultr VPS 기반 지역별 테스트

서버가 올라간 DigitalOcean·Hetzner와 다른 인프라를 쓰기 위해 Vultr가 선택됨
- 지역은 수동 작업 부담 때문에 London, São Paulo, Silicon Valley, Tokyo 네 곳으로 제한됨
- 각 지역에 가장 저렴한 Fedora VM을 만들고 테스트를 실행함
최종 테스트 도구는 hey가 더 적합하다고 판단됨

./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log

설정은 총 1,000,000 요청, 동시 요청 10,000, 타임아웃 10초, 총 실행 시간 5분, HTTP/2 사용이었음
현실적인 블로그 트래픽보다 훨씬 큰 부하였음
첫 실행에서 새 FreeBSD 서버는 10,000개 동시 연결을 감당하지 못해 초반에 실패함
- netstat -Lan으로 소켓 큐 크기를 확인하자 모두 128로 나타남
- 기본값 kern.ipc.somaxconn이 128이어서 다음처럼 늘림

sysctl kern.ipc.somaxconn=16384

São Paulo 테스트에서 두 서버 모두 상당한 오류를 반환했지만, FreeBSD 서버는 기대한 1,000,000 요청에 대응했고 Ubuntu 서버는 20,000 요청도 반환하지 못했음
- 기존 Ubuntu 서버는 전체 요청의 약 7%만 완료함
- 새 FreeBSD 서버는 약 94%를 완료함
- Tokyo에서는 새 서버의 성공률이 약간 낮았지만, 크게 우려할 수준은 아니라고 판단됨
초당 요청 수 기준으로 새 서버는 기존 서버보다 최소 3배, 최대 11배 나았음
- 지연시간 백분위에서는 새 서버가 약 90% 지점까지 더 선형적으로 증가해 예측 가능성이 더 높았음
- 높은 부하에서도 전 세계 대부분 지역에서 블로그 메인 페이지 콘텐츠를 3.5초 미만에 받을 수 있는 결과였음
Tokyo 결과는 깊게 분석하지 않았음
- hey의 요청 단계별 분석에서는 일본으로 향하는 트래픽이 더 느릴 가능성이 나타남
- 두 번째 도메인의 DNS dial-up·lookup 값이 비정상적으로 낮아 보였고, CNAME 레코드 영향 가능성이 있었음
- resp wait와 resp read 값도 이상하게 높았는데, 성공한 요청만 집계했기 때문에 기존 서버가 초기에 빠르게 응답하다가 이후 새 요청을 사실상 막았을 가능성이 있었음

최종 전환과 핵심 교훈

벤치마크는 답하지 못한 부분이 많았지만, 결과에 만족해 DNS 레코드를 새 서버로 전환함
- 이 블로그는 이후 FreeBSD 기반 Hetzner 서버에서 공식적으로 운영됨
FreeBSD로 사이트 호스팅 머신을 구성하는 일은 여러 시간의 실험, 수정, 빌드, 실패를 거쳤지만 예상보다 복잡하지 않았음
- 요구 조건을 만족하는 웹 호스팅 서비스를 사용할 수도 있었고, 예시로 OpenBSD Amsterdam이 나옴
- Proxmox로 컨테이너와 관리 대시보드를 사용할 수도 있었음
- FreeBSD 쪽 대안으로 Sylve도 거론됨
- 직접 구성한 경로는 많은 학습을 제공했기 때문에 만족스러운 선택이었음
기존 Ubuntu 서버도 매우 견고했음
- 10년 동안 사이트 부하를 잘 처리했고, 마지막 4년은 재부팅 없이 운영됨
- 설정에 큰 노력을 들이지 않고도 안정적으로 동작함
FreeBSD 설정은 예상보다 쉬웠고, 시스템 설정을 한곳에 중앙화하는 방식과 온라인 문서 품질이 좋았음
직접 블로그 호스팅 머신을 구성하려면 게임 개발자가 아는 범위를 넘어서는 네트워킹 지식이 필요했음
- 다른 시스템을 배우는 과정이 즐거웠고, 다음에는 OpenBSD나 NetBSD를 시도할 수도 있음
- 블로그 트래픽 대부분이 AI 시스템의 크롤링에서 온다는 점에서, 이 모든 작업의 실용성은 제한적이라고 마무리됨

▲

GN⁺ 4시간전 [-]

Hacker News 의견들

내가 한 가장 큰 실수는 높은 가동 시간이었음
arjie.com이 Hetzner VPS에서 10년 넘게 떠 있다 보니, Hetzner가 그 기반 머신을 종료하려 할 때 10대 시절의 내가 뭘 설정해뒀는지 전혀 알 수 없었음
백업은 있지만 사이트는 10년째 내려가 있음
요즘은 옮겨 다닐 수 있게 만들고, 실제로 몇 번 옮겨 봐서 동작하는지 확인함
- “가장 큰 실수는 높은 가동 시간”이라는 말이 맞음
  예전에는 머신 가동 시간이 명예 훈장처럼 여겨지던 시절도 기억함
  나이만 들고 딱히 더 현명해지진 않았지만, 요즘은 서비스 가동 시간을 봄
  예전에도 MX 같은 DNS 레코드가 그런 목적에 가까웠고, 오래된 클러스터는 꽤 난해했지만 split brain 같은 교훈이 남아 지금도 Proxmox 2노드 클러스터가 왜 망가지는지, 왜 추가 witness를 권하는지 계속 설명하게 됨
  VMware가 예전에 2노드 HA 클러스터 문제를 큰 임시방편으로 덮은 것도 틀렸고, 그 방식이 아직 남아 있다면 여전히 틀렸을 가능성이 큼
  높은 가동 시간은 패치를 안 했다는 뜻이고, 패치는 다들 좋아하는 일임
- 일본의 이세 신궁이 떠오름
  20년마다 완전히 해체했다가 다시 짓는데, 최근 읽은 Dan Wang의 Breakneck에서 이런 재건 관행이 시간이 지나면 사라질 지식을 보존한다고 설명함
  Wang은 이세 신궁과 Notre Dame을 대비시키는데, Notre Dame 지붕 재건이 꽤 어려운 이유 중 하나가 지식 손실일 수 있다고 봄
  두 건축물에 충분히 익숙하지 않아 공정한 비교인지는 모르겠지만, 원칙 자체는 마음에 듦
  책에서는 작은 비유일 뿐이고, 전체적으로는 강력 추천함
- VM에서 높은 가동 시간은 별 의미가 적음
  재부팅은 몇 초면 끝나고, 업그레이드는 새 인스턴스로 DNS만 바꾸면 무중단으로 가능함
  쉽게 복제할 수 없는 물리 머신은 이야기가 다름
- 큰 Ansible 플레이북 저장소에 설정을 넣기 시작했음
  전부 Ansible로 완전 관리할 필요는 없고, 주로 초기 설정만 거기에 두며 아직도 손으로 관리하는 일이 많음
- 개인 프로젝트에도 가끔 Architectural Decision Records를 남김
  좀 우스꽝스럽게 느껴지지만, 예상보다 자주 도움이 됨
개인/취미 용도는 대체로 Caddy 앞단 + Docker Compose 조합으로 운영함
단순 웹사이트면 Caddy가 콘텐츠를 직접 서빙하고, “웹 앱”이면 거의 전부 컨테이너화한 뒤 Caddy가 TLS 종료와 Docker 아래 앱으로의 역방향 프록시를 맡음
보통 ~/apps/appname 구조이고, 각 앱 디렉터리에 Docker Compose 파일과 마운트된 데이터 디렉터리를 둠
compose down 후 (s)ftp로 데이터를 꺼내 장기 보관하거나 사이트/서비스를 옮길 수 있음
한때 전용 서버에서 여러 VM을 돌렸지만 OVH의 별도 VPS들로 옮겼고, OVH에서 메일을 돌리려면 메일 호스팅을 허용하지 않는 local zone VM은 피해야 함
환경에 따라 다를 수 있음
- 한 프로젝트에서 Traefik을 쓰기 시작했는데 nginx proxy manager보다 좋은 업그레이드였음
  NPM도 훌륭하고 웹 GUI도 괜찮지만, Traefik은 Docker Compose 파일에 원하는 동작만 적으면 끝남
- 내 홈 설정도 비슷함
  다만 Unraid가 컨테이너를 돌리고, 그중 하나가 다른 서비스들을 역방향 프록시하도록 설계된 nginx 계열 도구임
- 나도 거의 같은 방식으로 함
  Debian에서 Flatcar처럼 컨테이너 우선이고 불변 시스템/OS인 쪽으로 바꿀지 고민 중임
  FreeBSD에는 흥미로운 기술적 장점이 있지만, 좋든 싫든 많은 오픈소스 소프트웨어의 기본값은 Docker이고, 모든 걸 FreeBSD jail로 옮길 시간도 의욕도 없음
몇 주 전에 나도 같은 일을 했음
서버는 2015년쯤 이후 업데이트되지 않았고, 그 시절 Ghost 블로그와 node 0.10이 설치돼 있었음
나는 좀 더 거칠게 처리했는데, 백업만 뜬 뒤 Hermes 에이전트(Gemini 3.1 Pro)를 풀어놨음
필요한 모든 업그레이드와 패치를 하고, 최신 대응 항목으로 마이그레이션까지 진행했음
이후 서버 강화와 안 쓰는 서비스 제거도 꽤 진행됐고, AI 지원이 없었다면 아마 계속 미뤘을 것 같음
- AI 없이도 업데이트 자체는 아주 쉽게 할 수 있음
  진짜 문제는 무언가 깨질 위험이고, 그건 백업이 완화해 줌
개인 서버에 FreeBSD를 써본 건 즐거웠음
뭔가 멋지고, 깔끔하고, 단순하며 “펑크 록” 같은 느낌이 있었음
하지만 주요 고통 지점 때문에 포기했음: PM2가 FreeBSD에서 버그가 있었고 프로세스 관리에 쓰던 도구였음, 대안으로 rc.d로 데몬을 돌리려 했지만 로그 설정이 너무 어려웠음, 방화벽은 ICMP를 어떻게 할지 같은 보안 모범 사례까지 맞추려면 직접 설정할 게 너무 많았고 UFW 기본값 같은 템플릿이 아쉬웠음
- FreeBSD에도 그런 기본 템플릿이 포함돼 있음
  PF가 아니라 IPFW로 구현돼 있음
  rc.conf의 firewall_type 키를 보면 됨: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
  단일 머신 방화벽을 쉽게 구성하려면 firewall_type=client를 쓰거나, 뭔가 호스팅하려면 firewall_type=workstation을 쓸 수 있음
  후자의 경우 firewall_myservices와 firewall_allowservices가 어떤 포트를 열지, 어떤 네트워크/IP가 접근 가능한지를 제어함
  아주 단순한 NAT 게이트웨이는 firewall_type=simple과 firewall_simple_(iif|inet|oif|onet)(_ipv6)?로 ISP 쪽/내부 쪽 인터페이스 이름과 IPv4/IPv6 네트워크 범위를 설정하면 됨
  각 옵션이 정확히 뭘 하는지는 /etc/rc.firewall에 구현돼 있음: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
- 감시(supervision) 용도로 PM2를 쓴 건지 궁금함
  rc.d 데몬 로그는 유닉스 방식으로 단순 메시지면 logger(1)를 쓰고, 파일로 리다이렉션한 뒤 newsyslog(8)로 크기를 관리하면 됨
  방화벽은 The Book of PF[0]를 추천함
  FreeBSD의 PF는 OpenBSD의 pf와 문법 차이가 있지만, 방화벽이 어떻게 동작하는지 감을 잡고 어떤 규칙을 써야 할지 이해하기엔 충분함
  [0]: https://nostarch.com/book-of-pf-4e
- PM2는 어떤 OS에서 쓰든 항상 버그가 있었음
  처음엔 엄청 편하지만 동시에 쓰기 불쾌한 소프트웨어였고, 배포 시 환경 변수 업데이트가 의도대로 된 적이 한 번도 없었음
- 내 주요 고통은 정전 뒤에 버티지 못한다는 점이었음
  전원이 나가면 재부팅 후 파일시스템을 수동으로 fsck하라고 요구함
약간 다른 이야기지만, 지금 지원 주기가 가장 긴 무료 Linux 배포판은 무엇인지 궁금함
한동안 작은 VM들에는 CentOS 7을 썼는데, 보안 업데이트가 아주 오래 제공됐고 업데이트로 무언가 깨질 위험도 최소였음
조금 찾아보니 현재는 Alma/Rocky Linux가 가장 나은 선택 같고 10년 지원이 제공됨
다만 잘 유지보수되고 있는지는 궁금함
- 나도 10년 넘게 장기 안정성과 마음의 평화를 기대하며 서버에 CentOS를 돌렸음
  그런데 그렇게 긴 기간이 지나면 생태계가 크게 drift하고, OS 위에서 애플리케이션을 최신으로 유지해 실행하는 일이 점점 어려워짐
  glibc, Python/Apache 조합, GCC 같은 인프라 패키지가 최신 애플리케이션 스택과 서서히 맞지 않게 됨
  이후 버전 업그레이드도 고통스러웠는데, 이상한 패키지 혼합으로 스스로 구석에 몰렸기 때문만이 아니라 업그레이드 경로 자체가 늘 최선 노력 수준이었음
  6에서 7로 넘어가다 포기했던 것 같고, 결국 내게 필요한 건 Fedora였다고 깨달음
  1년 또는 반년 주기 업데이트면 배포판 패키지와 싸울 필요가 없고, 구성은 최신으로 유지되며 동작하고, 주요 배포판 업그레이드도 매끄럽고, 중단 시간도 최소임
  다시는 “서버 배포판”으로 돌아갈 생각이 없음
- Alma는 이제 RHEL 소스 호환이 아니어서 약간의 여지가 있음
  예를 들어 권한 상승 취약점 수정 커널 업데이트를 더 빨리 낼 수 있음
  Rocky는 RHEL에서 내려오기를 기다리는 동안 익스플로잇 완화를 제공하는 선택형 보안 저장소로 대응했음
  최근 사건만 놓고 보면 둘 다 꽤 잘 유지보수되는 편으로 보임
- 개인 서버에 롤링 릴리스 배포판을 쓰지 않을 이유를 잘 모르겠음
  모든 서비스는 컨테이너에서 돌리고, 기본 OS는 필요한 만큼 자주 자동 업데이트하게 두면 됨
  나는 openSUSE MicroOS를 골랐고, 거의 매일 업데이트와 재부팅을 해서 서버가 건강하다고 꽤 확신할 수 있음
  원자적 업데이트라 뭔가 깨져도 당장 처리하기 싫으면 Cockpit에서 롤백 버튼을 누르고 시간 날 때 보면 됨
- 호스팅하는 것이 업그레이드 주기보다 오래 살지 않을 것이라고 베팅하는 셈임
  결국 업그레이드가 오면 꽤 고통스러울 가능성이 큼
  오래 지나 모든 게 바뀐 뒤 큰 점프를 하는 것보다, 더 작은 버전 점프를 자주 하는 편이 낫다고 봄
- 완전 무료를 원하거나 머신이 많다면 Alma와 Rocky가 맞음
  Red Hat에 등록해도 괜찮다면 RHEL도 있고, 등록 계정당 10대까지 업데이트 접근을 무료로 줌
  RHEL은 확실히 주요 배포판 중 가장 안정적이고, Alma와 Rocky는 본질적으로 RHEL의 다운스트림 클론임
나도 같은 배를 타고 있음
“너무” 오래 방치한 낡은 서버가 2대 있고, 이제 업데이트하려고 건드리기가 두려움
다만 Linux 배포판들이 나이 확인/증명 쪽에서 벌이는 소동을 보면 아예 떠날까도 생각 중임
Artix도 시도했지만, 지난주 재시작 후 깨졌고 이전 커널 업데이트에서 뭔가 잘못됐던 듯해서 rescue ISO까지 꺼내야 했음
그래서 그 장비는 Devuan으로 바꿨지만 아직 판단 보류임
큰 불만은 없지만 아직 burn-in 단계임
노트북에는 Arch를 돌리고 있는데, 커뮤니티가 검열 문제로 좀 적대적으로 느껴져서 주말 시간이 나면 밀고 다른 걸 설치하려고 기다리는 중임
소프트웨어에 정치적 드라마는 원하지 않음
흥미롭게도 이번이 새 노트북을 사서 Windows로 한 번도 부팅하지 않고 바로 Linux를 설치한 첫 사례였고, 모든 것이 “그냥 동작”했음
이제 Linux를 신나게 써보려는 시점에 큰 플레이어들이 AI everywhere, 나이 증명/확인, 기본 켜짐 원격 측정 같은 프라이버시 침식 단계를 받아들이는 게 슬픔
그런 쪽과의 상호작용은 그냥 “nope” 하려 함
- 예전에 Ubuntu 서버를 10년 방치했다가 20분 만에 고통 없이 업데이트한 적이 있음
  그 서버는 지금도 최신 LTS로 계속 돌고 있음
  시작이 Ubuntu 4였는지 6이었는지도 모르겠지만, 쭉 무난했음
  어쩌면 느린 업그레이드가 초기 도입자 고통을 피하게 해줬을 수도 있음
  요즘은 Debian을 훨씬 더 많이 씀
  공급망 공격이 많은 상황에서 Debian Stable은 정말 보석 같고, 더 최신 버전이 필요해서 따로 처리해야 하는 패키지가 몇 개 있더라도 구식의 담백한 엔지니어링 정신이 좋음
- 나이 확인/증명 관련해서는 잘못 인도된 것 같음
- 이전 커널 업데이트가 잘못돼 재시작 후 깨진 건 대체로 Arch/Artix의 문제임
  둘은 최신 흐름을 가장 빨리 따라가는 쪽이고, 안정성에는 항상 최선이 아님
  하지만 롤링 배포판이 항상 모든 것의 최신 버전만 제공해야 한다는 뜻은 아님
  지난 몇 달간 Void Linux를 쓰고 있는데, 롤링 배포판이지만 LTS 커널을 사용하고 메인라인도 선택 가능하며, 유지보수자들은 빠른 업데이트보다 안정적인 앱 버전에 더 집중함
- 내 서버/VM은 보통 FreeBSD나 Alpine을 돌림
  필요한 곳에는 Debian도 조금 있음, 예를 들면 Proxmox, Alpine을 지원하지 않는 VPS, 회사 관련 장비 등임
  Chimera를 돌리는 테스트 시스템도 몇 대 있지만 안정판이 나오기 전까지는 많이 의존하지 않을 생각임
  AerynOS도 조금 실험 중임
- FreeBSD의 지원 주기가 더 길었으면 좋겠음
  릴리스 지원 수명이 1년 미만이라 업그레이드 창을 놓치면 이후 업그레이드가 Debian Stable 같은 다른 배포판보다 더 어려워짐
서버 용도는 Debian과 Ubuntu로 옮겼지만, 젊었을 때인 2000년대 중반에는 FreeBSD에 빠져 있었음
실제로 유용한 일을 하기보다 설정하고 세팅하는 데 더 많은 시간을 썼음
그때는 BSD 계열을 제공하는 전용 서버나 VPS를 찾기 어려웠고, Panix.com 같은 곳으로 정착했던 것 같음
그전에는 뉴저지 쪽 NAC였던 듯한 15MinuteServers라는 회사가 BSD를 제공했던 기억도 있음
이제는 그냥 추억을 주절거리는 중임
- 요즘은 내 제공업체들에서 설치가 꽤 간단함
  Hetzner와 OVH에서 FreeBSD를 쓰고 있고, 예전에는 Vultr도 써봤음
- OVH에는 FreeBSD 템플릿이 있음
  그리고 대부분의 KVM VM/VPS 제공업체는 콘솔 접근과 사용자 ISO 마운트를 허용하므로 원하는 것을 설치할 수 있음
fastfetch가 실제보다 메모리를 더 많이 사용한다고 보고하는 건 아마 ZFS ARC 때문일 가능성이 큼
Linux의 페이지 캐시와 비슷하게 언제든 회수될 수 있고, 도구마다 이름을 다르게 붙임: https://www.linuxatemyram.com/
누군가 Docker를 처음 설명해줬을 때 “아, jail 말하는 거야?”라고 답했던 기억이 있음
글에서 설명하듯이 완전히 같지는 않음
kqueue도 큰 승리였음
FreeBSD 개발자들에게 정말 고마움
첫 회사를 15년 동안 FreeBSD 위에서 운영했고, 가동 시간과 회복탄력성이 놀라웠음
나도 업데이트하기 두려운 Ubuntu 16.04 서버가 있음
현재 가동 시간이 1281일이고, 이쯤 되니 재부팅하기가 미안해짐
- 파일시스템을 다른 머신에 dd로 복사한 뒤 qemu 같은 에뮬레이터로 부팅해서 예행연습을 해보면 됨
  자동 시작되는 것 중 외부로 접속하는 게 있으면 조심해야 함
- 무엇이 두려운 건지 모르겠음
  백업은 있지 않나?
  Debian/Ubuntu 시스템은 정기적으로 자동 업데이트와 재부팅을 하도록 쉽게 설정할 수 있고, 수동 유지보수는 더 큰 버전 업그레이드 때만 남게 됨
- 내 가장 오래된 서버는 8.04에 있음

답변달기

블로그를 Ubuntu 16.04에서 10년 동안 운영하다가 FreeBSD로 마이그레이션함

마이그레이션 배경

FreeBSD를 선택한 이유

FreeBSD 설치와 Bastille 도입

네트워크와 리버스 프록시 구조

Caddy와 사이트별 Jail 구성

사이트와 블로그 배포

벤치마크와 부하 테스트

Vultr VPS 기반 지역별 테스트

최종 전환과 핵심 교훈

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들