Instance 실행기

GitLab Runner의 Instance 실행기를 사용하여 자동 스케일링 환경에서 온디맨드 인스턴스를 생성하고 CI/CD 작업을 실행하는 방법을 설명합니다.

히스토리 GitLab Runner 15.11.0에서 실험적 기능으로 도입되었습니다. GitLab Runner 16.6에서 베타 로 변경 되었습니다. GitLab Runner 17.1에서 일반 공개 되었습니다. Instance 실행기는 러너 관리자가 처리하는 작업량에 맞춰 온디맨드로 인스턴스를 생성하는 자동 스케일링 지원 실행기입니다. 작업에서 호스트 인스턴스, 운영 체제, 연결된 장치에 전체 접근이 필요한 경우 Instance 실행기를 사용할 수 있습니다. Instance 실행기는 다양한 수준의 격리 및 보안을 갖춘 단일 테넌트 및 다중 테넌트 작업을 수용하도록 구성할 수도 있습니다. 중첩 가상화 # Instance 실행기는 GitLab이 개발한 nesting 데몬 을 통해 중첩 가상화를 지원합니다. nesting 데몬은 작업과 같이 격리되고 단기적인 워크로드에 사용되는 호스트 시스템에서 미리 구성된 가상 머신을 생성하고 삭제할 수 있도록 합니다. Nesting은 Apple Silicon 인스턴스에서만 지원됩니다. 자동 스케일링을 위한 환경 준비 # 자동 스케일링을 위한 환경을 준비하려면: 러너 관리자가 설치되고 구성된 대상 플랫폼에 맞는 fleeting 플러그인을 설치 합니다. 사용 중인 플랫폼에 맞는 VM 이미지를 생성합니다. 이미지에는 다음이 포함되어야 합니다: Git GitLab Runner 바이너리 작업 아티팩트와 캐시를 처리하려면, 가상 머신에 GitLab Runner 바이너리를 설치하고 러너 실행 파일을 기본 경로에 유지해야 합니다. VM 이미지는 GitLab Runner를 실행할 필요가 없습니다. VM 이미지를 사용하여 실행된 인스턴스는 GitLab에 러너로 등록되어서는 안 됩니다. 실행할 작업에 필요한 의존성 네이티브 단계용 GitLab Runner 바이너리 # Instance 실행기에서는 run 키워드를 사용하는 작업이 자동으로 네이티브 단계 로 실행되며 gitlab-runner 바이너리가 필요합니다. Docker 실행기 와 달리 기능 플래그가 필요하지 않습니다. Windows 인스턴스에서는 네이티브 단계가 지원되지 않습니다. 네이티브 단계를 사용하려는 경우: gitlab-runner 바이너리가 인스턴스의 PATH 에 있어야 합니다. 바이너리를 러너 관리자와 동일한 버전으로 유지하세요(버전이 일치하지 않으면 경고가 기록되지만 작업이 실패하지는 않습니다). SSH 세션 제한: 각 native-steps 작업은 인스턴스에 대해 두 개의 동시 SSH 세션을 엽니다(하나는 step-runner 서버용, 다른 하나는 프록시 연결용). capacity_per_instance 를 1보다 크게 설정하는 경우 sshd_config 의 MaxSessions 를 최소 2 * capacity_per_instance 로 설정하세요. 그렇지 않으면 OpenSSH 기본 제한(10)에 도달했을 때 작업이 불명확한 연결 오류로 실패할 수 있습니다. 자동 스케일링을 위한 실행기 구성 # 사전 요구 사항: 관리자여야 합니다. 자동 스케일링을 위해 Ins