애플리케이션 및 가상 머신 구성
Azure 솔루션에 대한 앱 및 기타 사용자 지정 코드를 빌드하는 것이 일반적입니다. 사용자 지정 앱에는 사람이 개입할 필요 없이 실행되는 웹 사이트, API, 백그라운드 앱이 포함될 수 있습니다. 본 단원에서는 인프라와 함께 앱을 빌드하고 배포하는 워크플로를 설계하는 방법을 알아봅니다.
앱 빌드
많은 유형의 앱을 사용하려면 ‘컴파일’ 또는 ‘빌드’해야 합니다. 빌드 프로세스는 앱의 소스 코드를 가져와서 일련의 작업을 수행한 다음 배포 가능한 파일 집합을 만듭니다.
빌드 프로세스는 소스 코드를 이진 파일 또는 실행 파일로 컴파일합니다. 일반적으로 빌드 프로세스에는 웹 사이트 사용자에게 제공되는 이미지 파일을 압축하고, 코드를 린팅하여 적절한 코딩 사례를 따르는지 확인하고, 앱의 개별 부분의 동작을 확인하는 단위 테스트를 실행하는 등의 기타 작업이 포함됩니다. 파일을 수정할 수 없도록 디지털 서명과 같은 단계를 수행할 수도 있습니다.
일련의 단계가 무엇이든 빌드 프로세스의 출력은 배포 가능한 ‘아티팩트’입니다. 아티팩트는 일반적으로 워크플로 실행기의 파일 시스템에 저장됩니다. 워크플로의 이후 부분은 아티팩트와 함께 작동하여 여러 환경에 걸쳐 아티팩트를 배포하고 그 과정에서 워크플로 정의에 정의한 품질 기준에 따라 테스트해야 합니다.
참고
‘CI(연속 통합)’ 및 ‘CD(지속적인 배포)’라는 용어를 들어보셨을 것입니다. 빌드 프로세스는 워크플로의 연속 통합에 속해 있습니다.
워크플로 아티팩트
워크플로에서 생성된 아티팩트는 Git 리포지토리에 저장되지 않습니다. 소스 코드에서 파생되지만 코드 자체가 아니므로 소스 제어 리포지토리에 속하지 않습니다. 워크플로 실행기의 파일 시스템에 만들어집니다. 각 워크플로 작업에 대해 새 실행기가 만들어지므로 작업과 실행기 간에 파일을 공유하는 방법이 필요합니다.
워크플로 아티팩트를 통해 GitHub Actions에 파일을 저장할 수 있으며, 워크플로의 특정 실행과 연결됩니다. actions/upload-artifact 워크플로 작업을 사용하여 GitHub Actions에 실행기 파일 시스템에서 파일 또는 폴더를 워크플로 아티팩트로 업로드하도록 지시합니다.
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
path 속성은 작업 실행기의 파일 시스템에 있는 컴파일된 코드 또는 출력 파일을 포함하는 위치입니다. 이 위치의 내용은 아티팩트에 업로드됩니다. 단일 파일, 여러 파일 또는 폴더를 지정할 수 있습니다.
각 아티팩트에는 name 속성을 사용하여 지정하는 이름이 있습니다. 아티팩트 이름을 사용하여 나중에 워크플로에서 참조합니다. 후속 워크플로 작업은 아티팩트와 함께 작업할 수 있도록 아티팩트를 다운로드(예: 웹 사이트를 호스트하는 서버에 배포)할 수 있습니다.
actions/download-artifact 작업을 사용하여 모든 워크플로 아티팩트 다운로드:
- uses: actions/download-artifact@v3
또는 아티팩트 이름을 지정하여 특정 아티팩트만 다운로드:
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
앱 배포
앱에 대한 빌드 프로세스는 배포 가능한 아티팩트를 생성하고 업로드합니다. 이후 워크플로의 작업에서 아티팩트를 배포합니다. 앱을 배포하는 방법은 앱을 호스트하는 데 사용하는 서비스에 따라 달라집니다.
Azure App Service에 배포
완구 회사는 Azure App Service를 사용하여 웹 사이트를 호스트합니다. Bicep을 사용하여 App Service 앱을 만들고 구성할 수 있습니다. 하지만 앱을 배포해야 하는 경우 컴파일된 앱을 호스팅 인프라에 사용할 수 있는 몇 가지 옵션이 있습니다. 이러한 옵션은 App Service 데이터 플레인의 일부로 관리됩니다.
가장 일반적인 방법은 azure/webapps-deploy 작업을 사용하는 것입니다.
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
App Service에 앱을 배포하려면 몇 가지 정보를 제공해야 합니다. 이 정보에는 app-name 속성을 사용하여 지정하는 App Service 앱의 리소스 이름이 포함 됩니다. 이전 단원에서 학습한 대로 Bicep 파일에 출력을 추가하고 워크플로 변수를 사용하여 워크플로를 통해 앱 이름을 전파해야 합니다. 또한 package 속성을 사용하여 배포할 앱과 함께 .zip 파일을 지정해야 합니다. 일반적으로 워크플로 아티팩트 경로입니다.
App Service에는 배포에 사용하는 자체 데이터 플레인 인증 시스템이 있습니다. azure/webapps-deploy 작업은 인증 프로세스를 자동으로 처리합니다.
azure/webapps-deploy 작업은 워크로드 ID(
)를 사용하여 로그인한 작업의 활성 Azure 세션과 연결된 ID를 사용합니다. 작업은 배포(
)에 필요한 자격 증명을 만들고 다운로드합니다. 그런 다음 App Service 데이터 평면 API(
)와 통신할 때 배포 자격 증명을 사용합니다.
또한 App Service는 ‘배포 슬롯’을 비롯한 몇 가지 다른 배포 관련 기능을 제공합니다. 슬롯을 사용하면 가동 중지 시간 없이 새 버전의 앱을 안전하게 배포할 수 있습니다. 또한 프로덕션 트래픽을 보내기 전에 새 버전의 애플리케이션을 준비하고 가동하는 데 도움이 됩니다. 본 모듈에서는 슬롯을 사용하지 않지만 모듈 마지막 부분의 요약 페이지에서 슬롯에 대한 자세한 정보 링크를 제공합니다.
다른 Azure 서비스에 앱 배포
Azure는 앱을 호스트하기 위한 다른 많은 옵션을 제공하며, 옵션마다 배포 방식이 다릅니다.
Azure Functions는 App Service를 기반으로 하며, 앞서 설명한 것과 비슷한 배포 프로세스를 사용합니다.
가상 머신에 배포하는 경우 일반적으로 가상 머신 인스턴스에 연결하여 앱을 설치해야 합니다. Chef, Puppet 또는 Ansible과 같은 특수한 도구를 사용하여 가상 머신에 대한 배포를 오케스트레이션 해야 하는 경우도 있습니다.
Kubernetes 또는 AKS(Azure Kubernetes Service)를 사용하는 경우 일반적으로 약간 다른 방식을 사용하여 솔루션을 빌드하고 배포합니다. 앱을 빌드한 후 워크플로는 컨테이너 이미지를 만들어 컨테이너 레지스트리에 게시합니다. 그러면 Kubernetes 클러스터가 컨테이너 레지스트리에서 이미지를 읽습니다. 컨테이너 레지스트리는 컴파일된 애플리케이션을 유지하므로 일반적으로 워크플로 아티팩트를 사용하지 않습니다.
본 모듈에서는 Azure App Service를 중심으로 관련된 워크플로 개념을 설명합니다. 본 모듈 마지막 부분의 요약 페이지에서는 다른 호스팅 서비스에 배포하는 방법에 대한 자세한 정보 링크를 제공합니다.
워크플로에서 앱 테스트
이전 모듈에서는 워크플로에서 자동화된 테스트를 실행하는 경우의 가치 및 중요성에 대해 알아보았습니다. 앱 배포 시 워크플로가 앱 코드를 호출하는 테스트를 실행하는 것이 좋습니다. 이러한 테스트는 앱 또는 배포 오류로 인해 가동 중지 시간이 발생할 수 있는 위험을 줄입니다. 더 나아가, API 호출 또는 가상 트랜잭션 제출 및 모니터링과 같은 앱에 대해 테스트 사례 집합을 수행할 수도 있습니다.
많은 앱에서 ‘상태 검사 엔드포인트’를 실행합니다. 상태 검사 엔드포인트는 요청을 받으면 앱 환경에서 데이터베이스 및 네트워크 서비스에 연결할 수 있는지 확인하는 등 웹 사이트에 대해 일련의 검사를 수행합니다. 사이트에서 반환하는 응답은 앱이 정상 상태인지 여부를 나타냅니다. 개발자는 앱의 요구 사항에 맞게 상태 검사를 작성하고 사용자 지정할 수 있습니다. 앱에 상태 검사 엔드포인트가 있는 경우 배포 작업이 완료된 후 워크플로에서 모니터링하는 것이 좋습니다.
배포 워크플로
다음 연습에서는 배포 워크플로를 업데이트하여 새 작업을 추가하여 웹 사이트의 애플리케이션을 빌드하고 각 환경에 배포합니다.
