자체 호스팅 실행기에서 GitHub 호스팅 실행기로 마이그레이션

GitHub호스팅 러너 또는 자체 호스팅 러너에서 워크플로를 실행하거나, 여러 러너 유형을 혼합하여 사용할 수 있습니다.

이 자습서에서는 현재 실행기 사용 현황을 평가한 다음, 워크플로를 자체 호스팅 실행기에서 GitHub호스팅 실행기로 효율적으로 마이그레이션하는 방법을 보여 줍니다.

1. 현재 CI 인프라 평가

자체 호스팅 실행기에서 GitHub호스팅 대형 실행기로 마이그레이션하려면 현재 CI 인프라를 철저히 평가하는 것부터 시작해야 합니다. 사양 및 환경을 신중하게 일치시키는 데 시간이 걸리는 경우 다른 실행기에서 워크플로 실행을 시작할 때 문제를 해결하는 데 소요된 시간을 최소화할 수 있습니다.

CPU 코어, RAM, 스토리지, 칩 아키텍처 및 운영 체제를 포함하여 워크플로를 실행하는 데 사용되는 각 컴퓨터 사양의 인벤토리를 만듭니다.
실행기 중 일부가 특정 실행기 그룹에 속하는지, 아니면 레이블이 있는지 확인해야 합니다. 이 정보를 사용하여 워크플로를 새 실행기로 마이그레이션하는 작업을 간소화할 수 있습니다.
마이그레이션 전략에 영향을 주기 때문에 워크플로가 사용하는 사용자 지정 이미지 및 미리 설치된 종속성을 문서화합니다.
현재 자체 호스팅 실행기를 대상으로 하는 워크플로를 파악하고 그 이유를 설명합니다. 예를 들어 GitHub Actions 사용 메트릭에서는 작업 탭을 사용하고, 실행기 레이블(self-hosted 또는 사용자 지정 레이블 등)로 필터링하여 해당 레이블을 사용하는 리포지토리와 작업을 확인합니다. 특정 워크플로 파일의 유효성을 검사해야 하는 경우 코드 검색을 사용하여 참조 runs-on: self-hosted 하는 워크플로 파일 또는 기타 자체 호스팅 레이블을 찾을 수도 있습니다.
프라이빗 네트워크 리소스(예: 내부 패키지 레지스트리, 프라이빗 API, 데이터베이스 또는 온-프레미스 서비스)에 액세스하는 워크플로를 식별합니다. 추가 네트워킹 구성이 필요할 수 있으므로

2. 처리 요구 사항을 GitHub-호스팅된 실행기 유형에 맞게 매핑합니다

GitHub는 여러 운영 체제(Linux, Windows 및 macOS)에서 관리되는 실행기를 제공하며 GPU 사용 컴퓨터에 대한 옵션을 제공합니다. 대형 실행기 참조을(를) 참조하세요.

인벤토리의 각 고유 머신 사양을 적합한 GitHub호스티드 러너 사양에 매핑합니다.
적합한 GitHub-호스팅 러너가 없는 자체 호스팅 러너는 메모해 두세요.
자체 호스팅 실행기에서 계속 실행해야 하는 워크플로는 마이그레이션 계획에서 제외합니다.

3. 용량 요구 사항 예측

GitHub호스팅 러너를 프로비저닝하기 전에 워크플로에 얼마나 많은 컴퓨팅 용량이 필요한지 추정하세요. 현재 자체 호스팅 실행기 사용을 검토하면 적절한 실행기 크기를 선택하고, 동시성 제한을 설정하고, 잠재적인 비용 변경을 예측하는 데 도움이 됩니다.

GitHub의 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음, Your organizations를 클릭합니다.
조직 이름을 클릭합니다.
조직 이름에서 인사이트를 클릭합니다.
"인사이트" 탐색 메뉴에서 작업 사용 메트릭을 클릭합니다.
확인하고자 하는 메트릭이 있는 탭을 클릭하세요. GitHub Actions 측정 항목 정보을(를) 참조하세요.
호스트된 실행기 용량을 예측하려면 다음 데이터 요소를 검토합니다.
- 총 소요 시간(분): 기준 컴퓨팅 수요를 예측하는 데 도움이 됩니다.
- 워크플로 실행 수: 동시성이 더 필요할 수 있는 최대 작업 시간을 식별합니다.
- OS 유형 간 작업 배포: Linux, Windows 및 macOS 실행기의 적절한 조합을 프로비전합니다.
- 실행기 레이블(작업 탭): 실행기 레이블별로 필터링하여 레이블이 사용되는 위치를 파악합니다.
결과를 용량 계획으로 변환합니다.
- 사용량이 많은 워크플로를 적절할 때 더 큰 실행기 크기에 맞춰 조정하세요.
- 런타임을 줄이기 위해 미리 빌드된 이미지 또는 사용자 지정 이미지의 이점을 얻을 수 있는 워크플로를 식별합니다.
- 일반적으로 동시에 실행되는 작업 수를 결정하여 동시성을 예측합니다.
간격을 기록해 둡니다.
- 현재 호스팅된 실행기 이미지가 지원하지 않는 엄격한 종속성이 있는 워크플로.
- 비정상적으로 긴 런타임 또는 맞춤형 환경이 필요한 작업 (이에 대한 사용자 지정 이미지가 필요할 수 있습니다.)

용량 계획은 프로비전할 실행기 수, 사용할 머신 유형 및 다음 단계에서 실행기 그룹 및 정책을 구성하는 방법을 안내합니다.

러너 그룹 및 정책 설정

용량 요구 사항을 예측한 후 올바른 조직 및 워크플로에서 호스팅된 실행기를 사용할 수 있도록 GitHub실행기 그룹 및 액세스 정책을 구성합니다.

실행기를 프로비전하기 전에 실행기 그룹을 구성하면 마이그레이션이 실수로 액세스를 너무 광범위하게 열거나 예기치 않은 비용 증가를 일으키지 않도록 하는 데 도움이 됩니다.

엔터프라이즈 수준에서 실행기 그룹을 만들어 호스트된 실행기를 사용할 수 있는 사용자를 정의합니다. 더 큰 실행기 액세스 제어을(를) 참조하세요.

실행기 그룹을 사용하여 조직, 리포지토리 또는 워크플로별로 액세스 범위를 지정합니다. 자체 호스팅 실행기를 마이그레이션하는 경우, 가능하다면 기존 실행기 그룹 이름 또는 레이블을 재사용하는 것을 고려해 보세요. 이렇게 하면 GitHub호스팅 실행기로 전환해도 워크플로가 변경 없이도 계속 작동할 수 있습니다.
적절한 그룹에 호스트된 새 GitHub실행기를 추가하고 3단계에서 식별한 사용 패턴에 따라 동시성 제한을 설정합니다. 자동 크기 조정에 대한 자세한 내용은 대형 런너 관리하기을 참조하세요.
정책 설정을 검토하여 실행기가 의도된 워크플로에서만 사용되는지 확인합니다. 예를 들어 특정 리포지토리로 사용을 제한하거나 신뢰할 수 없는 워크플로가 더 강력한 컴퓨터 유형에 액세스하지 못하도록 방지합니다.

5. GitHub호스팅된 실행기 설정

다음으로, 이전에 파악한 머신 유형과 용량을 기준으로 GitHub호스팅된 실행기를 프로비저닝합니다.

워크플로 요구 사항과 일치하는 컴퓨터 크기 및 운영 체제를 선택합니다. 사용 가능한 이미지 및 사양은 대형 실행기 참조을 참조하세요.
실행기 그룹에 각 실행기를 할당하고 동시성 제한을 구성하여 동시에 실행할 수 있는 작업 수를 제어합니다.
이미지 유형을 선택합니다.
- 유지 관리되고 자주 업데이트되는 환경을 위해 GitHub 관리 이미지를 사용하세요.
- 설치 시간을 줄이기 위해 미리 설치된 종속성이 필요한 경우 사용자 지정 이미지를 사용합니다. 사용자 지정 이미지 사용을(를) 참조하세요.
환경 변수, 소프트웨어 설치 또는 시작 스크립트와 같은 필수 사용자 지정을 적용합니다. 자세한 예제는 GitHub 호스팅 실행기 사용자 지정을 참조하세요.
필요에 따라 실행기가 내부 리소스에 액세스해야 하는 경우 프라이빗 네트워킹을 구성합니다. GitHub에서 호스팅하는 러너를 사용하여 비공개 네트워킹을(를) 참조하세요.

프라이빗 연결 옵션 구성

워크플로가 프라이빗 리소스(예: 내부 패키지 레지스트리, 프라이빗 API, 데이터베이스 또는 온-프레미스 서비스)에 액세스해야 하는 경우 네트워크 및 보안 요구 사항에 맞는 접근 방식을 선택합니다.

Azure 프라이빗 네트워킹 구성

내부 리소스에 대한 보안 액세스를 위해 VNET(Azure Virtual Network) 내에서 호스팅된 실행기를 실행GitHub합니다.

Azure Virtual Network(VNET)를 만들고, 실행기에 필요한 서브넷과 네트워크 보안 그룹을 설정합니다.
실행기 그룹에서 Azure Private Networking을 사용하도록 설정합니다. GitHub에서 호스팅되는 러너를 위한 엔터프라이즈 내 프라이빗 네트워킹 구성을(를) 참조하세요.
NSG 및 방화벽 규칙과 같은 네트워크 구성을 적용하여 수신 및 송신 트래픽을 제어합니다.
프라이빗 네트워킹에 대해 구성된 실행기 그룹을 사용하도록 워크플로 대상을 업데이트합니다.

자세한 지침은 다음을 참조하세요.

WireGuard 오버레이 네트워크를 사용하여 연결

Azure 프라이빗 네트워킹을 적용할 수 없는 경우(예: 대상 네트워크가 온-프레미스 또는 다른 클라우드에 있기 때문에) WireGuard와 같은 VPN 오버레이를 사용하여 프라이빗 리소스에 대한 네트워크 수준 액세스를 제공할 수 있습니다.

자세한 지침 및 예제는 WireGuard를 사용하여 네트워크 오버레이 만들기을 참조하세요.

프라이빗 리소스에 대한 신뢰할 수 있는 액세스를 위해 API 게이트웨이와 함께 OIDC 사용

실행기를 사용하여 프라이빗 네트워크에 조인할 필요가 없는 경우 OIDC를 사용하여 API 게이트웨이를 통해 노출하는 서비스에 대한 신뢰할 수 있는 단기 액세스를 설정할 수 있습니다. 이 방법은 수명이 긴 비밀에 대한 필요성을 줄이고 워크플로에 필요한 특정 엔드포인트에 대한 네트워크 액세스를 제한할 수 있습니다.

자세한 지침 및 예제는 OIDC와 함께 API 게이트웨이 사용을 참조하세요.

6. 새로운 실행기를 사용하도록 워크플로를 업데이트하십시오.

GitHub에서 호스팅되는 실행기가 구성되면 워크플로 파일을 업데이트하여 해당 실행기를 대상으로 하도록 설정합니다.

자체 호스팅 실행기에서 사용한 것과 동일한 실행기 그룹 이름으로 새 실행기를 할당하면 기존 레이블이 다시 사용됩니다. 이 경우 워크플로는 변경 없이 새 실행기를 자동으로 사용합니다.

새로운 실행기 그룹 또는 레이블을 생성한 경우, 워크플로 YAML 파일에서 runs-on 필드를 업데이트하십시오. 다음은 그 예입니다.

jobs:
  build:
    runs-on: [github-larger-runner, linux-x64]
    steps:
      - name: Checkout code
        uses: actions/checkout@v6
      - name: Build project
        run: make build

자체 호스팅 레이블(예: self-hosted``linux-x64사용자 지정 레이블)에 대한 하드 코딩된 참조를 확인하고 적절한 GitHub호스팅된 실행기 레이블로 바꿉니다.
업데이트된 각 워크플로를 테스트하여 새 실행기에서 올바르게 실행되는지 확인합니다. 환경 차이 또는 누락된 종속성과 관련된 문제를 모니터링합니다.

7. 사용되지 않는 자체 호스팅 러너 제거

워크플로가 업데이트되고 GitHub호스팅 실행기에서 테스트된 후에는 더 이상 필요하지 않은 자체 호스팅 실행기를 제거하세요. 이는 작업이 오래된 인프라를 실수로 대상으로 지정하지 않도록 방지합니다. 자체 호스트형 실행기 제거을(를) 참조하세요.

자체 호스팅 실행기를 제거하기 전에 모든 항목이 완전히 마이그레이션되었는지 확인하세요.

GitHub Actions 사용 메트릭에서 Jobs 탭을 사용하고 러너 레이블(예: self-hosted 또는 사용자 지정 레이블)로 필터링하여 자체 호스팅 러너를 여전히 사용하는 리포지토리나 작업이 없는지 확인합니다.

자체 호스팅 실행기에서 GitHub 호스팅 실행기로 마이그레이션

이 기사에서