Git, Docker 이미지, 데이터베이스, 프리뷰 앱용 홈 개발 서버 구축 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Build a Home Development Server for Git, Docker Images, Databases, and Preview Apps - Zima Store Online

하나의 안정적인 서비스 기반을 구축하고, 영구 데이터를 재생성 가능한 아티팩트와 분리하며, 호스트 자체를 보존하지 않고도 모든 개발자 서비스를 복구할 수 있도록 하세요.

집에서 한두 명의 개발자가 사용하는 경우, 하나의 Linux 서버에서 Git, 이미지 레지스트리, 데이터베이스, 프리뷰 애플리케이션을 호스팅할 수 있습니다. 서비스가 서로 의존하기 시작하기 전에 ID, 스토리지 역할, 네트워크 노출, 백업, 복구를 계획해야만 설계를 관리 가능한 상태로 유지할 수 있습니다.

하드웨어를 선택하기 전에 서비스 역할을 할당하세요

하나의 호스트를 공유하더라도 Git, 컨테이너 레지스트리, 데이터베이스 엔진, 프리뷰 애플리케이션을 별도의 서비스 역할로 취급하세요. Git은 소스 이력을 보존하고, 레지스트리는 재생성 가능한 아티팩트를 저장하며, 데이터베이스는 변경 가능한 애플리케이션 상태를 보관하고, 프리뷰 앱은 폐기 가능한 런타임입니다.

동시 빌드 수, 데이터베이스 작업 세트, 활성 프리뷰를 기준으로 CPU와 메모리를 산정하세요. 리포지토리, 레지스트리 보존 데이터, 데이터베이스 증가량, 로그, 백업 스테이징을 기준으로 스토리지를 산정하세요. 이렇게 하면 대용량 디스크를 구매하고도 메모리가 먼저 병목이 되는 상황을 피할 수 있습니다.

개발 환경에서 장애를 감수할 수 있다면 처음에는 하나의 컴퓨팅 노드를 사용하세요. 버스트성 컴파일로 인해 데이터베이스나 대화형 프리뷰가 느려지기 시작하면 빌드 워커를 분리하세요.

영구 데이터, 재생성 가능한 데이터, 복구 데이터를 분리하세요

데이터 역할	예시	보호 방법
영구 상태	Git 리포지토리, 데이터베이스 볼륨	스냅샷 및 독립 백업
재생성 가능한 아티팩트	컨테이너 이미지, 빌드 캐시	보존 정책; 선택적 백업
시크릿 및 구성	배포 키, 환경 파일	암호화된 내보내기 및 오프라인 복구 사본
복구 미디어	OS 설치 프로그램, 복구 안내	서버 외부에 보관

모든 바이트를 동일하게 백업하지 마세요. 레지스트리는 일반적으로 소스와 빌드 지침으로 다시 만들 수 있지만, 데이터베이스는 그렇지 않습니다. 데이터베이스 덤프 또는 일관된 스냅샷을 실행 중인 데이터베이스 볼륨과 분리해 저장하세요.

실용적인 셀프 호스팅 백업 계획에서는 NAS 자체를 백업이라고 간주하지 않고 Git과 오프사이트 복사본을 별도의 작업으로 자동화하는 것이 얼마나 중요한지 보여줍니다.

하나의 비공개 액세스 경로를 만드세요

서버에 안정적인 LAN 주소와 로컬 DNS 이름을 할당하세요. Git, 레지스트리, 데이터베이스, 프리뷰 경로는 이를 필요로 하는 네트워크에만 노출하세요. 원격 액세스는 여러 서비스 포트를 포워딩하는 대신 비공개 VPN 또는 인증된 리버스 프록시 경로를 통해 진입해야 합니다.

서비스 계정과 배포 키를 পৃথ따로 사용하세요. 개발자가 관리자 비밀번호를 공유해서는 안 되며, 프리뷰 애플리케이션이 Git 리포지토리나 레지스트리를 수정할 수 있는 자격 증명을 상속해서도 안 됩니다.

실제로 공유 마운트가 필요한 파일 작업에만 SMB 또는 NFS를 사용하세요. SMB 및 NFS 클라이언트 적합성 가이드를 참고하면 프로토콜 선택과 애플리케이션 서비스 액세스를 별개의 문제로 유지할 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

배포 순서를 종속성 그래프에 맞추세요

스토리지 마운트, ID, 데이터베이스, 레지스트리, Git, 프리뷰 애플리케이션 순서로 시작하세요. 상태 확인은 실제 종속성을 테스트해야 하지만, 애플리케이션이 아직 준비 중이라는 이유만으로 느린 데이터베이스를 재시작해서는 안 됩니다.

배포 정의, 스키마 마이그레이션, 리버스 프록시 경로를 버전 관리에 보관하세요. 시크릿은 리포지토리 외부에 보관하고 복구 위치를 명확히 하세요. 교체 호스트는 정의와 보호된 상태만으로 서비스를 재생성할 수 있어야 합니다.

깨끗한 체크아웃에서 프리뷰 앱 하나를 재빌드하고, 해당 이미지를 가져오고, 테스트 데이터베이스 복구를 적용한 뒤, 의도한 클라이언트 경로에서 접속해 검증하세요.

수집이 아니라 복구를 위해 백업하세요

리포지토리, 데이터베이스 네이티브 덤프, 서비스 구성, 암호화된 시크릿을 모든 서비스가 쓰기 권한으로 마운트할 수 없는 대상에 백업하세요. 서버의 전원 및 관리자 경계 외부에 최소 한 개의 사본을 보관하세요.

분기마다 격리된 네임스페이스에 복구를 수행하세요. 파일이 존재하는지만 확인하지 말고 사용자, 확장 기능, 예약 작업, 리포지토리 권한, 레지스트리 인증, DNS 경로를 확인하세요.

빌드 대기열로 대화형 작업이 지연되거나, 이미지를 푸시하는 동안 데이터베이스 지연 시간이 증가하거나, 백업 시간이 업무 시간과 겹치기 시작하면 확장하세요. 하나의 실험적 서비스가 안정적인 서비스 기반에 필요한 리소스나 자격 증명을 고갈시킬 수 있다면 같은 호스트에 역할을 계속 추가하지 마세요.