GitHub Actions 러너 제공업체를 전환하는 방법: 레이블, 캐시, 시크릿, 청구, 폴백

이 가이드는 특정 업체에 치우치지 않습니다. GitHub Actions 러너 제공업체를 바꿀 때 무엇이 옮겨 가는지, 무엇이 가장 자주 깨지는지, 어떻게 되돌리는지 설명합니다. 저희는 제공업체 중 하나인 CRACI를 만듭니다. CRACI는 문서화된 사실이 해당하는 곳과 마지막의 별도 섹션에서만 등장합니다. 먼저 제공업체를 고르려면 GitHub Actions 러너 제공업체 비교와 GitHub 호스팅 러너 대안을 참조하세요.

전환할 때 바뀌는 것과 그대로인 것

GitHub Actions는 두 부분으로 나뉩니다. GitHub는 컨트롤 플레인입니다. 리포지토리와 워크플로 파일을 저장하고, 트리거를 실행하고, 시크릿을 저장하고, 작업을 할당하고, 로그와 체크를 보여 주고, 아티팩트를 보관하고, OIDC 토큰을 발급합니다. CI 러너는 작업이 실행되는 곳입니다. 이미지, CPU, 디스크, 인터넷으로 가는 네트워크 경로, 그리고 보통 로컬 캐시를 갖춘 머신입니다. GitHub는 작업을 러너에 할당하고 작업이 시작될 때 시크릿을 전달하며, 러너는 로그를 다시 스트리밍합니다.

러너 제공업체는 이 중 두 번째 부분만 대체합니다.

항목	GitHub에 남음	제공업체로 이동
리포지토리, 워크플로 파일, 트리거	예	아니요
시크릿 저장소	예	시크릿은 작업 시작 시 제공업체의 머신으로 전달됨
작업 할당, 로그, 체크 UI	예	러너가 로그를 다시 스트리밍함
actions/upload-artifact의 아티팩트	예	아니요
OIDC 토큰 발급자	예	아니요. 단, 토큰에는 러너가 셀프 호스팅으로 표시됨
머신, 이미지, CPU, 메모리, 디스크	아니요	예
아웃바운드 네트워크 경로와 IP 주소	아니요	예
캐시 스토리지	제공업체에 따라 다름	제공업체에 따라 다름
옮긴 작업의 분당 청구	아니요	예

서드파티 러너는 GitHub에 셀프 호스팅 러너로 등록됩니다. 그래서 셀프 호스팅 러너에 대한 GitHub의 규칙이 그대로 적용됩니다. 레이블이 작업을 라우팅하는 방식, 러너 그룹이 접근을 제한하는 방식, OIDC 토큰이 러너를 기술하는 방식, GitHub가 요금을 청구하는 방식이 모두 여기에 해당합니다.

runs-on 변경과 레이블

GitHub는 작업의 runs-on 레이블과 그룹에 일치하는 러너를 찾습니다. 일치하는 러너가 온라인이 아니면 작업은 러너가 온라인이 될 때까지 대기열에 머뭅니다. 할당된 러너가 60초 안에 작업을 가져가지 않으면 작업은 다시 대기열에 들어가고, 24시간 넘게 대기한 작업은 실패합니다 (GitHub의 셀프 호스팅 러너 레퍼런스). 레이블 오타나 리포지토리에 설치되지 않은 제공업체 앱은 시작되지 않는 작업으로 나타납니다.

제공업체는 머신을 두 가지 방식 중 하나로 지정합니다.

• 레이블에 지정. Ubicloud는 ubicloud-standard-2, Blacksmith는 blacksmith-2vcpu-ubuntu-2404, Avrea는 avrea-ubuntu-latest-2-vcpu 같은 레이블을 쓰며, ARM 머신은 레이블에 arm이 들어갑니다. 크기를 바꾸려면 레이블을 바꿔야 합니다.
• setup 단계에서 지정. CRACI는 runs-on: craci 레이블 하나만 사용하고, cracicorp/setup@v1 단계에서 크기(1 vCPU와 3 GB로 된 컴퓨팅 단위 1~32개, 기본값 2), 이미지, 네트워크 정책 또는 슬러그로 지정한 조직 러너 템플릿을 선택합니다. CRACI가 입력을 해석하지 못하면 기본 환경으로 실행하고 작업 로그에 경고를 남기며, 알 수 없는 이미지나 템플릿은 거부됩니다.

전환을 변수 하나로 만들기

레이블을 하드코딩하지 말고 리포지토리 또는 조직 변수에 두세요. 그러면 전환과 되돌리기가 모든 리포지토리에 걸친 pull request가 아니라 설정 변경 하나로 끝납니다.

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

선택은 작업별로 이루어지므로, 빌드와 테스트 작업은 옮기고 배포 작업은 남겨 둘 수 있습니다. 변수는 조직 수준에서 설정하고 리포지토리별로 재정의할 수 있으므로, 설정 하나로 여러 리포지토리를 옮기면서 특정 리포지토리는 제외할 수 있습니다.

재사용 가능한 워크플로

같은 파이프라인이 여러 리포지토리에 복사되어 있다면, 입력이나 변수에서 러너를 읽는 재사용 가능한 워크플로로 옮기세요. 그곳에서 runs-on을 바꾸면 이를 호출하는 모든 리포지토리가 바뀝니다. 룰셋으로 조직의 리포지토리에서 워크플로 실행을 강제할 수 있으므로, 공유 버전이 계속 사용됩니다.

러너 이미지: 호환성과 고정

GitHub의 호스팅 이미지에는 방대한 사전 설치 도구 모음과 호스팅 도구 캐시가 들어 있습니다. 제공업체는 GitHub와 호환되는 이미지나 더 가벼운 이미지를 제공합니다. 작업은 선언하지 않은 것에 의존하는 경우가 많습니다.

• 사전 설치된 언어 버전과 명령줄 도구
• 암호 없는 sudo, 그리고 서비스용 systemd(systemctl로 시작하는 서비스)
• Buildx와 Compose를 갖춘 실행 중인 Docker 데몬
• setup-* 액션이 다운로드 전에 읽는 호스팅 도구 캐시
• 대규모 빌드를 위한 여유 디스크 공간

판단 기준: 제공업체의 GitHub 호환 이미지로 시작하세요. 작업이 성공한 뒤에만 가벼운 이미지로 옮기고, 암묵적으로 사용하던 모든 것에 대해 명시적인 setup-* 단계를 추가하세요.

고정: ubuntu-latest는 GitHub의 일정에 따라 새 릴리스로 바뀌고, ubuntu-24.04는 운영 체제 릴리스를 고정할 뿐 그 위의 패키지 버전은 고정하지 않습니다. 중요한 것은 작업 안에서 고정하세요. setup 액션은 명시적 버전으로, 컨테이너 이미지는 다이제스트로 고정합니다. 각 제공업체에 무엇을 고정할 수 있는지 문의하세요. 러너 애플리케이션 자체는 GitHub와 통신하려면 계속 업데이트되어야 합니다.

CRACI의 이미지는 x86-64와 ARM64용 CRACI Slim(Ubuntu 24.04, systemd 없음)과 GitHub Actions 호환 전체 Ubuntu 24.04 이미지입니다. 후자는 ubuntu-24.04 또는 ubuntu-latest로 선택하며, GitHub의 Ubuntu 24.04 러너 이미지를 따르고 호스팅 도구 캐시를 포함합니다. 모든 이미지에 Docker Engine, Buildx, Compose v2가 들어 있습니다.

캐시: 이어지는 것과 비어 있는 상태로 시작하는 것

새 제공업체에서의 첫 실행은 느린 경우가 많은데, 보통 원인은 느린 머신이 아니라 비어 있는 캐시입니다. actions/cache의 작동 방식이 무엇을 보게 될지 결정합니다 (actions/cache README).

• 항목은 키와 버전으로 찾습니다. 버전은 캐시된 경로와 압축 도구의 해시입니다.
• 항목은 브랜치 범위로 나뉘며, 기본 브랜치의 항목은 다른 브랜치에서도 사용할 수 있습니다.
• 기본적으로 리포지토리는 가장 오래된 항목이 제거되기 전까지 최대 10 GB의 캐시를 보유할 수 있습니다. 리포지토리 관리자와 조직 또는 엔터프라이즈 소유자는 이 한도를 높일 수 있으며, 10 GB를 초과한 사용량은 계정에 청구됩니다(GitHub 종속성 캐싱 문서).
• Windows에서 저장한 캐시는 enableCrossOsArchive를 설정하지 않으면 다른 운영 체제에서 복원되지 않으며, 반대도 마찬가지입니다. 압축 도구가 다르면 버전도 달라집니다.

제공업체는 캐시를 두 가지 방식 중 하나로 제공합니다.

모델	첫 실행	장단점
러너가 GitHub 호스팅 러너처럼 GitHub의 캐시 서비스를 사용	기존 항목이 복원됨	캐시 트래픽이 제공업체와 GitHub 사이에서 인터넷을 가로지름
제공업체가 러너 옆의 스토리지에서 캐시 API를 제공	제공업체가 GitHub의 항목을 가져오거나 GitHub로 넘기지 않는 한, 보통 첫 실행이 채울 때까지 비어 있음	복원이 더 빠름. 그곳에 기록된 항목은 보통 GitHub 호스팅 러너에서 보이지 않음

두 번째 점은 혼합 운영과 롤백에서 중요합니다. 작업을 되돌리면 GitHub에서도 비어 있는 캐시로 시작할 수 있습니다. 제공업체가 어떤 모델을 쓰는지, 항목이 어디에 저장되는지 문의하세요.

비어 있는 캐시와 느린 러너 구분하기. 큰 node_modules 디렉터리를 캐시하는 Node 빌드를 예로 들어 보겠습니다. 새 제공업체에서의 첫 실행에서 actions/cache는 미스를 보고하고, 설치 단계는 모든 것을 다운로드하며, post 단계가 캐시를 저장합니다. 같은 브랜치의 다음 실행부터는 히트를 보고하고 설치 단계가 짧아집니다. 캐시가 채워진 뒤에만 실행을 비교하세요. cache-hit 출력을 확인하고, 복원 단계와 설치 단계의 시간을 빌드 자체와 따로 측정하세요. 키, 범위, 캐시 포이즈닝은 GitHub Actions 캐시의 작동 방식을 참조하세요.

CRACI에서 actions/cache는 지금과 똑같이 작동하며, 빌드 기록은 패키지별로 가져온 것인지 CI 캐시에서 복원된 것인지 표시합니다.

Docker 레이어 캐싱

방식	레이어 저장 위치	알아 둘 점
BuildKit type=gha	GitHub Actions 캐시	위와 같은 범위 및 크기 규칙. 이를 지원하는 빌더가 필요함
BuildKit type=registry	레지스트리의 별도 이미지	어떤 러너에서도 작동하고 제공업체를 바꿔도 유지됨. 레지스트리 스토리지와 전송 비용이 듦
제공업체 로컬 레이어 캐시 또는 영구 디스크	제공업체의 러너 옆	보통 가장 빠름. 제공업체를 떠나면 그곳에 남음

레지스트리 캐시는 이식 가능한 선택지입니다(Docker 캐시 백엔드).

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

동시에 시작한 두 작업은 같은 캐시를 복원하고, 둘 다 캐시에 없는 레이어를 빌드합니다. 이는 어떤 CI에서나 일어나는 일이므로 제공업체의 문제로 보지 마세요.

CRACI는 로컬 레이어 캐시, 원격 레이어 캐시, 바인드 마운트 캐시로 컨테이너 레이어 캐싱을 제공합니다.

시크릿, OIDC, 클라우드 자격 증명

GitHub는 시크릿을 저장하고, 작업을 실행하는 러너에 전달합니다. 작업을 제공업체로 옮긴다는 것은 그 작업의 시크릿을 제공업체에 맡긴다는 뜻입니다. 다음을 문의하세요.

• 작업마다 전용 가상 머신이 주어집니까, 아니면 공유 호스트의 컨테이너입니까?
• 작업 후 머신이 폐기됩니까? 남는 것이 있습니까?
• 제공업체는 어떤 로그를 보관합니까? GitHub는 등록된 시크릿을 작업 로그에서 마스킹하지만, 변환된 값의 자동 가림은 보장되지 않는다고 밝힙니다. 제공업체 자체의 시스템 로그도 문의하세요.

OIDC는 계속 작동하지만, 주의할 점이 하나 있습니다. OIDC 토큰은 러너가 아니라 GitHub가 발급하므로 permissions: id-token: write는 어떤 러너에서도 작동합니다. 하지만 토큰의 runner_environment 클레임은 github-hosted 또는 self-hosted이며 (GitHub의 OIDC 레퍼런스), 서드파티 러너에서는 self-hosted입니다. github-hosted를 요구하는 클라우드 신뢰 정책은 작업을 거부합니다. 예를 들어 다음 속성 조건을 가진 Google Cloud 워크로드 아이덴티티 풀이 그렇습니다.

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

러너 검사를 제거하면 자격 증명을 얻을 수 있는 대상이 넓어지므로, 동시에 다른 조건을 강화하세요. 전환 전에 모든 클라우드 신뢰 정책과 워크로드 아이덴티티 구성에서 runner_environment를 검색하세요.

이미지 푸시: GITHUB_TOKEN에 packages: write 권한이 있으면 어떤 러너에서도 GitHub Container Registry로 푸시할 수 있으며, 저장된 시크릿을 사용하는 레지스트리 로그인도 그대로 작동합니다.

CRACI에서는 GitHub App이 코드와 Actions 실행을 읽고, 조직에 등록한 러너를 관리합니다. 각 작업은 격리된 전용 가상 머신에서 실행되며, CRACI는 소스 코드를 저장하지 않습니다.

네트워크 아이덴티티: IP 허용 목록과 이그레스

새 러너는 새 IP 주소에서 나갑니다. 출발지 주소로 필터링하는 모든 것을 목록으로 만드세요.

• 데이터베이스와 아티팩트 리포지토리의 허용 목록
• IP 제한이 있는 SaaS API
• 파트너 SFTP 서버와 방화벽 뒤의 내부 서비스

선택지는 제공업체의 고정 또는 안정적인 이그레스 IP 주소, 또는 직접 통제하는 프록시입니다. 지금이 작업이 애초에 어디에 접근할 수 있는지 정할 때이기도 합니다. 러너의 이그레스 정책은 손상된 의존성이 빌드에 필요 없던 호스트로 시크릿을 보내는 것을 막습니다. GitHub Actions 이그레스 정책을 참조하세요.

CRACI는 안정적인 이그레스 IP 범위와 이그레스 정책(기본 거부 또는 허용)을 제공하며, 정책은 작업 시작 전에 검증되고 실패 시 차단됩니다. network 입력이 없으면 기본 템플릿이 다른 아웃바운드 연결을 허용하므로, 이그레스 통제는 직접 구성해야 합니다.

혼합 운영: Linux는 옮기고 macOS와 iOS는 그대로

러너는 작업별로 선택되므로, 하나의 워크플로에서 Linux 작업은 제공업체에서, macOS 작업은 GitHub 호스팅 러너에서 실행할 수 있습니다. actions/upload-artifact로 업로드한 아티팩트는 GitHub가 저장하므로, 한 러너의 작업이 다른 러너의 작업에 파일을 넘길 수 있습니다.

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

GitHub에 남은 작업은 계속 요금제의 포함 사용량을 소진하고, 이를 넘으면 GitHub가 청구합니다. CRACI는 현재 x86-64와 ARM64에서 Linux를 실행하며 Windows와 macOS는 로드맵에 있으므로, CRACI를 쓰는 혼합 운영은 Linux에는 CRACI, 나머지에는 GitHub 호스팅 러너를 의미합니다.

제공업체가 다운되었을 때의 폴백

GitHub에는 러너 레이블 간의 기본 폴백이 없습니다. 레이블에 맞는 러너가 온라인이 아니면 작업은 대기하다가 24시간 후 실패합니다. 다음과 같이 대비하세요.

• 위의 변수 전환: 변수를 ubuntu-latest로 되돌리면 새 실행은 GitHub 호스팅 러너로 갑니다.
• 수동 재정의: 긴급 실행을 위해 workflow_dispatch 입력을 두고 runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}로 읽습니다.
• timeout-minutes: 작업에 설정해 멈춘 작업이 배포를 몇 시간씩 붙잡지 않게 합니다.
• 대기 시간 모니터링: 작업이 평소보다 오래 기다릴 때 알아차릴 수 있게 합니다.

각 제공업체에 자동 폴백이 있는지, 무엇이 그것을 작동시키는지 문의하세요. 반대 방향도 대비하세요. GitHub가 모든 작업의 대기열과 할당을 맡으므로, GitHub Actions 장애는 모든 러너 제공업체의 작업도 멈춥니다.

청구: GitHub가 여전히 요금을 청구합니까?

GitHub는 셀프 호스팅 러너에 분당 요금을 부과하지 않으며, 서드파티 러너는 셀프 호스팅으로 등록되므로 옮긴 사용 시간은 GitHub 청구서에서 사라집니다 (GitHub Actions 청구). GitHub는 여전히 다음을 청구합니다.

• 요금제의 시트
• 포함 한도를 넘어 보관하는 아티팩트와 캐시 스토리지
• GitHub 호스팅 러너에 남은 작업 중 요금제 포함 사용량을 넘는 부분(환불되지 않음)

시범 운영 기간에는 청구서를 두 개 받습니다. 제공업체마다 빌드 시간을 세는 방식이 다릅니다. GitHub는 작업마다 분 단위로 올림하고, 일부 제공업체는 초 단위로 측정합니다. 전환 전후의 사용량을 가늠하려면 GitHub Actions 비용 계산기를 사용하세요. CRACI는 빌드 시간에만 요금을 청구합니다. vCPU 분당 $0.002(기본 2 vCPU 러너는 $0.004)이며, 초 단위로 측정하고 월 요금은 없습니다.

보안 격리: 어떤 제공업체에든 물어볼 것

질문	중요한 이유
작업마다 가상 머신 하나입니까, 아니면 공유 호스트의 컨테이너입니까?	공유 호스트에서는 손상된 작업이 이웃 작업에 닿을 수 있음
작업 후 머신이 폐기됩니까?	유지되는 머신은 파일, 자격 증명, 프로세스를 다음 작업으로 넘김
하드웨어는 어디에 있고 누가 운영합니까?	데이터 위치, 관할권, 고객과의 계약
제공업체는 무엇을 얼마 동안 저장합니까?	로그, 캐시, 네트워크 데이터에 민감한 정보가 담길 수 있음
어떤 인증을 보유하고 있습니까?	공급업체 검토에서 반드시 묻는 항목
이그레스를 통제할 수 있습니까?	악성 패키지를 통해 시크릿이 유출되는 것을 막음
GitHub App은 무엇을 읽고 바꿀 수 있습니까?	앱의 권한은 설치한 모든 리포지토리에 적용됨

GitHub는 누구나 pull request를 열어 환경을 손상시킬 수 있으므로 공개 리포지토리에는 셀프 호스팅 러너를 거의 사용하지 말아야 하며, just-in-time 러너는 제거되기 전까지 최대 한 개의 작업만 실행한다고 설명합니다 (GitHub의 보안 사용 레퍼런스). 작업마다 새 가상 머신을 쓰면 이 우려의 대부분이 해소됩니다.

CRACI의 답변: 각 작업은 유럽 베어메탈 인프라의 격리된 전용 가상 머신에서 실행됩니다. CRACI 플랫폼의 개발 및 운영에 대한 CRACI Corporation Oy의 정보 보안 관리 시스템은 Into Certification으로부터 ISO/IEC 27001 인증을 받았으며, 자세한 내용은 Trust Center에 있습니다. CRACI는 빌드 메타데이터, 패키지 데이터, 네트워크 추적, SBOM, 출처 증명, 캐시, 감사 기록을 저장하며, 소스 코드는 절대 저장하지 않습니다. CRACI가 접근할 수 있는 범위와 보안을 참조하세요.

먼저 리포지토리 하나로 시험해 보기

1. 릴리스 파이프라인이 아니라, 대표적이고 자주 실행되는 Linux 워크플로가 있는 리포지토리를 고르세요.
2. GitHub 호스팅 러너에서 기준선을 기록하세요. 최근 30회 실행의 소요 시간 중앙값, 대기 시간 중앙값, 청구된 사용 시간입니다.
3. 제공업체의 GitHub App을 그 리포지토리에만 설치하세요.
4. 브랜치에서 리포지토리 변수를 통해 작업 하나를 전환하세요.
5. 최소 열 번 실행하고, 처음 세 번은 캐시 준비로 보고 제외하세요.
6. 소요 시간, 대기 시간, 캐시 적중률, 실패, 비용을 비교하고, 로그, OIDC, 아웃바운드 호출을 확인하세요.
7. 변수를 바꿔 롤백하고, 작업이 GitHub 호스팅 러너로 돌아오는지 확인하세요.

지표	GitHub 호스팅 기준선	제공업체	통과 기준
작업 소요 시간 중앙값			목표치, 예: 30% 단축
대기 시간 중앙값			기준선보다 나쁘지 않음
캐시 준비 후 캐시 적중률			기준선과 같음
코드와 무관한 실패 실행			없음
실행당 비용			기준선보다 낮음
OIDC, 허용 목록, 아웃바운드 호출			모두 작동

속도는 자신의 워크플로에서 측정하세요. 모든 제공업체가 자체 수치를 발표하지만, 여러분의 경우를 결정하는 숫자는 여러분의 파이프라인에서 나온 것뿐입니다.

CRACI가 맞는 경우

CRACI는 GitHub Actions 러너입니다. GitHub Actions가 아니라 러너를 대체합니다. 작업은 runs-on: craci로 옮기고, 크기와 이미지는 cracicorp/setup@v1 또는 조직 러너 템플릿으로 설정하며, 실행은 계속 GitHub에 표시됩니다. 더 빠른 하드웨어, 더 짧은 대기 시간, 캐싱 덕분에 CRACI는 GitHub 호스팅 러너보다 빌드를 약 2배 빠르게 실행합니다.

다른 제공업체 대신 CRACI를 선택할 이유는 각 작업이 남기는 것입니다. 빌드가 가져온 것의 SBOM이 완전성 상태와 함께, 실패 시 차단되는 이그레스 정책 아래에서 기록됩니다. docs.craci.com은 워크플로에 대한 작업별 마이그레이션 계획을 제안하는 코딩 에이전트용 프롬프트도 제공합니다. CI/CD 통합을 참조하세요.

CRACI가 답이 아닌 경우

• macOS 또는 Windows 러너가 필요한 경우: CRACI의 로드맵에 있습니다.
• GitHub Enterprise Server를 사용하는 경우: CRACI는 지원하지 않습니다.
• CI가 GitLab CI 또는 Jenkins인 경우: 둘 다 로드맵에 있습니다.
• 러너가 자체 클라우드 계정에 있어야 하는 경우: 고객 호스팅 러너는 로드맵에 있습니다. RunsOn과 WarpBuild의 bring-your-own-cloud 옵션은 현재 이를 제공합니다. CRACI vs RunsOn과 CRACI vs WarpBuild를 참조하세요.
• 주된 목표가 CI 관측성과 디버깅인 경우: CRACI vs Avrea를 참조하세요. 러너를 직접 운영하려면 관리형 러너와 셀프 호스팅 러너 비교를 참조하세요.

러너 제공업체 전환: 자주 묻는 질문

다른 GitHub Actions 러너 제공업체를 사용하려면 무엇을 바꿔야 합니까?

제공업체의 GitHub App을 설치한 다음, 작업의 runs-on 레이블을 제공업체의 레이블로 바꿉니다. 워크플로, 트리거, 시크릿, GitHub UI는 그대로입니다. 중요한 작업을 옮기기 전에 러너 이미지, 캐시, 아웃바운드 IP 주소, OIDC를 사용하는 클라우드 신뢰 정책, 폴백, 청구를 확인하세요.

GitHub Actions 캐시는 새 러너 제공업체로 그대로 이어집니까?

제공업체가 캐시를 어디에서 제공하는지에 따라 다릅니다. 러너가 GitHub의 캐시 서비스를 사용하면 기존 항목이 복원됩니다. 러너 옆의 스토리지에서 캐시 API를 제공하면, 캐시는 보통 비어 있는 상태로 시작해 처음 몇 번의 실행에서 채워집니다. 제공업체가 어떤 방식을 쓰는지, 그리고 자사 러너에서 기록된 항목이 GitHub 호스팅 러너에서도 보이는지 문의하세요.

서드파티 러너에서도 Docker 레이어 캐싱이 작동합니까?

예, 세 가지 방식 중 어느 것으로든 작동합니다. Actions 캐시를 사용하는 BuildKit의 type=gha 백엔드, 어떤 러너에서도 작동하는 type=registry 레지스트리 캐시, 또는 제공업체가 러너 옆에 유지하는 레이어 캐시나 영구 디스크입니다.

Linux 작업을 옮기면서 macOS와 iOS 빌드는 GitHub에 남겨 둘 수 있습니까?

예. 러너는 작업별로 선택되므로, 같은 워크플로에서 Linux 작업은 제공업체에서 실행하고 macOS 작업은 GitHub 호스팅 러너에 남겨 둘 수 있습니다. needs:로 작업을 연결하고, GitHub가 저장하는 actions/upload-artifact와 actions/download-artifact로 파일을 넘기세요.

서드파티 러너가 다운되면 작업은 어떻게 됩니까? 폴백이 있습니까?

GitHub에는 러너 레이블 간의 기본 폴백이 없습니다. 레이블과 일치하는 온라인 러너가 없는 작업은 대기열에 머물다가 24시간 후 실패합니다. 레이블을 리포지토리 또는 조직 변수에 두어 한 번의 변경으로 되돌릴 수 있게 하고, timeout-minutes를 설정하고, 각 제공업체에 자체 폴백이 있는지 문의하세요.

서드파티 러너에서도 시크릿과 OIDC가 작동합니까?

예. GitHub가 시크릿을 저장해 작업 시작 시 러너에 전달하고, OIDC 토큰도 GitHub가 발급하므로 id-token: write는 어떤 러너에서도 작동합니다. 주의할 점은 서드파티 러너에서는 토큰의 runner_environment 클레임이 self-hosted이므로, github-hosted를 요구하는 클라우드 신뢰 정책은 작업을 거부한다는 것입니다.

다른 러너 제공업체를 사용해도 GitHub가 분 단위 요금을 청구합니까?

옮긴 작업에는 청구하지 않습니다. 서드파티 러너는 GitHub에 셀프 호스팅 러너로 등록되며, GitHub는 셀프 호스팅 러너에 분당 요금이 없다고 명시합니다. GitHub는 여전히 시트, 포함 한도를 넘는 스토리지, GitHub 호스팅 러너에 남은 작업에 요금을 청구합니다. 제공업체는 자체 사용 시간을 청구합니다.

러너 이미지가 모르는 사이에 바뀌지 않도록 고정하려면 어떻게 합니까?

ubuntu-latest는 GitHub의 일정에 따라 바뀌고, ubuntu-24.04는 운영 체제 릴리스는 고정하지만 그 위의 패키지 버전은 고정하지 않습니다. 중요한 것은 작업 안에서 고정하세요. setup 액션은 명시적 버전으로, 컨테이너 이미지는 다이제스트로 고정합니다. 각 제공업체에 무엇을 고정할 수 있는지 문의하세요. 러너 애플리케이션 자체는 GitHub와 계속 작동하려면 업데이트되어야 합니다.

서드파티 러너에서 작업은 서로 어떻게 격리됩니까?

제공업체마다 다릅니다. 작업마다 전용 가상 머신이 주어지는지 아니면 공유 호스트의 컨테이너인지, 작업 후 머신이 폐기되는지, 제공업체가 이후 무엇을 보관하는지 문의하세요. 작업마다 새 가상 머신을 쓰는 방식이 일반적인 모델 중 가장 강력합니다. 한 작업의 흔적이 다음 작업에 남지 않기 때문입니다.

러너 제공업체를 먼저 리포지토리 하나에서 테스트하려면 어떻게 합니까?

제공업체의 GitHub App을 리포지토리 하나에 설치하고, 브랜치에서 리포지토리 변수를 통해 자주 실행되는 Linux 작업 하나를 전환한 뒤, 최소 열 번 실행해 소요 시간, 대기 시간, 캐시 적중, 실패, 비용을 GitHub 호스팅 기준선과 비교하세요. 롤백은 변수를 바꾸면 됩니다.