재사용 가능한 워크플로를 사용하여 환경 간 유사성 처리

5분

여러 환경에 변경 내용을 배포하는 경우 각 환경에 배포하는 단계는 비슷하거나 동일합니다. 이 단원에서는 반복을 방지하고 워크플로 코드를 다시 사용할 수 있도록 워크플로를 디자인하는 방법을 알아봅니다.

여러 환경에 배포

웹 사이트 팀의 동료와 이야기한 후, 완구 회사의 웹 사이트에 대해 다음 워크플로를 결정합니다.

테스트 및 프로덕션 배포를 포함한 일련의 워크플로 작업을 보여 주는 다이어그램

워크플로는 Bicep Linter를 실행하여 Bicep 코드가 유효한지 확인하고 모범 사례를 따릅니다.

린팅은 Azure에 연결할 필요 없이 Bicep 코드에서 발생하므로 배포하는 환경의 수는 상관이 없습니다. 한 번만 실행됩니다.
워크플로는 테스트 환경에 배포되며 다음이 필요합니다.
1. Azure Resource Manager 실행 전 유효성 검사를 실행합니다.
2. Bicep 코드를 배포합니다.
3. 테스트 환경에 대한 테스트를 실행합니다.
워크플로 일부가 실패하면 전체 워크플로가 중지되므로 문제를 조사하고 해결할 수 있습니다. 그러나 모든 것이 성공하면 워크플로가 계속해서 프로덕션 환경에 배포됩니다.
1. 워크플로에는 프로덕션 환경에서 가상 작업을 실행하여 프로덕션 Azure 리소스에 적용되는 변경 내용을 나열하는 미리 보기 단계가 포함됩니다. 또한 가상 작업은 배포의 유효성을 검사하므로 프로덕션 환경에 대해 별도의 유효성 검사 단계를 실행할 필요가 없습니다.
2. 수동 유효성 검사를 위해 워크플로가 일시 중지됩니다.
3. 승인이 수신되면 워크플로는 프로덕션 환경에 대한 배포 및 스모크 테스트를 실행합니다.

이러한 작업 중 일부는 테스트 환경과 프로덕션 환경 간에 반복되며 일부는 특정 환경에 대해서만 실행됩니다.

작업	환경
린트	둘 다 아님 - 린팅이 어느 환경에 대해서도 작동하지 않습니다.
유효성 검사	테스트에서만
미리 보기	프로덕션에서만
배포	두 환경 모두
스모크 테스트	두 환경 모두

워크플로에서 단계를 반복해야 할 때 단계의 정의를 복사하고 붙여넣는 것은 좋은 방법이 아닙니다. 실수로 사소한 실수가 발생하거나 워크플로 코드를 복제할 때 동기화되지 않을 수 있습니다. 그리고 나중에 단계를 변경해야 하는 경우에는 변경 내용을 여러 위치에 적용해야 합니다. 더 좋은 방법은 재사용 가능한 워크플로를 활용하는 것입니다.

재사용 가능한 워크플로

GitHub Actions를 사용하면 단계 또는 작업을 정의하는 별도의 워크플로 YAML 파일을 만들어 워크플로 정의의 재사용 가능한 섹션을 만들 수 있습니다. YAML 파일을 만들어 단일 워크플로 내에서 또는 여러 워크플로에서도 워크플로의 일부를 여러 번 다시 사용합니다. 다시 사용하는 워크플로는 호출된 워크플로이며 이 워크플로가 포함된 워크플로는 호출자 워크플로입니다. 개념적으로 Bicep 모듈과 유사한 것으로 간주할 수 있습니다.

재사용 가능한 워크플로를 만들 때 workflow_call 트리거를 사용하여 다른 워크플로에서 워크플로를 호출할 수 있음을 GitHub 작업에 알립니다. 다음은 script.yml이라는 파일에 저장된 재사용 가능한 워크플로의 기본 예제입니다.

on:
  workflow_call:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello world!

호출자 워크플로에서 uses: 키워드를 포함하고 현재 리포지토리 내에서 호출된 워크플로의 경로를 지정하여 호출된 워크플로를 참조합니다.

on: 
  workflow_dispatch:

jobs:
  job:
    uses: ./.github/workflows/script.yml

다른 리포지토리의 워크플로 정의 파일을 참조할 수도 있습니다.

호출된 워크플로 입력 및 비밀

‘입력’ 및 ‘비밀’을 사용하여 워크플로를 사용할 때마다 워크플로의 작은 차이를 허용할 수 있으므로 호출된 워크플로를 더 쉽게 다시 사용할 수 있습니다.

호출된 워크플로를 만들 때 파일의 맨 위에 입력과 비밀을 표시할 수 있습니다.

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

필요한 만큼 입력과 비밀을 정의할 수 있습니다. 그러나 Bicep 매개 변수와 마찬가지로 워크플로 입력을 과도하게 사용해서는 안 됩니다. 너무 많은 설정을 지정하지 않고도 다른 사용자가 워크플로를 쉽게 다시 사용할 수 있도록 해야 합니다.

입력에는 다음을 비롯한 여러 속성이 포함될 수 있습니다.

워크플로 정의의 입력을 참조하는 데 사용하는 입력 이름입니다.
입력 유형입니다. 입력은 ‘문자열’, ‘숫자’, ‘부울’ 값을 지원합니다.
입력의 기본값(선택 사항)입니다. 기본값을 지정하지 않은 경우 워크플로가 호출자 워크플로에서 사용될 때 값을 제공해야 합니다.

비밀에는 이름이 있지만 형식이나 기본값은 없습니다.

예에서 워크플로는 environmentType 필수 문자열 입력과 AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID 필수 비밀을 정의합니다.

워크플로에서는 다음 예제와 같이 매개 변수 값을 참조하는 특수 구문을 사용합니다.

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

with 키워드를 사용하여 입력 값을 호출된 워크플로에 전달합니다. with 섹션 내에서 각 입력의 값을 정의해야 합니다. 워크플로의 환경 변수를 참조하는 데는 env 키워드를 사용할 수 없습니다. secrets 키워드를 사용하여 호출된 워크플로에 비밀 값을 전달합니다.

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

호출된 워크플로의 워크로드 ID 사용

호출된 워크플로로 작업하는 경우 여러 워크플로 정의 파일에서 배포 작업 중 일부를 정의하는 경우가 종종 있습니다. 호출된 모든 워크플로가 워크플로의 ID에 액세스하고 Azure에 인증할 수 있도록 하려면 다음과 같이 호출자 워크플로에 권한을 부여해야 합니다.

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

조건

워크플로 ‘조건’을 사용하여 지정한 규칙에 따라 단계 또는 작업을 실행할지 여부를 지정할 수 있습니다. 입력과 워크플로 조건을 결합하여 다양한 상황에 맞게 배포 프로세스를 사용자 지정할 수 있습니다.

예를 들어, 스크립트 단계를 실행하는 워크플로를 정의한다고 가정합니다. 각 환경에 대한 템플릿을 재사용하려고 합니다. 프로덕션 환경을 배포할 때 기타 단계를 실행하려고 합니다. 단계에서 if 조건을 사용하여 이를 달성하는 방법은 다음과 같습니다.

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

    - run: |
        echo This step only runs for production deployments.
      if: inputs.environmentType == 'Production'

이 조건은 ‘environmentType 매개 변수의 값이 ‘Production’과 같은 경우 단계를 실행한다’는 것을 의미합니다.

조건이 워크플로에 유연성을 더한다고 하더라도, 조건이 너무 많으면 워크플로가 복잡해지고 이해하기 어려워질 수 있습니다. 호출된 워크플로에 조건이 많은 경우 이를 다시 디자인하는 것이 좋습니다.

또한 YAML 주석을 사용하여 사용하는 조건을 설명하고, 추가적인 설명이 필요할 수 있는 워크플로의 기타 측면을 설명하세요. 주석을 사용하면 나중에 워크플로를 더 쉽게 이해하고 사용할 수 있습니다. 이 모듈 전체의 연습에서 일부 예제 YAML 설명이 있습니다.

재사용 가능한 워크플로를 사용하여 환경 간 유사성 처리

여러 환경에 배포

재사용 가능한 워크플로

호출된 워크플로 입력 및 비밀

호출된 워크플로의 워크로드 ID 사용

조건

피드백