개발자들은 왜 CI 러너, 레지스트리, 테스트 데이터베이스를 노트북에서 옮기고 있을까요?

에바 왕

IceWhale author

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

Why Are Developers Moving CI Runners, Registries, and Test Databases Off Their Laptops? - Zima Store Online

팀은 빌드를 반복 가능하게 만들고, 공유 종속 항목에 접근할 수 있게 하며, 테스트 상태를 폐기 가능하게 하고, 한 개발자의 배터리나 작업 공간에 구애받지 않고 배포하기 위해 이러한 서비스를 노트북에서 분리합니다.

서버는 더 큰 노트북이 아닙니다. CI 러너는 신뢰할 수 없는 프로젝트 지침을 실행하고, 레지스트리는 소프트웨어 공급망 아티팩트를 저장하며, 테스트 데이터베이스는 변경 가능한 상태를 보관합니다. 이를 하나로 결합하는 방식은 소규모 팀에서 효율적일 수 있지만, 역할별로 ID, 네트워크, 스토리지, 시크릿, 할당량, 복구를 분리하는 경우에만 그렇습니다.

워크플로 실패부터 시작하기

노트북에서 호스팅되는 CI는 소유자가 잠들거나, 이동하거나, 네트워크를 변경하거나, 덮개를 닫거나, 로컬 CPU와 메모리가 필요할 때 실패합니다. 로컬 레지스트리는 해당 장비와 함께 사라지고, 테스트 데이터베이스에는 한 개발자만 이해하는 상태가 누적됩니다.

지속적 통합은 모두가 확인할 수 있는 빈번하고 자동화된 검증에 의존합니다. Martin Fowler의 지속적 통합 방식은 자동 자체 테스트 빌드와 가시적인 결과를 강조하며, 이러한 특성은 가끔만 사용할 수 있는 노트북에서 보장하기 어렵습니다.

역할을 옮기기 전에 해결하려는 실패가 대기열 지연, 환경 드리프트, 이미지 배포, 공유 통합 상태, 노트북 리소스 경합 중 무엇인지 먼저 명확히 하세요.

러너의 신뢰 경계 분리하기

CI 작업을 코드 실행으로 취급하세요. 가능한 경우 일회성 컨테이너나 가상 머신을 사용하고, 신뢰할 수 없는 작업에 호스트 Docker 소켓을 마운트하지 않으며, 저장소나 파이프라인별로 범위가 좁은 자격 증명을 할당하세요.

빌드 작업 공간과 캐시에 할당량을 설정하세요. 실패한 작업이 서버의 루트 파일 시스템을 가득 채우거나 프로젝트와 관련 없는 레지스트리 자격 증명을 읽어서는 안 됩니다.

신뢰 수준과 기능에 따라 러너 레이블을 정의하세요. 알려지지 않은 기여자의 풀 리퀘스트 코드를 프로덕션 시크릿이나 홈 네트워크에 접근할 수 있는 러너로 보내지 마세요.

레지스트리를 내구성 있는 배포 역할로 만들기

인증, 신뢰할 수 없는 경로에서의 TLS, 보존 규칙, 가비지 컬렉션 시간을 설정하고, 레지스트리 데이터와 구성을 영구 스토리지에 저장하세요. 변경할 수 없는 릴리스 태그와 폐기 가능한 브랜치 이미지를 분리하세요.

구성, 메타데이터, 다시 빌드할 수 없는 아티팩트를 백업하세요. 이미지가 소스에서 재현 가능하다면 모든 캐시 레이어를 백업하는 대신 재빌드 시간과 소스, 빌드 정의, 외부 종속 항목을 문서화하고 보존하세요.

정리하기 전에 용량을 모니터링하세요. 레지스트리 가비지 컬렉션은 I/O를 많이 사용할 수 있으며 구현 방식에 따라 유지 관리 상태가 필요할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

테스트 데이터베이스는 폐기 가능하면서도 대표성을 갖게 유지하기

각 파이프라인이나 브랜치에 격리된 데이터베이스 이름, 스키마, 컨테이너 또는 VM을 할당하세요. 버전 관리된 픽스처나 정제된 데이터셋에서 시드하고, 마이그레이션을 자동으로 실행한 다음, 보존 기간이 끝나면 삭제하세요.

프로덕션 시크릿이나 마스킹되지 않은 개인 데이터를 테스트 역할에 복사하지 마세요. 손상된 작업이 테스트 데이터베이스에서 관련 없는 서비스로 이동할 수 없도록 네트워크 접근 범위를 제한하세요.

실패한 테스트를 진단하는 데 필요한 로그와 아티팩트만 보존하세요. 장기간 남아 있는 정체불명의 데이터베이스는 더 큰 장비에서 노트북 문제를 재현합니다.

소규모 팀 서버 토폴로지 구축하기

러너, 레지스트리, 데이터베이스 역할에 대해 별도의 서비스 계정, 컨테이너 네트워크, 볼륨, 할당량, 백업 규칙을 사용하세요. 이 NAS 및 Docker 플랫폼 가이드는 컨테이너와 가상 머신 중 어떤 방식으로 격리를 제공할지 결정하는 데 도움이 됩니다.

관리 인터페이스는 제한된 네트워크에 배치하세요. 팀에만 또는 인증된 액세스 계층을 통해 레지스트리와 CI UI를 노출하세요. 모든 서비스의 업데이트, 소유권, 롤백을 기록하세요.

러너 재생성, 레지스트리 복원 또는 재빌드, 데이터베이스 재시드, 전체 디스크 상태, 서버 재부팅을 테스트하세요. 공유 서비스가 복구되는 동안에도 개발자는 로컬에서 계속 작업할 수 있어야 합니다.

최종 설정 점검

특정 노트북 없이도 빌드가 실행되고, 버전 관리된 정의에서 환경을 재생성할 수 있으며, 레지스트리 아티팩트에 보존 및 복구 계획이 있고, 테스트 데이터베이스가 격리되고 폐기 가능하며, 어떤 러너도 작업에 필요한 범위를 넘어서는 시크릿을 보유하지 않을 때 이전이 성공한 것입니다.