배경:여기에 자세히 설명했듯이, 제 Discourse 설치 환경은 디스크 용량이 업그레이드를 완료하기에 너무 작은 VPS에 호스팅되어 있었습니다. 처음에는 관리자 제어판에서 “업그레이드” 버튼을 클릭했습니다. 업그레이드가 실패했고, GUI는 그 후로 다시 작동하지 않았습니다. 그 후 VPS 콘솔에 로그인하여 유명한 ./launcher rebuild app 명령을 실행했습니다. 이것도 완료되지 않았습니다: 디스크 저장 공간이 완전히 부족했기 때문입니다. 예산을 지키면서 더 많은 공간을 확보하기 위해, 전체 설정을 다른 호스팅 회사의 새 VPS로 이전하기로 결정했습니다. 귀중한 사이트 데이터를 저장하는 것이 최우선 과제였습니다.
실패: 백업을 만드는 가장 명백한 두 가지 방법은 작동하지 않았습니다:
원래의 업그레이드 시도가 웹 기반 GUI를 망가뜨렸기 때문에, 관리자 제어판에 접근하여 거기서 백업을 시작할 수 있는 방법이 없었습니다.
docker 컨테이너 내부로 들어가 셸 명령을 실행하려는 시도도 작동하지 않았습니다. 이를 위한 권장 명령은 /var/discourse/launcher enter app입니다. 하지만 제 경우를 포함해 적어도 일부 경우에서 launcher 스크립트는 컨테이너에 진입하기 전에 앱을 재빌드하려고 시도했고, 재빌드가 계속 실패했기 때문에 이 명령은 컨테이너에 접근하는 것조차 불가능했으며, 더 나아가 컨테이너 내부의 셸에 접근하는 것도 불가능했습니다.
성공: 포기하려던 참에 기쁜 놀라움을 받았습니다. 작은 VM의 명령줄에서 작업하면서 docker ps를 입력했고, app이라는 이름의 활성 컨테이너가 있다는 것을 알게 되었습니다. Docker에는 실행 중인 컨테이너 내부로 직접 들어가는 방법이 있습니다: 그 명령은 docker exec -it app bash입니다.
컨테이너 내부에서 저는 진전을 이룰 수 있었습니다: discourse backup 명령을 실행하고 몇 분간 기다린 후, <backup>.tar.gz 파일을 안전한 새로운 위치로 복사했습니다. 최신 백업을 확보한 덕분에 제 설정을 새 환경으로 이전하는 작업을 완료할 수 있었습니다. (이 포럼에는 이를 수행하는 방법을 보여주는 다른 스레드들이 있습니다.)
여기서 핵심은 Discourse 전용 ./launcher 명령이 작동하지 않았을 때에도 컨테이너에 진입하기 위한 위의 docker 명령은 작동했다는 점입니다.
원래 설정을 정상적으로 작동시키기 위해 애쓰던 동안, 공간을 확보하기 위해 할 수 있는 모든 일을 했다고 생각했습니다. ./launcher cleanup 실행은 물론이고, 오래된 커널 제거, apt 캐시 정리, 비필수 소프트웨어 삭제 등 훨씬 더 많은 작업을 수행했죠.
결국 사이트 전체를 이전하기로 결심하고 그 과정에 많은 시간을 쏟은 후, 더 많은 일을 할 수 있었을지 궁금해졌습니다. 하지만 그때쯤이면 더 깊이 파고들고 싶은 의욕을 잃어 버린 상태였습니다. (일종의 "몰입 비용 오류"라고 할 수 있죠.) 구체적으로 말씀드리면, 곧 폐기할 VPS의 명목상 디스크 용량은 25GB였습니다. 이 중 약 19GB가 /var/lib/docker/overlay2 디렉토리에 할당되어 있었습니다. 그리고 제가 실행 중이던 도커 컨테이너는 Discourse와 관련 메일 수신기뿐이었습니다. 경험상 Discourse는 강력하지만, 디스크 용량 19GB보다 훨씬 적은 공간으로도 실행 가능해야 합니다. 하지만 인터넷 검색 결과 overlay2 디렉토리 내부에서 변경 사항을 적용하는 것은 안전하지 않다는 지적이 있어서, 그 지점에서 더 이상 진행하지 못했습니다.
새로운 설정에서 /var/lib/docker/overlay2 디렉토리는 13GB를 차지하고 있습니다. 여전히 엄청난 크기입니다.
소규모 취미 웹사이트에서 포럼을 운영하기 위해 Discourse를 선택한 이유는 “그냥 잘 작동하기를” 바랐기 때문입니다. 즉, 새로운 것을 많이 배우지 않고도 관리가 매우 쉬울 것이라는 기대였죠. 이는 대체로 사실이지만, 충분한(혹은 과도한?) 리소스를 할당할 수 있는 경우에만 해당됩니다.
제 새로운 계획은 overlay2 디렉토리가 시간이 지남에 따라 커지지 않기를 무작정 믿고, 새 VPS의 50GB 디스크가 가득 차는 일이 없기를 기원하는 것입니다. 도커와 Discourse라는 콤비의 크기를 어떻게 통제할 수 있는지 아시는 분(혹은 저를 포함한 누구라도)이 있다면, 그 방법을 듣고 싶습니다. 최근 며칠 동안 배운 것들의 멋진 마무리가 될 것입니다. 다시 한번 감사합니다.
스스로 문제를 해결할 수 있어 다행입니다. 저는 작은 포럼 두 개를 운영하는데, 하나는 20GB 저장공간, 다른 하나는 25GB 저장공간을 사용하고 있습니다. 이를 유지하기 위해 때로는 상당한 시간과 창의성이 필요하지만, 결국 매번 같은 전술(과 그 공유)을 반복하는 것 같습니다. 아래를 참고해 주세요.
Discourse 개발은 최소 비용 하드웨어에서 실행하는 것보다 다른 요소들에 최적화되어 있습니다. 물론 제 제한적인 환경에서도 간신히 계속 작동하고 있기는 합니다. 앞으로도 계속 작동하기를 바랍니다.
작은 저장공간 환경에서 작업하는 핵심은 무슨 일이 일어나고 있는지 측정하는 것입니다. 많은 분들이 무슨 일이 일어나고 있는지 추측만 하는 경우가 너무 많습니다. 제 접근 방식은 항상 다음부터 시작됩니다.
더 자세한 내용은 제 게시글에서 prune, journalctl, kernel을 검색해 보세요.