Coolify

Coolify가 실제로 하는 일

Coolify (github.com/coollabsio/coolify)는 내가 소유한 서버를 위한 제어 평면입니다. SSH로 머신 한 대를 지정하면 — 프로젝트 자신의 표현으로는 VPS, 베어메탈, 또는 라즈베리 파이 — git 저장소와 실행 중인 서비스 사이의 거리를 대신 메워 줍니다. 이미지 빌드, 컨테이너 실행, 인증서 발급, 도메인 연결, 그리고 그 옆에 데이터베이스와 원클릭 서비스를 함께 두는 일까지입니다. 배지가 아니라 LICENSE 파일을 읽어 보면 확인되는데, 수정되지 않은 순수한 Apache 2.0 본문이고 부록 조항도 없으며 무료 코어와 유료 디렉터리를 가르는 선도 없습니다. 이웃한 몇몇 프로젝트가 택한 오픈 코어 방식과는 그 점이 다릅니다. 유료 클라우드 버전이 있긴 하지만, 저장소 자신의 설명에 따르면 이 프로젝트는 어떤 기능도 결제 장벽 뒤에 두지 않을 생각이고, 클라우드가 파는 것은 고가용성과 알림, 지원, 그리고 유지보수를 남에게 맡기는 편의입니다.

차분히 읽어 볼 만한 대목은 공급업체 종속에 관한 문장입니다. README는 설정이 당신 자신의 서버에 기록되므로 Coolify를 그만 쓰더라도 돌아가는 것들을 계속 관리할 수 있다고 말한 뒤, 다만 자동화는 잃게 된다고 스스로 덧붙입니다. 보기 드물게 솔직한 서술이고, 머릿속 모형으로도 정확합니다. 남는 것은 컨테이너와 설정이고, 잃는 것은 그것들을 다시 빌드하고 다시 배포해 주던 기계 장치입니다. 그래도 같은 질문에 대해 대부분의 관리형 플랫폼이 내놓는 답 — 내보내기 버튼 하나이거나 아무것도 없거나 — 보다는 훨씬 낫습니다.

실제로 비교하고 있는 청구서

표면적인 비교는 쉽고, 그래서 오해를 부릅니다. 관리형 플랫폼은 작은 서버 두 대로 비슷하게 흉내 낼 수 있는 것에 월 요금을 매기므로, 시작하기도 전에 산수가 끝난 것처럼 보입니다. 진짜 비교 대상은 청구서가 아니라 청구서에 시간을 더한 값입니다. 그리고 그 시간이야말로 처음에 아무도 정직하게 추정하지 않는 절반입니다. 나중에, 잘게 쪼개져서 도착하기 때문입니다.

이 중 어느 것도 직접 호스팅을 반대하는 근거가 아닙니다. 의식적으로 선택하라는 근거입니다. 내 시간이 청구서보다 쌀 때, 돌릴 서비스가 여럿이라 제어 평면의 고정비가 나뉠 때, 그리고 남이 정해 둔 보이지 않는 한계보다 내 눈에 보이는 한계에 부딪히는 편이 낫다고 여겨질 때, 이것은 좋은 거래입니다. 첫 고객을 찾고 있는 달에는 나쁜 거래입니다. 거기에 들어가는 한 시간은 만든 것을 누군가 보러 오게 만드는 일에 쓰지 못한 한 시간이기 때문입니다.

관리형 플랫폼에서 우리 서비스군을 운영하며 배운 것

우리는 Coolify를 쓰지 않으므로 이 페이지는 그 운영에 관해 아무것도 주장하지 않습니다. 일차 경험으로 말할 수 있는 것은 반대편의 결정입니다. 우리는 고객 작업 공간마다 컨테이너 하나를 관리형 플랫폼 위에서 돌리고 있고, 놀랐던 것이 셋 있습니다. 어느 쪽을 택하든 미리 알아 둘 값어치가 있는 셋입니다.

첫째, 관리형 플랫폼의 한계는 남이 정한 숫자이고, 그것이 당신의 사용자 앞에 드러날 수 있습니다. 우리 플랫폼은 한 프로젝트가 담을 수 있는 서비스 수에 상한이 있습니다. 그 천장에 닿았을 때 장애는 경보로 오지 않았습니다. 가입 도중이던 고객의 화면에 플랫폼 자신의 할당량 초과 메시지가 뜬 형태로 왔습니다. 우리 공급업체 이름이 박혀 있고, 고객이 아니라 우리를 향한 요금제 상향 권유까지 붙은 문구였습니다. 내가 직접 빌린 하드웨어의 한계라면 적어도 다가오는 것이 보입니다. 이것은 Coolify에 유리한 진짜 논거이며, 여기 적은 것들 중 우리가 가장 무겁게 치는 한 가지입니다.

둘째는 설계의 문제입니다. 우리의 해법은 고객마다 전용 서비스를 주는 방식을 그만두고, 도착하는 고객을 범용 서비스 묶음 중 하나에 묶는 방식으로 바꾼 것이었습니다. 관리형이든 직접 호스팅이든 고객당 컨테이너 하나를 계획하고 있다면, 그 주위를 설계하기 전에 천장이 어디인지부터 확인하십시오. 나중에는 늦습니다.

셋째는 절약 그 자체에 관한 것입니다. 놀고 있는 머신을 0까지 내리는 것은 실제로 돈이 됩니다. 그리고 어려운 부분은 재우는 것이 아니라 계속 자게 두는 것입니다. 우리가 쫓아간 모든 깨어남은, 아무도 트래픽이라고 생각하지 않던 백그라운드 타이머였습니다. 헬스 체크, 상태 폴링, 다른 창에 열어 둔 대시보드. 로그인한 채 잊힌 탭 하나가 혼자 새로고침을 계속한 것만으로 그 작업 공간은 거의 상시 깨어 있었고, 나머지 대부분은 하루의 대부분을 자고 있었습니다. 그래서 그 작업 공간에서의 절약은 0이었습니다. 직접 호스팅하는 구성에 주기적인 작업을 하나 더하기 전에, 그것이 자고 있어야 할 머신에 무슨 짓을 하는지 물어보십시오.

이것이 이 선택의 정직한 모양입니다. Coolify는 배포 버튼을 내가 통제하는 하드웨어로 옮겨 주고, 호출기도 함께 건넵니다. 어느 쪽으로 가든 배포는 문제의 끝이 아니라 시작입니다. 방금 올린 그것을 아직 누군가는 찾아내 주어야 하고, 그것은 돌아가게 만든 기술과는 다른 기술입니다. 창업자가 결국 그 옆에 함께 돌리게 되는 직접 호스팅 부품으로는 백엔드용 PocketBase, 언제 내려갔는지 알기 위한 OpenStatus, 그리고 검색창이 의미를 갖기 시작할 때의 Meilisearch가 있습니다.