Azure Pipelines를 사용하여 릴리스 파이프라인 계획
이 섹션에서는 Andy 및 Mara와 함께 Azure Pipelines에서 실행되는 기본 CD 파이프라인을 계획합니다.
이들은 파이프라인이 완료되면 나머지 팀원에게 시연할 것입니다. 파이프라인은 POC로 제공되며, 이를 통해 더 많은 내용을 배우고 Tim 님과 Amita 님으로부터 피드백을 받아 개선하고 확장할 것입니다.
기본 CD 파이프라인의 구성 요소는 무엇일까요?
기본 CD 파이프라인에는 프로세스를 진행하고 하나 이상의 ‘스테이지’ 또는 배포 단계를 구성하는 ‘트리거’가 포함되어 있습니다. 단계는 작업으로 구성됩니다. 작업은 애플리케이션을 빌드, 테스트 또는 배포하는 방법을 정의하는 일련의 단계입니다.
Andy: 이미 
빌드 아티팩트가 있습니다. 기존 빌드 파이프라인이 만드는 .zip 파일입니다. 그런데 이를 
라이브 환경에 배포하려면 어떻게 해야 할까요?
파이프라인 단계란 무엇일까요?
‘스테이지’는 독립적으로 실행될 수 있고 다른 메커니즘에 의해 트리거될 수 있는 파이프라인의 일부입니다. 메커니즘은 이전 스테이지에서 가져온 것이거나 일정 또는 수동 트리거일 수 있습니다. 해당 메커니즘에 대해서는 다음 모듈에서 자세히 살펴보겠습니다.
Mara: 앱을 빌드하는 스테이지와 테스트를 실행하는 다른 스테이지를 둘 수 있습니다.
Mara: 파이프라인의 빌드 스테이지 에 대한 작업을 이미 정의했습니다. 빌드를 환경으로 배포하는 작업을 비롯한 배포 스테이지는 유사할 수 있습니다.
문제는 이 아티팩트를 배포할 위치입니다.
환경이란 무엇일까요?
애플리케이션 또는 서비스가 실행되는 위치를 가리키는 데 ‘환경’이라는 용어를 사용하는 경우가 많습니다. 예를 들어 프로덕션 환경은 최종 사용자가 애플리케이션에 액세스하는 위치일 수 있습니다.
이 예의 경우 프로덕션 환경은 다음이 될 수 있습니다.
- 물리적 머신 또는 VM(가상 머신).
- 컨테이너화된 환경(예: Kubernetes).
- 관리형 서비스(예: Azure App Service).
- 서버리스 환경(예: Azure Functions).
아티팩트는 환경에 배포됩니다. Azure Pipelines를 사용하면 온-프레미스든 클라우드에 있든 관계없이 거의 모든 종류의 환경에 쉽게 배포할 수 있습니다.
Azure Pipelines에서 ‘환경’이라는 용어에는 두 번째 의미가 있습니다. 여기서 ‘환경’은 Kubernetes 클러스터, App Service 인스턴스 또는 가상 머신과 같은 배포 환경의 추상적 표현입니다.
Azure Pipelines 환경에서는 배포 기록을 기록하여 변경 출처를 식별하는 데 도움을 줍니다. Azure Pipelines 환경을 사용하면 보안 검사를 정의하고 아티팩트가 파이프라인의 한 스테이지에서 다른 스테이지로 승격되는 방식을 제어할 수도 있습니다. 환경에 포함되는 항목은 아티팩트를 사용하여 수행하려는 작업에 따라 달라집니다. 아티팩트를 테스트하려는 환경은 최종 사용자에 아티팩트를 배포하려는 환경과 다르게 정의될 수 있습니다.
Azure Pipelines 환경을 정의하는 한 가지 방법은 YAML 파일을 사용하는 것입니다. YAML 파일에는 아티팩트를 배포할 Azure Pipelines 환경을 지정하는 environment 섹션이 포함되어 있습니다.
릴리스 파이프라인을 계획할 때 애플리케이션 또는 서비스를 실행할 위치를 결정해야 합니다. Andy 님과 Mara 님이 결정하는 내용을 확인해 보세요.
Andy: 전반적으로 어떤 유형의 환경이 필요할까요? 온-프레미스에 배포할까요? 아니면 클라우드에 배포할까요?
Mara: Tim에게 실험실에서 VM을 만들어 달라고 요청할 수 있지만 Tim은 항상 하드웨어가 부족합니다. 클라우드를 사용하는 경우 자체적으로 POC를 설정하는 편이 빠르고 간편할 것입니다.
Andy: 동의합니다. 하지만 고려해야 할 클라우드 옵션이 너무 많고 Azure Pipelines를 사용하여 그 중 하나에 배포할 수 있습니다. 어떤 것을 시도해야 할까요?
Mara: 게임을 개발하는 팀은 Azure를 사용하여 백 엔드 시스템의 일부를 호스트합니다. 이들은 Azure를 빠르게 설정하며, 이를 선호하는 것 같습니다. 클라우드에서도 Azure를 사용해야 할 것 같습니다.
Andy: 좋습니다. 하지만 Azure에서는 많은 컴퓨팅 옵션을 제공하죠. 무엇을 선택해야 할까요?
Andy 님은 화이트 보드에 다음과 같은 옵션을 나열합니다.
- 가상 머신
- 컨테이너
- Azure App Service
- 서버리스 컴퓨팅
참고
이 모듈의 끝부분에서 각 컴퓨팅 옵션에 대한 자세한 정보를 찾을 수 있습니다.
Mara: 컨테이너와 서버리스 컴퓨팅이 현재 인기를 끌고 있습니다. VM과 비교하면 리소스 측면에서 이 둘은 간단합니다. 교체와 스케일 아웃도 쉽죠. 둘 다 흥미롭지만 동시에 두 기술을 새롭게 배워야 한다니 걱정되는군요. 파이프라인 빌드에만 집중하는 것이 좋겠습니다.
Andy: 동의합니다. 그러면 VM이나 App Service가 되겠네요. 일부 특정 환경에 대한 전체 액세스 권한이 필요한 기간 업무 앱을 클라우드로 이동하는 경우 VM이 더 나은 선택이 될 것이라고 생각합니다. 딱히 그럴 일은 없죠.
Mara: 그러면 선택할 옵션으로 App Service가 남네요. Azure DevOps를 지원하도록 설계되었으며 여러 이점을 제공합니다. 웹앱을 지원하는 PaaS(Platform as a Service) 환경이므로 저희의 부담을 많이 덜어줍니다. 인프라에 대해 걱정하지 않아도 됩니다. 또한 보안 기능을 제공하며 부하 분산 및 자동 스케일링을 수행할 수 있습니다.
Andy: App Service가 저희에게 알맞은 것 같네요. 그러면 App Service를 사용하죠. 개념 증명을 만드는 것뿐이지만요. 나중에 다른 옵션을 사용하려는 경우에 컴퓨팅 옵션을 언제든지 변경할 수 있죠.
Azure Pipelines에서는 배포 단계를 어떻게 수행할까요?
애플리케이션을 배포하려면 먼저 Azure Pipelines를 대상 환경에서 인증해야 합니다. Azure Pipelines는 여러 인증 메커니즘을 제공합니다. 사용하는 환경은 배포하려는 대상 환경에 따라 다릅니다. 이 모듈의 끝부분에서 관련 메커니즘에 대한 자세한 정보를 찾을 수 있습니다.
Andy: 빌드 아티팩트가 있고, 파이프라인의 스테이지에서 빌드와 배포를 한다는 점을 알게 되었습니다. 또한 배포 대상 환경을 정의했습니다. 바로 App Service죠. 이제 질문하자면, App Service에서 Azure Pipelines를 어떻게 인증할까요? 이는 Tim 님이 고려해야 할 문제 중 하나입니다. 프로세스를 보호해야 합니다.
약간의 조사를 거쳐 Andy 님과 Mara 님은 Azure Piplelines에서 App Service에 배포할 수 있는 일반적인 단계를 알아냈습니다.
- 파이프라인 구성에서 대상 배포 환경을 지정합니다.
- Azure Pipelines에서 해당 환경에 대한 액세스를 인증하는 수단을 제공합니다.
- Azure Pipelines 태스크를 사용하여 빌드 아티팩트를 해당 환경에 배포합니다.
Mara: 조사한 내용에 따라 대상 환경을 지정하고, 해당 환경에 대한 액세스를 인증하기 위한 ‘서비스 연결’을 만들어야 합니다. 서비스 연결을 정의하고 나면 모든 작업에서 사용할 수 있습니다. 그런 다음 기본 제공 작업 DownloadPipelineArtifact을(를) 사용하여 빌드 아티팩트를 파이프라인 에이전트에 다운로드하고 AzureWebApp을(를) 사용하여 애플리케이션을 Azure App Service에 배포해야 합니다.
작업과 전략이란?
기존 빌드 파이프라인은 빌드 에이전트, 파이프라인 변수, 소프트웨어를 빌드하는 데 필요한 태스크를 정의합니다.
파이프라인의 배포 부분에는 이와 같은 요소가 포함되어 있습니다. 또한 배포 구성은 일반적으로 하나 이상의 작업, 하나의 파이프라인 환경, 그리고 전략을 정의합니다. 앞서 파이프라인 환경에 대해 알아보았습니다.
다음은 이 모듈에서 나중에 실행할 구성 예제입니다. 이 구성은 Azure App Service에 Space Game 웹 사이트를 배포합니다.
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
작업
작업은 하나의 단위로 순차적으로 실행되는 일련의 단계 또는 작업입니다. 모든 파이프라인 단계는 해당 단계에서 job 키워드를 사용하지 않는 경우에도 기본적으로 하나의 작업을 포함합니다.
작업은 에이전트 풀, 컨테이너 또는 Azure DevOps 서버에서 직접 실행할 수 있습니다. 여기에 표시된 예제 작업은 Microsoft에서 호스트하는 Ubuntu 에이전트에서 실행됩니다.
각 작업이 실행되는 조건을 지정할 수 있습니다. 여기에 표시된 예제 작업은 조건을 정의하지 않습니다. 기본적으로 작업은 다른 작업에 종속되지 않거나 의존하는 모든 작업이 성공적으로 완료된 경우 실행됩니다.
작업을 병렬 또는 순차적으로 실행할 수도 있습니다. 예를 들어 기존 빌드 파이프라인을 사용하면 병렬 작업을 사용하여 Windows, Linux 및 macOS 에이전트에서 소프트웨어를 동시에 빌드할 수 있습니다.
‘배포 작업’은 배포 스테이지에서 중요한 역할을 수행하는 특별한 유형의 작업입니다. 배포 작업은 Azure Pipelines의 배포 상태를 기록하여 감사 내역을 제공합니다. 배포 작업은 배포 전략을 정의하는 데도 도움이 됩니다. 이 작업은 잠시 후에 수행합니다.
전략
‘전략’은 애플리케이션 출시 방법을 정의합니다. 향후 모듈에서 파란색-녹색 및 카나리아와 같은 전략에 대해 배웁니다. 지금은 runOnce 전략을 사용하여 파이프라인에서 Space Game 패키지를 다운로드하고 Azure App Service에 배포합니다.
Azure Pipelines Azure에 어떻게 연결하나요?
Azure 리소스(예: 가상 머신 또는 App Service)에 앱을 배포하려면 ‘서비스 연결’이 필요합니다. 서비스 연결은 다음 두 가지 방법 중 하나를 사용하여 Azure 구독에 대한 보안 액세스를 제공합니다.
- 서비스 주체 인증
- Azure 리소스에 대한 관리 ID
이 모듈의 끝부분에서 다음 보안 모델에 대해 자세히 알아볼 수 있으므로 여기서는 간략히 알아봅니다.
- ‘서비스 주체’는 Azure 리소스에 액세스할 수 있는 ID로, 역할이 제한적입니다. 서비스 주체는 사용자를 대신하여 자동화된 태스크를 수행할 수 있는 서비스 계정으로 간주됩니다.
- Azure 리소스에 대한 관리 ID는 서비스 주체 작업 프로세스를 간소화하는 Microsoft Entra ID의 기능입니다. 관리 ID는 Microsoft Entra 테넌트에 존재하므로 Azure 인프라는 자동으로 서비스를 인증하고 계정을 관리할 수 있습니다.
관리 ID는 서비스 주체 작업 프로세스를 간소화합니다. 하지만 이 모듈에서는 서비스 연결이 자동으로 Azure 리소스를 검색하고 적절한 서비스 주체 역할을 할당할 수 있기 때문에 서비스 주체 인증을 사용합니다.
계획
Andy 님과 Mara 님은 시작할 준비가 되었습니다. 이들이 수행할 작업은 다음과 같습니다.
- 기존 Azure Pipelines 빌드 구성을 활용합니다.
- 아티팩트를 만드는 빌드 스테이지를 정의합니다.
- App Service에 아티팩트를 배포하는 배포 스테이지를 정의합니다.
Andy: 이 그림이 정확한가요? Azure Pipelines를 사용하여 Azure App Service 에 배포합니다. 이를 위해 
빌드 아티팩트를 배포 스테이지 
에 대한 입력으로 사용합니다. 배포 스테이지의 작업은 
아티팩트를 다운로드하고 서비스 연결을 사용하여 아티팩트를 App Service 
에 배포합니다.
Mara: 그렇게 요약할 수 있겠네요. 이제 시작하겠습니다.