빠른 시작: GitHub Actions를 사용하여 Bicep 파일 배포

아티클
09/26/2024

GitHub Actions는 소프트웨어 개발 워크플로를 자동화하는 GitHub의 기능 모음입니다. 이 빠른 시작에서는 Azure Resource Manager 배포를 위한 GitHub Actions를 사용하여 Azure에 Bicep 파일 배포를 자동화합니다.

GitHub Actions 및 Bicep 파일에 대한 간략한 소개를 제공합니다. GitHub Actions 및 프로젝트 설정에 대한 자세한 단계는 Bicep 및 GitHub Actions를 사용하여 Azure 리소스 배포를 참조하세요.

필수 조건

활성 구독이 있는 Azure 계정. 체험 계정을 만듭니다.
GitHub 계정. 없는 경우 평가판에 등록하세요.
Bicep 파일과 워크플로 파일을 저장하는 GitHub 리포지토리입니다. 리포지토리를 만들려면 새 리포지토리 만들기를 참조하세요.

리소스 그룹 만들기

리소스 그룹을 만듭니다. 이 빠른 시작의 뒷부분에서 Bicep 파일을 이 리소스 그룹에 배포합니다.

CLI
PowerShell

az group create -n exampleRG -l westus

New-AzResourceGroup -Name exampleRG -Location westus

GitHub Actions는 ID로 실행됩니다. az ad sp create-for-rbac 명령을 사용하여 ID에 대한 서비스 주체를 만듭니다. ID가 있는 GitHub 작업이 이 리소스 그룹에 리소스를 만들 수 있도록 이전 세션에서 만든 리소스 그룹에 대한 기여자 역할을 서비스 주체에게 부여합니다. 필요한 최소한의 액세스 권한을 부여하는 것이 좋습니다.

az ad sp create-for-rbac --name {app-name} --role contributor --scopes /subscriptions/{subscription-id}/resourceGroups/exampleRG --json-auth

{app-name} 자리 표시자를 애플리케이션 이름으로 바꿉니다. {subscription-id}는 구독 ID로 바꿉니다.

출력은 다음 출력과 유사하게 App Service 앱에 대한 액세스를 제공하는 역할 할당 자격 증명이 포함된 JSON 개체입니다.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
  }

나중에 사용할 수 있도록 이 JSON 개체를 복사합니다. clientId, clientSecret, subscriptionId 및 tenantId 값이 있는 섹션만 필요합니다. 마지막 줄 끝에 추가 쉼표가 없어야 합니다(예: 위 예의 tenantId 줄). 그렇지 않으면 잘못된 JSON 파일이 생성됩니다. 배포 중에 "Login failed with Error: Content isn't a valid JSON object. Double check if the 'auth-type' is correct."라는 오류가 발생합니다.

Open ID Connect는 단기 토큰을 사용하는 인증 방법입니다. GitHub Actions로 OpenID Connect 설정은 보안 강화를 제공하는 더 복잡한 프로세스입니다.

기존 애플리케이션이 없는 경우 리소스에 액세스할 수 있는 새 Active Directory 애플리케이션 및 서비스 주체를 등록합니다. Active Directory 애플리케이션을 만듭니다.
```
az ad app create --display-name myApp
```
이 명령은 client-id인 appId를 사용하여 JSON을 출력합니다. 이 값을 저장하여, 나중에 AZURE_CLIENT_ID GitHub 비밀로 사용합니다.

Graph API로 페더레이션 자격 증명을 생성할 때 objectId 값을 사용하고 이를 APPLICATION-OBJECT-ID로 참조합니다.
서비스 주체를 생성합니다. $appID를 JSON 출력의 appId로 대체합니다.

이 명령은 다른 objectId로 JSON 출력을 생성하며 다음 단계에서 사용됩니다. 새 objectId는 assignee-object-id입니다.

appOwnerTenantId를 복사하여 나중에 AZURE_TENANT_ID에 대한 GitHub 비밀로 사용합니다.
```
 az ad sp create --id $appId
```
구독 및 개체별 새 역할 할당을 만듭니다. 기본적으로 역할 할당은 기본 구독에 연결됩니다. $subscriptionId를 구독 ID로, $resourceGroupName을 리소스 그룹 이름으로, $assigneeObjectId를 생성된 assignee-object-id로 바꿉니다. Azure CLI를 사용하여 Azure 구독을 관리하는 방법을 알아보세요.
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scopes /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/
```
다음 명령을 실행하여 Active Directory 애플리케이션에 대한 새 페더레이션 ID 자격 증명을 만듭니다.
- APPLICATION-OBJECT-ID를 Active Directory 애플리케이션의 objectId(앱을 생성하는 동안 생성됨)로 대체합니다.
- CREDENTIAL-NAME의 값을 나중에 참조하도록 설정합니다.
- subject를 설정합니다. 이 값은 워크플로에 따라 GitHub에 의해 정의됩니다.
  - GitHub Actions 환경의 작업: repo:< Organization/Repository >:environment:< Name >
  - 환경에 연결되지 않은 작업의 경우 워크플로를 트리거하는 데 사용되는 참조 경로를 기반으로 분기/태그에 대한 참조 경로(repo:< Organization/Repository >:ref:< ref path>)를 포함합니다. 예를 들어 repo:n-username/ node_express:ref:refs/heads/my-branch 또는 repo:n-username/ node_express:ref:refs/tags/my-tag입니다.
  - 끌어오기 요청 이벤트에 의해 트리거된 워크플로의 경우: repo:< Organization/Repository >:pull_request
```
az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}'
```
Azure Portal에서 Active Directory 애플리케이션, 서비스 주체 및 페더레이션 자격 증명을 만드는 방법을 알아보려면 GitHub 및 Azure 연결을 참조하세요.

GitHub 비밀 구성

서비스 주체
Open ID Connect

Azure 자격 증명, 리소스 그룹 및 구독에 대한 비밀을 만듭니다. 워크플로 만들기 섹션에서 이러한 비밀을 사용합니다.

GitHub에서 리포지토리로 이동합니다.
설정 > 비밀 및 변수 > 작업 > 새 리포지토리 비밀을 선택합니다.
Azure CLI 명령의 전체 JSON 출력을 비밀의 값 필드에 붙여넣습니다. 비밀 AZURE_CREDENTIALS의 이름을 지정합니다.
AZURE_RG라는 이름으로 다른 비밀을 만듭니다. 보안 비밀의 값 필드(exampleRG)에 리소스 그룹의 이름을 추가합니다.
AZURE_SUBSCRIPTION라는 이름으로 다른 비밀을 만듭니다. 비밀의 값 필드에 구독 ID를 추가합니다(예: aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e).

로그인 작업에 애플리케이션의 클라이언트 ID, 테넌트 ID 및 구독 ID를 제공해야 합니다. 이러한 값은 워크플로에서 직접 제공하거나 GitHub 비밀에 저장하고 워크플로에서 참조할 수 있습니다. 값을 GitHub 비밀로 저장하는 것이 더 안전한 옵션입니다.

GitHub 리포지토리를 열고 설정으로 이동합니다.
설정 > 비밀 > 새 비밀을 차례로 선택합니다.
AZURE_CLIENT_ID, AZURE_TENANT_ID 및 AZURE_SUBSCRIPTION_ID에 대한 비밀을 만듭니다. GitHub 비밀에 Active Directory 애플리케이션의 다음 값을 사용합니다.

GitHub 비밀 Active Directory 애플리케이션

AZURE_CLIENT_ID 애플리케이션(클라이언트) ID

AZURE_TENANT_ID 디렉터리(테넌트) ID

AZURE_SUBSCRIPTION_ID 구독 ID
비밀 추가를 선택하여 각 비밀을 저장합니다.

GitHub 비밀	Active Directory 애플리케이션
AZURE_CLIENT_ID	애플리케이션(클라이언트) ID
AZURE_TENANT_ID	디렉터리(테넌트) ID
AZURE_SUBSCRIPTION_ID	구독 ID

Bicep 파일 추가

GitHub 리포지토리에 Bicep 파일을 추가합니다. 다음 Bicep 파일은 저장소 계정을 만듭니다.

@minLength(3)
@maxLength(11)
param storagePrefix string

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
  'Standard_ZRS'
  'Premium_LRS'
  'Premium_ZRS'
  'Standard_GZRS'
  'Standard_RAGZRS'
])
param storageSKU string = 'Standard_LRS'

param location string = resourceGroup().location

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

output storageEndpoint object = stg.properties.primaryEndpoints

Bicep 파일에는 3~11자의 storagePrefix라는 매개 변수 하나가 필요합니다.

파일을 리포지토리의 어디에나 배치할 수 있습니다. 다음 섹션의 워크플로 샘플에서는 Bicep 파일의 이름이 main.bicep이고 리포지토리의 루트에 저장되어 있다고 가정합니다.

워크플로 만들기

워크플로는 트리거될 때 실행할 단계를 정의합니다. 리포지토리의 .github/workflows/ 경로에 있는 YAML(.yml) 파일입니다. 워크플로 파일 확장명은 .yml 또는 .yaml일 수 있습니다.

워크플로를 만들려면 다음 단계를 따르세요.

GitHub 리포지토리의 상단 메뉴에서 작업을 선택합니다.
새 워크플로를 선택합니다.
워크플로 직접 설정을 선택합니다.
main.yml이 아닌 다른 이름을 선호하는 경우 워크플로 파일의 이름을 바꿉니다. 예: deployBicepFile.yml

yml 파일의 내용을 다음 코드로 바꿉니다.

서비스 주체
OpenID Connect

name: Deploy Bicep file
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

    - name: Checkout code
      uses: actions/checkout@main

    - name: Log into Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Deploy Bicep file
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

mystore를 고유한 스토리지 계정 이름 접두사로 바꿉니다.

참고 항목

ARM 배포 작업에 대신 JSON 형식 매개 변수 파일을 지정할 수 있습니다(예: .azuredeploy.parameters.json).

워크플로 파일의 첫 번째 섹션에는 다음이 포함됩니다.

name: 워크플로의 이름입니다.
on: 워크플로를 트리거하는 GitHub 이벤트의 이름입니다. 기본 분기에 푸시 이벤트가 있을 때 워크플로가 트리거됩니다.

on: [push]
name: Azure ARM
permissions:
  id-token: write
  contents: read
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

      # Checkout code
    - uses: actions/checkout@main

      # Log into Azure
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Deploy Bicep file
    - name: deploy
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

변경 내용 커밋을 선택합니다.
기본 분기에 직접 커밋을 선택합니다.
새 파일 커밋(또는 변경 내용 커밋)을 선택합니다.

워크플로 파일이나 Bicep 파일을 업데이트하면 워크플로가 트리거됩니다. 워크플로는 변경 내용을 커밋한 직후에 시작됩니다.

워크플로 상태 확인

작업 탭을 선택합니다. deployBicepFile.yml 만들기 워크플로가 나열됩니다. 워크플로를 실행하는 데 1-2분이 소요됩니다.
워크플로를 선택하여 열고 Status가 Success인지 확인합니다.

리소스 정리

리소스 그룹 및 리포지토리가 더 이상 필요하지 않은 경우 리소스 그룹과 GitHub 리포지토리를 삭제하여 배포한 리소스를 정리합니다.

CLI
PowerShell

az group delete --name exampleRG

Remove-AzResourceGroup -Name exampleRG

다음 단계

Bicep 파일 구조 및 구문

다음을 통해 공유