셀프 호스팅 Git 러너가 개발자의 일상적인 워크플로에 포함되면 무엇이 달라질까요?

에바 왕

IceWhale author

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

What Changes When a Self-Hosted Git Runner Becomes Part of a Developer's Daily Workflow? - Zima Store Online

셀프 호스팅 Git 러너가 일상적인 워크플로에 들어오면 프로덕션 의존성이 됩니다. 이제 개발자는 러너의 대기열, 도구 체인, 네트워크 액세스, 시크릿, 캐시, 복구 시간에 의존하게 됩니다.

따라서 토폴로지는 제어와 실행을 분리하고, 작업을 일회용으로 만들며, 의도적으로 공유하는 상태만 보존해야 합니다. 빠른 영구 러너는 편리하지만, 숨겨진 환경 차이와 광범위한 자격 증명은 이러한 편리함을 취약한 신뢰 경계로 바꿀 수 있습니다.

러너를 원격 코드 실행으로 취급하기

승인된 모든 작업은 사용자가 소유한 인프라에서 저장소가 제어하는 코드를 실행합니다. 배포 또는 패키지 자격 증명을 연결하기 전에 어떤 저장소, 브랜치, 기여자, 풀 리퀘스트 이벤트가 러너에 도달할 수 있는지 정의하세요.

마이크로VM 기반 러너 설계는 일회용 가상 머신을 사용해 셀프 호스팅 성능을 유지하면서 한 작업에서 다음 작업으로 전달되는 상태를 줄입니다.

신뢰할 수 있는 릴리스 작업과 일반 테스트에는 별도의 러너 그룹을 사용하세요. 공개 워크플로 또는 포크에서 트리거된 워크플로는 프로덕션 배포 시크릿이 있는 실행 환경을 공유해서는 안 됩니다.

빠른 단일 머신에서 대기열 계약으로 전환하기

매일 사용하면 작업 수신 시간, 동시성, 취소, 우선순위에 대한 기대가 생깁니다. 테스트가 느린 것과 러너 용량이 부족한 것을 혼동하지 않도록 대기열 지연 시간을 작업 실행 시간과 별도로 측정하세요.

동시 빌드로 인해 메모리, 스토리지 또는 Docker 풀 작업이 포화되기 전 수준으로 동시성을 설정하세요. 긴 테스트 매트릭스 뒤에서 대기하면 안 되는 대화형 작업이나 릴리스 작업을 위해 용량을 예약하세요.

러너가 오프라인일 때 개발자가 사용할 대체 경로를 문서화하세요. 호스팅 실행, 로컬 명령 또는 지연 가능한 비핵심 작업 등이 될 수 있습니다. 대체 경로가 없으면 유지 관리가 계획되지 않은 개발 중단으로 이어집니다.

재구축 가능한 캐시와 영구 상태 분리하기

러너 상태	보존?	보호 방법
체크아웃된 소스	아니요	작업별로 가져오기
종속성 및 레이어 캐시	재구축 가능	할당량 및 가비지 컬렉션
러너 등록 정보	교체 가능	자동 등록
빌드 아티팩트	보존 정책에 따름	외부 아티팩트 저장소
시크릿 및 배포 키	예, 단 디스크에는 저장하지 않음	범위가 제한된 시크릿 서비스

캐시는 일상적인 작업 흐름을 개선하지만 크기 제한, 소유권 모델, 삭제 규칙이 있어야 합니다. 빌드 아티팩트와 릴리스 증적은 제한 없이 커지는 작업 공간 폴더가 아니라 명시적인 보존 정책이 적용되는 외부 대상에 저장해야 합니다.

이미지 또는 프로비저닝 스크립트로 러너를 교체할 수 있게 만드세요. 호스트를 재구축했을 때 유일한 서명 키나 테스트 결과가 사라진다면, 해당 자산은 잘못된 역할에 저장된 것입니다.

-15% OFF

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

Single board computer zimaboard2

패치, 관측 가능성, 장애 책임 추가하기

러너 버전, 운영 체제 패치, Docker 또는 도구 체인 버전, 디스크 사용량, 작업 실패율, 대기열 지연 시간, 캐시 증가량을 추적하세요. 러너가 개인 서버인 경우에도 하나의 유지 관리 시간대와 하나의 담당자를 지정하세요.

경험적 워크플로 유지 관리 연구에 따르면 자동화 자체가 지속적인 버그 수정과 CI 개선 작업을 만들어 냅니다. 셀프 호스팅을 사용하면 호스트 수명 주기까지 이러한 유지 관리 부담에 추가됩니다.

오프라인 상태, 반복되는 작업 실패, 디스크 가득 참, 비정상적으로 긴 대기열에 대해 알림을 설정하세요. 로그에는 실패 원인이 저장소 코드, 러너 이미지, 네트워크 액세스 또는 호스트 중 어디에 있는지 나타나야 합니다.

일상적인 워크플로 준비 상태 테스트 사용하기

러너를 재구축하고, 배포 자격 증명을 교체하고, 두 개의 동시 빌드를 실행하고, 캐시를 가득 채운 후 정리하며, 작업 중 호스트를 의도적으로 오프라인으로 전환하세요. 개발자가 장애를 확인하고 대체 경로를 사용할 수 있는지 확인하세요.

가동 중단을 허용할 수 있고 작업을 신뢰할 수 있다면 러너를 하나의 호스트에 유지하세요. 서로 다른 자격 증명이나 유지 관리 시간이 필요한 릴리스, 신뢰할 수 없는 작업 또는 하드웨어별 작업은 분리하세요. 홈 서버 OS 가이드는 반복 가능한 업데이트와 복구에 맞춰 러너 호스트를 구성하는 데 도움을 줍니다.

작업 누락으로 릴리스나 고객 업무가 차단되기 시작하면 러너를 취미용 서비스로 취급하지 마세요. 그 시점에는 다른 개발 의존성과 마찬가지로 서비스 소유권, 여유 용량, 검증된 교체 절차를 정의해야 합니다.