5. Github Action (With Using jobs in a workflow & Choosing the runner for a job)

Overview

Github Action의 워크플로에서 작업 사용 및 작업에 대한 러너 선택에 대해서 알아본다.

• Using jobs in a workflow
• Choosing the runner for a job

 

2023.05.19 - [IaC/CI CD Tool] - 1. Github Action이란?

1. Github Action이란?

2023.05.22 - [IaC/CI CD Tool] - 2. Github Action (With Syntax)

2. Github Action 주요 문법(Syntax)

2023.05.23 - [IaC/CI CD Tool] - 3. Github Action (With Automate Pull Request)

3. Github Action Pull Request 자동화

2024.03.12 - [IaC/CI CD Tool] - 4. Github Action (With Matrix Strategy)

4. Github Action (With Matrix Strategy)

 

GitHub Actions에서 워크플로는 통합부터 배포까지 소프트웨어 개발 프로세스를 자동화한다. 이러한 워크플로의 중요한 측면은 정의된 종속성을 사용하여 병렬 또는 순차적으로 실행할 수 있는 여러 작업을 실행할 수 있는 기능이다. 워크플로에서 작업을 사용하는 방법을 살펴보고 GitHub 호스팅 및 자체 호스팅 Runner를 모두 포함하여 각 작업에 적합한 Runner를 선택하는 방법을 자세히 살펴보려고 한다.

​

mindmap
    root((Using jobs in a workflow and Choosing the runner for a job))
        jobExecution[Job Execution in a Workflow]
            taskId[Set Task ID]
            taskName[Set Task Name]
            essentialTasks[Define Essential Tasks]
                gcp[GCP]
                aws[AWS]
            workflowExecution[Workflow Execution and Job Dependencies]
                seqExecution[Standard Use Case: Sequential Job Execution]
                parCondExecution[Advanced Use Case: Parallel and Conditional Execution]
                
        choosingRunner[Choosing the Runner for a Job]
            githubHosted[Choosing GitHub-hosted runners]
            selfHosted[Choosing self-hosted runners]
            runnerGroups[Choosing runners in a group]
                groupControl[Example: Using groups to control where jobs are run]
                groupLabelComb[Example: Combining groups and labels]
                prefixDiff[Example: Using prefixes to differentiate runner groups]

 

 

 

---

Using jobs in a workflow

 

---

 

1. Set Task ID

워크플로 내의 각 작업에 고유 식별자를 할당합니다. 이 ID는 워크플로 파일 내에서 작업 참조를 용이하게 한다.

jobs:
  build and push:
	  # Job definition goes here
	deploy to kubernetes:
		# Job definition goes here

 

 

---

 

2. Set Task Name

각 작업에 name 키워드를 사용하여 각 작업에 대한 명확한 이름을 부여한다.

jobs:
  build-and-push:
    name: Build And Push
    # Job definition goes here
  deploy-to-kubernetes:
    name: Deploy to Kubernetes
    # Job definition goes here

• 각 작업에 대해 `name` 을 명시적으로 지정하지 않고 GitHub Actions 워크플로에서 작업을 정의하면 GitHub Actions는 작업 ID(워크플로 YAML에서 정의한 키)를 GitHub Actions UI에서 해당 작업의 기본 이름으로 사용한다.
• 따라서 예시에서는 각 작업에 대해 `name` 필드를 설정하지 않으면 작업 ID `build and push` 및 `deploy to kubernetes` 가 이름으로 사용된다.

 

---

 

3. Define Essential Tasks

작업은 기본적으로 체크아웃, 환경 설정, 명령 실행 등 특정 작업을 수행하는 단계로 구성된다.

steps:
  - uses: actions/checkout@v
  - name: Set up Node.js
    uses: actions/setup-node@v2
    with:
      node-version: '14'
  - name: Install dependencies
    run: npm install
  - name: Run tests
    run: npm test

 

Cloud를 사용한다면 아래와 같이 구성할수도 있다.

 

GCP

steps:
  - uses: actions/checkout@v4
  
  - name: Configure GCP credentials
    id: auth         
    uses: google-github-actions/auth@v2
    with:
      token_format: access_token
      workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
      service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
      access_token_lifetime: 500s
 
  - name: Set up Cloud SDK
    uses: google-github-actions/setup-gcloud@v2

• Checkout Repository
  • `actions/checkout@v4 action` 을 사용하여 저장소의 코드를 GitHub Actions runner에 checkout 한다.

 

• Configure GCP Credentials
  • 이 단계에서는 `google-github-actions/auth@v4` 작업을 사용하여 저장소의 비밀번호에 지정된 사용자 인증 정보 세트를 사용하여 Google Cloud Platform에 대해 인증한다.
  • token_format: access_token은 GCP 인증을 위해 액세스 토큰이 생성되어야 함을 지정한다.
  • workload_identity_provider 및 service_account는 GitHub 비밀에서 가져오고 GCP를 안전하게 인증하는 데 사용된다.
  • access_token_lifetime: 500s는 생성된 액세스 토큰이 유효한 기간을 설정한다.

 

• Set up Cloud SDK
  • 마지막 단계에서는 `google-github-actions/setup-gcloud@v4` 를 사용하여 GitHub Actions Runner에 Google Cloud SDK를 설치하고 구성한다.
  • 이 설정을 사용하면 워크플로가 GCP 서비스와 상호작용하여 애플리케이션 배포, 클라우드 리소스 관리 등과 같은 명령을 실행할 수 있다.

 

AWS

steps:
  - name: Check out branch for workflow call
    id: checkout-for-workflow-call
    if: ${{ inputs.branch }}
    uses: actions/checkout@v4
    with:
      ref: ${{ inputs.branch }}

  - name: Check out branch for workflow dispatch
    if: ${{ steps.checkout-for-workflow-call.outcome == 'skipped' }}
    uses: actions/checkout@v4

  - name: Set AWS region JP for prod environment
    if: ${{ inputs.environment == 'stage' || inputs.environment == 'prod' }}
    id: set-prod-region
    run: |
      echo "environment : ${{ inputs.environment }}"
      echo "AWS_REGION=ap-northeast-1" >> $GITHUB_ENV

• Check out branch for workflow call
  • 워크플로에 branch 입력이 제공되면 특정 분기를 확인한다.
  • inputs.branch에 지정된 분기로 설정된 ref 매개변수와 함께 `actions/checkout@v4` 작업을 사용한다.
  • 이 단계는 inputs.branch가 제공되는 경우에만 실행된다(`if: ${{ inputs.branch }}`)
  • 이 단계는 (checkout-for-workflow-call)에는 id가 할당되어 후속 단계에서 해당 결과를 참조할 수 있다.

 

• Check out branch for workflow dispatch
  • ref를 지정하지 않고 동일한 `actions/checkout@v4` 를 사용하여 폴백 체크아웃 액션을 실행하여 기본 브랜치를 효과적으로 체크아웃한다.
  • 이 단계는 이전 체크아웃 단계를 건너뛴 경우에만 실행된다(`if: ${{ steps.checkout-for-workflow-call.outcome == 'skipped' }}`)

 

• Set AWS region JP for prod environment
  • 조건부 논리를 사용하여 inputs.environment 값을 확인하고 stage 또는 prod와 일치하는 경우에만 실행된다.
  • echo `"AWS_REGION=ap-northeast-1" >> $GITHUB_ENV` 명령은 AWS Region 설정을 GitHub Actions 환경 변수 파일에 추가하여 후속 단계 및 작업에서 AWS_REGION을 사용할 수 있도록 한다.
  • 이 단계의 id는 set-prod-region이며, 로깅 또는 디버깅 목적으로 현재 environment를 출력한다.

 

---

 

 

4. Workflow Execution and Job Dependencies

needs 키워드를 사용하면 워크플로우에서 작업 간 종속성을 지정할 수 있다.

다른 작업을 시작하기 전에 성공적으로 완료해야 하는 작업을 정의할 수 있다. 이 기능은 작업 시퀀스를 관리하는 데 중요하며, 특히 작업이 이전 작업의 출력 또는 성공 여부에 따라 달라질 때 매우 중요하다.

 

Standard Use Case: Sequential Job Execution

빌드, 테스트 및 배포의 세 가지 작업이 있는 시나리오를 예시로 든다.

• `test` runs only after `build` completes successfully.
• `deploy` runs only after `test` completes successfully.

name: CI Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: echo "Building the project..."

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Test project
        run: echo "Testing the project..."

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy project
        run: echo "Deploying the project..."

• Job `build`: 첫번째로 실행되는 작업이다. 간단한 에코 명령을 사용하여 프로젝트를 구축하는 것을 시뮬레이션한다. 지정된 종속성(요구)이 없으므로 워크플로우가 트리거되면 바로 시작된다.
• Job `test`: 이 작업은 빌드 작업에 종속성을 가지며, `needs: build` 로 지정된다. 이는 테스트가 빌드가 성공적으로 완료될 때까지 기다렸다가 시작한다는 것을 의미한다. 빌드가 실패하면 테스트가 실행되지 않는다.
• Job `deploy`: 마찬가지로 배포는 테스트 작업에 따라 달라진다. 테스트가 성공적으로 완료된 후에만 시작된다. 테스트가 실패하면 배포가 실행되지 않는다.

 

Advanced Use Case: Parallel and Conditional Execution

또한 여러 종속성을 지정하고 조건을 사용하여 복잡한 워크플로우를 생성할 수도 있다.

예를 들어 빌드 후 병렬로 실행할 수 있는 두 개의 테스트 작업과 두 테스트 작업이 모두 성공한 경우에만 실행해야 하는 배포 작업이 있는 시나리오를 예시로 든다.

jobs:
  build:
    # Build job definition
  
  test-backend:
    needs: build
    # Test-backend job definition
  
  test-frontend:
    needs: build
    # Test-frontend job definition
  
  deploy:
    needs: [test-backend, test-frontend]
    # Deploy job definition

• `test-backend` 와 `test-frontend` 는 모두 `build` 에 의존하며 `build` 가 완료된 후 병렬로 실행될 수 있다.
• `deploy` 를 시작하려면 두 테스트 작업이 모두 성공해야 한다.

 

---

 

Choosing the Runner for a Job

`jobs.<job_id>.runs-on` 작업을 실행할 머신 유형을 정의하는 데 사용된다.

• 대상 머신은 GitHub 호스팅 Runner , 더 큰 Runner 또는 자체 호스팅 Runner 일 수 있다 .
• 할당된 라벨, 그룹 멤버십 또는 이들의 조합을 기반으로 러너를 타겟팅할 수 있다.

 

• Run-on을 다음과 같이 제공할 수 있다.
  • a single string
  • a single variable containing a string
  • an array of strings, variables containing strings, or a combination of both
  • a key: value pair using the group or labels keys

• 문자열이나 변수의 배열을 지정하면 워크플로우는 지정된 모든 run-on 값과 일치하는 임의의 러너에서 실행된다.

 

---

 

 

1. Choosing GitHub-hosted runners

관리되는 실행 환경에 대해 GitHub 호스트 러너를 사용하여 Run-on 지정한다.

출처 : https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/choosing-the-runner-for-a-job#choosing-github-hosted-runners

 

---

 

2. Choosing self-hosted runners

Customized Environments의 경우 자체 호스팅된 러너를 사용한다.

예를 들어, 여기서 작업은 리눅스, x64 및 gpu라는 레이블을 가진 자체 호스팅된 러너에서만 실행된다.

runs-on: [self-hosted, linux, x64, gpu]

 

또한 배열에 문자열과 변수를 혼합할 수 있다.

on:
  workflow_dispatch:
    inputs:
      chosen-os:
        required: true
        type: choice
        options:
        - Ubuntu
        - macOS

jobs:
  test:
    runs-on: [self-hosted, "${{ inputs.chosen-os }}"]
    steps:
    - run: echo Hello world!

• 자체 호스팅과 같은 간단한 문자열에는 따옴표가 필요하지 않지만 `${inputs.chosen-os }` 와 같은 식에는 따옴표가 필요하다.

 

---

 

3. Choosing runners in a group

특정 작업 실행을 위해 러너를 그룹으로 구성한다.

 

Example: Using groups to control where jobs are run

GitHub Actions에서 자체 호스팅 Runner를 구성할 때 이를 그룹으로 구성할 수 있다. Runner 그룹을 사용하면 Runner에 대한 액세스를 관리하고 워크플로 요구 사항에 따라 특정 Runner 집합에 작업을 지시할 수 있다.

runs-on: my-group

 

Example: Combining groups and labels

Runner 그룹을 라벨과 결합하여 작업이 실행되는 위치를 더욱 구체화할 수 있다. 기능, 환경, 운영 체제 또는 기타 특성을 설명하기 위해 자체 호스팅 Runner에 레이블을 적용할 수 있다.

runs-on: [my-group, my-label]

 

Example: Using prefixes to differentiate runner groups

계층 구조, 환경 또는 기타 분류를 반영하여 Runner 그룹을 구별하기 위해 Prefix를 사용하여 러너 그룹을 명명할 수 있다.

runs-on: my-prefix-my-group

 

---

Reference

https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-jobs-in-a-workflow

https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/choosing-the-runner-for-a-job