엔드투엔드 배포 이해
GitHub Actions 워크플로는 필요에 맞게 다양한 방법으로 구성할 수 있는 유연한 도구입니다. 본 단원에서는 워크플로를 사용하여 Azure 인프라 구성을 포함하여 전체 솔루션을 배포하고 다른 배포 작업을 수행하는 방법을 알아봅니다.
워크플로 수는 어떻게 됩니까?
일부 조직에서는 Azure 환경을 관리하는 팀이 환경에서 실행되는 코드를 개발하는 팀과 다릅니다. 이러한 상황에서는 특정 영역을 담당하는 팀이 각각 소유한 여러 워크플로 생성을 시도하는 경우가 많습니다. 예를 들어 웹 사이트의 Azure 리소스를 배포하는 Bicep 코드를 배포하는 하나의 워크플로와 웹 사이트 애플리케이션을 배포하는 또 다른 워크플로를 만들 수 있습니다.
이 방법을 사용하면 워크플로를 관리하는 방법이 어느 정도 유연해질 수 있지만 모든 것을 동기화 상태로 유지하는 것은 어려울 수 있습니다. 예를 들어 웹 사이트 팀이 빌드하는 기능을 사용하도록 설정하기 위해 Azure App Service 앱에 새 설정이 필요하다고 가정해 보겠습니다. 인프라 배포 워크플로가 성공적으로 완료될 때까지 애플리케이션 배포 워크플로를 실행할 수 없습니다. 또한 인프라 워크플로에서 만든 Azure 리소스의 이름과 같은 데이터를 워크플로 간에 전송하는 것이 복잡해질 수 있습니다.
대신, 여러 팀이나 다른 사람이 구성 요소를 관리하더라도 솔루션에 필요한 모든 것을 배포하는 단일 워크플로를 만드는 것이 더 나은 경우가 많습니다. Git 및 GitHub와 같은 도구를 사용하여 작업을 조율할 수 있습니다. 새 기능이 추가되면 분기를 사용하여 Bicep 파일에 필요한 변경 내용을 적용할 수 있습니다. 변경 사항을 통합하고 릴리스할 준비가 되면 단일 워크플로가 솔루션을 빌드하고 배포하는 데 필요한 모든 단계를 수행하여 동기화되지 않을 가능성을 줄입니다.
팁
솔루션에 대한 코드를 빌드하는 경우 작동 방식을 테스트할 수 있도록 자주 배포해야 할 수 있습니다. 애플리케이션 코드와 함께 인프라를 배포하면 워크플로가 느리게 실행되고 진행이 중단될 수 있습니다.
이 위치에 있는 경우 개발 환경에 대한 인프라 배포를 사용하지 않도록 설정하는 것이 좋습니다. 경로 필터, 재사용 가능한 워크플로 및 조건을 사용하면 가능합니다. 그러나 다른 환경에서는 전체 배포 순서를 그대로 유지해야 합니다.
컨트롤 플레인 및 데이터 플레인
많은 Azure 리소스는 액세스를 위해 두 ‘플레인’을 제공합니다. ‘컨트롤 플레인’은 리소스를 배포하고 구성합니다. 데이터 플레인을 사용하면 리소스의 기능에 액세스할 수 있습니다.
Bicep 파일을 만들고 배포할 때 컨트롤 플레인과 상호 작용합니다. Azure에서 컨트롤 플레인은 Azure Resource Manager입니다. Resource Manager를 사용하여 각 리소스의 구성을 정의합니다.
하지만 워크플로에는 단순히 컨트롤 플레인과 상호 작용하는 것 이상의 작업이 필요한 경우가 많습니다. 예를 들어, 다음을 수행해야 합니다.
- 스토리지 계정에 BLOB를 업로드합니다.
- 데이터베이스 스키마를 수정합니다.
- 타사 서비스에 대한 API 호출을 수행합니다.
- 기계 학습 모델 업데이트를 트리거합니다.
- Azure App Service 앱에 웹 사이트 배포
- 가상 머신에 소프트웨어를 배포합니다.
- 타사 공급자에 DNS 항목을 등록합니다.
엔드투엔드 워크플로를 고려할 때 일반적으로 Azure 리소스를 배포한 다음 해당 리소스의 데이터 평면에 대해 일련의 작업을 수행해야 합니다. 경우에 따라 컨트롤 플레인을 사용하여 대부분의 배포를 수행하고 소수의 구성만 남아 있으므로 이러한 작업을 배포의 마지막 구간이라고 합니다.
참고
일부 리소스는 컨트롤 플레인과 데이터 플레인 간에 명확한 구분이 없습니다. 여기에는 Azure Data Factory와 Azure API Management가 포함됩니다. 두 서비스 모두 Bicep을 사용하여 완전히 자동화된 배포를 지원하지만 특별한 고려 사항이 필요합니다. 모듈 마지막 부분에 있는 요약 페이지에서 자세한 정보에 대한 링크를 찾을 수 있습니다.
데이터 플레인 작업을 수행하는 방법
리소스의 데이터 평면과 상호 작용하는 배포 워크플로를 만들 때 다음 세 가지 일반적인 방법 중에서 원하는 방법을 사용할 수 있습니다.
- Resource Manager 배포 스크립트
- 워크플로 스크립트
- 워크플로 작업
Resource Manager 배포 스크립트는 Bicep 파일 내에서 정의됩니다. 이러한 스크립트는 Bash 또는 PowerShell 스크립트를 실행하고 Azure CLI 명령 및 Azure PowerShell cmdlet과 상호 작용할 수 있습니다. 사용자는 Azure에 인증하는 데 사용할 배포 스크립트에 대한 관리 ID를 만들고, Azure는 배포 스크립트를 실행하는 데 필요한 다른 리소스를 자동으로 프로비저닝하고 관리합니다.
배포 스크립트는 배포 프로세스 내에서 기본 스크립트를 실행해야 할 때 유용하지만, 워크플로의 다른 요소에 쉽게 액세스할 수 있도록 하지는 않습니다.
배포 워크플로 내에서 사용자의 자체적인 논리를 실행할 수도 있습니다. GitHub Actions는 수행해야 하는 일반적인 작업의 풍부한 작업 에코시스템을 제공합니다. 요구 사항을 충족하는 작업을 찾을 수 없는 경우 스크립트를 사용하여 사용자의 자체적인 Bash 또는 PowerShell 코드를 실행할 수 있습니다. 워크플로 작업 및 스크립트는 워크플로의 실행기에서 실행됩니다. 사용하는 서비스의 데이터 평면에 대해 작업이나 스크립트를 인증해야 하는 경우가 많으며, 이를 수행하는 방법은 서비스에 따라 달라집니다.
워크플로 작업 및 스크립트는 유연성과 제어를 제공합니다. 또한 이를 통해 워크플로 아티팩트에 액세스할 수 있으며 이에 대해서는 곧 알아볼 수 있습니다. 이 모듈에서는 워크플로 작업에 집중합니다. 모듈의 마지막 부분에 있는 요약 페이지에서 Resource Manager 배포 스크립트에 관한 자세한 내용 링크를 확인할 수 있습니다.
출력
워크플로는 일반적으로 Bicep 파일을 배포하여 Azure 리소스를 만들고 구성합니다. 그런 다음 워크플로의 후속 부분은 해당 리소스의 데이터 평면과 상호 작용합니다. 리소스와 상호 작용할 수 있도록 워크플로 작업 및 단계에는 생성된 Azure 리소스에 대한 정보가 필요합니다.
예를 들어 스토리지 계정을 배포하는 Bicep 파일이 있다고 가정해 보겠습니다. 워크플로에서 스토리지 계정을 배포한 다음, 일부 BLOB를 스토리지 계정의 BLOB 컨테이너에 업로드하려고 합니다. BLOB를 업로드하는 워크플로 단계는 연결할 스토리지 계정의 이름과 파일을 업로드할 BLOB 컨테이너의 이름을 알고 있어야 합니다.
Bicep 파일이 Azure 리소스의 이름을 결정하도록 하는 것이 좋습니다. 매개 변수, 변수 또는 식을 사용하여 스토리지 계정 및 BLOB 컨테이너의 이름을 만들 수 있습니다. 그러면 Bicep 파일은 각 리소스의 이름을 제공하는 출력을 노출할 수 있습니다. 워크플로의 이후 단계에서 출력 값을 읽을 수 있습니다. 이렇게 하면 워크플로 정의가 환경 간에 변경되거나 Bicep 파일에 정의된 규칙에 따라 변경될 수 있는 이름 또는 기타 정보를 하드 코딩할 필요가 없습니다.
GitHub Actions를 사용하면 워크플로 변수를 사용하여 출력 값을 전파할 수 있습니다. azure/arm-deploy
작업은 각 Bicep 배포 출력에 대한 변수를 자동으로 만듭니다. 스크립트에서 워크플로 변수를 수동으로 만들 수도 있습니다. 모듈 마지막 부분에 있는 요약 페이지에서 자세한 정보에 대한 링크를 찾을 수 있습니다.
다른 작업에서 만든 변수에 액세스할 때 해당 변수를 읽는 작업에 액세스할 수 있도록 변수를 게시해야 합니다. 예를 들어 Bicep 파일을 배포하는 작업을 만들고 appServiceAppName
출력을 워크플로에 전파해야 한다고 가정합니다. outputs
키워드를 사용하여 appServiceAppName
워크플로 변수가 deploy
단계에서 만든 appServiceAppName
출력 변수의 값으로 설정되도록 지정합니다.
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
그런 다음 이후 작업에서 needs
키워드를 포함하여 변수를 만든 작업에 대한 명시적 종속성을 만들고, 게시된 변수의 이름을 사용하여 변수를 참조합니다.
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Bicep 출력 및 워크플로 변수를 사용하여 Bicep 코드를 배포한 다음 배포의 일부로 리소스에 대해 다양한 작업을 수행하는 워크플로를 만들 수 있습니다.