Azure Pipelines 및 Compute Engine으로 CI/CD 파이프라인 만들기

Last reviewed 2023-03-09 UTC

---

이 튜토리얼에서는 Azure Pipelines 및 Compute Engine을 사용하여 ASP.NET MVC 웹 애플리케이션의 지속적 통합/지속적 배포(CI/CD) 파이프라인을 만드는 방법을 설명합니다. 이 애플리케이션은 Microsoft Internet Information Services를 사용하고 Windows Server에서 실행됩니다.

CI/CD 파이프라인은 별도의 2가지 환경(테스트용 및 프로덕션용)을 사용합니다.

파이프라인 시작 부분에서 개발자는 예시 코드베이스에 대한 변경사항을 커밋합니다. 이 작업은 파이프라인을 트리거하여 애플리케이션을 빌드하고, ZIP 파일로 패키징하고, ZIP 파일을 Cloud Storage에 업로드합니다.

그런 다음 패키지는 순차적 업데이트를 사용하여 개발 환경에 자동으로 출시됩니다. 버전을 테스트한 후 출시 관리자가 프로덕션 환경에 배포되도록 버전을 승격할 수 있습니다.

이 튜토리얼은 개발자 및 DevOps 엔지니어를 대상으로 하며, 여기서는 사용자가 .NET Framework, Windows Server, IIS, Azure Pipelines, Compute Engine에 대한 기본 지식이 있다고 가정합니다. 또한 이 가이드를 진행하려면 Azure DevOps 계정에 대한 관리 액세스 권한이 있어야 합니다.

목표

• Compute Engine 관리형 인스턴스 그룹을 사용하여 롤링 배포를 구현합니다.
• Azure Pipelines에서 CI/CD 파이프라인을 설정하여 빌드, 만들기, 배포 프로세스를 조정합니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Compute Engine
• Cloud Load Balancing
• Cloud Storage

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

Azure DevOps 사용 시 부과될 수 있는 요금은 Azure DevOps 가격 책정 페이지를 참조하세요.

시작하기 전에

일반적으로 ID 및 액세스 관리(IAM) 역할 및 권한을 개별적으로 부여할 수 있도록 개발 및 프로덕션 워크로드에 별도의 프로젝트를 사용하는 것이 좋습니다. 이 튜토리얼에서는 편의상 개발, 프로덕션 환경에 대해 단일 프로젝트를 사용합니다.

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Enable the Compute Engine and Cloud Storage APIs.

   Enable the APIs

3. Make sure that billing is enabled for your Google Cloud project.

4. Azure DevOps 계정과 관리자 액세스 권한이 있어야 합니다. 아직 Azure DevOps 계정이 없는 경우 Azure DevOps 홈페이지에서 가입하면 됩니다.

참고: 명령줄 Git 클라이언트 또는 Visual Studio를 사용하여 이 가이드를 따를 수 있습니다. Visual Studio를 사용하는 경우 Azure DevOps 계정에 연결되어 있는지 확인합니다.

Azure DevOps 프로젝트 만들기

Azure DevOps를 사용하여 소스 코드를 관리하고, 빌드 및 테스트를 실행하고, Compute Engine으로의 배포를 조정합니다. 시작하려면 Azure DevOps 계정에서 새 프로젝트를 만듭니다.

1. Azure DevOps 홈페이지(https://dev.azure.com/YOUR_AZURE_DEVOPS_ACCOUNT_NAME)로 이동합니다.
2. 새 프로젝트를 클릭합니다.
3. 프로젝트 이름을 입력합니다(예: CloudDemo).
4. 표시 유형을 비공개로 설정하고 만들기를 클릭합니다.
5. 프로젝트를 만든 후 왼쪽 메뉴에서 저장소를 클릭합니다.
6. 가져오기를 클릭하여 GitHub에서 dotnet-docs-samples 저장소를 포크한 후 다음 값을 설정합니다.
   • 저장소 유형: Git
   • 클론 URL: https://github.com/GoogleCloudPlatform/dotnet-docs-samples.git

7. 가져오기를 클릭합니다.

   가져오기 프로세스가 완료되면 dotnet-docs-samples 저장소의 소스 코드가 표시됩니다.

8. 메뉴에서 Repos(저장소) > Branches(브랜치)를 클릭합니다.

9. main 브랜치 위로 마우스를 이동합니다. ... 버튼이 오른쪽에 표시됩니다.

10. ... > Set as default branch(기본 브랜치로 설정)를 클릭합니다.

지속적 빌드

이제 Azure Pipelines를 사용하여 빌드 파이프라인을 설정할 수 있습니다. Git 저장소로 푸시되는 커밋마다 Azure Pipelines는 코드를 빌드하고, 이를 ZIP 파일로 패키징하고, 결과 패키지를 내부 Azure Pipelines 스토리지에 게시합니다.

나중에 Azure Pipelines 스토리지의 패키지를 사용하여 이를 Compute Engine에 배포하는 출시 파이프라인을 구성합니다.

빌드 정의 만들기

Azure Pipelines에서 YAML 구문을 사용하는 새 빌드 정의를 만듭니다.

1. Visual Studio 또는 명령줄 git 클라이언트를 사용하여 새 Git 저장소를 클론합니다.
2. 저장소 루트에서 azure-pipelines.yml이라는 파일을 만듭니다.

3. 다음 코드를 복사하여 파일에 붙여넣습니다.

   resources:
   - repo: self
     fetchDepth: 1
   trigger:
   - main
   variables:
     artifactName: 'CloudDemo.Mvc'
   jobs:
   - job: Build
     displayName: Build application
     condition: succeeded()
     pool:
       vmImage: windows-latest
       demands:
       - msbuild
       - visualstudio
     variables:
       Solution: 'applications/clouddemo/net4/CloudDemo.Mvc.sln'
       BuildPlatform: 'Any CPU'
       BuildConfiguration: 'Release'
       ArtifactName: 'CloudDemo.Web'
     steps:
     - task: NuGetCommand@2
       displayName: 'NuGet restore'
       inputs:
         restoreSolution: '$(Solution)'
     - task: VSBuild@1
       displayName: 'Build solution'
       inputs:
         solution: '$(Solution)'
         msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"'
         platform: '$(BuildPlatform)'
         configuration: '$(BuildConfiguration)'
     - task: PublishBuildArtifacts@1
       displayName: 'Publish Artifact'
       inputs:
         PathtoPublish: '$(build.artifactstagingdirectory)/CloudDemo.Mvc.zip'
         ArtifactName: '$(ArtifactName)'
   
   

4. 모든 변경사항을 커밋하고 Azure Pipelines로 푸시합니다.

   Visual Studio

   1. 팀 탐색기를 열고 홈 아이콘을 클릭합니다.
   2. Changes(변경사항)를 클릭합니다.
   3. Add pipeline definition과 같은 커밋 메시지를 입력합니다.
   4. 모두 커밋 후 푸시를 클릭합니다.

   명령줄

   1. 수정된 모든 파일을 스테이징합니다.

      git add -A
      

   2. 로컬 저장소에 대한 변경사항을 커밋합니다.

      git commit -m "Add pipeline definition"
      

   3. Azure DevOps에 변경사항을 푸시합니다.

      git push
      

5. Azure DevOps 메뉴에서 파이프라인를 선택한 후 파이프라인 만들기를 클릭합니다.

6. Azure 저장소 Git를 선택합니다.

7. 저장소를 선택합니다.

8. 파이프라인 YAML 검토 페이지에서 실행을 클릭합니다.

   새 빌드가 트리거됩니다. 빌드가 완료되려면 2분 정도 걸릴 수 있습니다. 빌드가 끝나면 웹 애플리케이션의 모든 파일이 포함된 애플리케이션 패키지 CloudDemo.Mvc.zip을 내부 Azure Pipelines 아티팩트 스토리지 영역에서 사용할 수 있습니다.

지속적으로 배포

이제 Azure Pipelines가 커밋마다 코드를 자동으로 빌드하므로, 배포 작업에 집중할 수 있습니다.

다른 지속적 통합 시스템과 달리 Azure Pipelines는 빌드와 배포를 구분하며, 배포와 관련된 모든 태스크에 출시 관리라는 특수 도구 세트를 제공합니다.

Azure Pipelines 출시 관리는 다음과 같은 개념을 바탕으로 합니다.

• 출시는 앱의 특정 버전을 구성하고 일반적으로 빌드 프로세스의 결과인 아티팩트 집합을 의미합니다.
• 배포는 출시를 가져와서 특정 환경에 배포하는 프로세스를 의미합니다.
• 배포는 일련의 태스크을 수행하며 작업별로 그룹화할 수 있습니다.
• 단계를 사용하여 파이프라인을 세분화하고 개발 및 테스트 환경과 같은 여러 환경으로의 배포를 조정할 수 있습니다.

새 빌드가 완료될 때마다 출시 파이프라인이 트리거되도록 설정합니다. 파이프라인은 다음 3가지 단계로 구성됩니다.

1. 첫 번째 단계에서는 파이프라인이 Azure Pipelines 아티팩트 스토리지 영역에서 애플리케이션 패키지를 가져와서 Compute Engine에서 패키지에 액세스할 수 있도록 클라우드 스토리지 버킷에 게시합니다.
2. 두 번째 단계에서는 파이프라인이 순차적 업데이트를 사용하여 개발 환경을 업데이트합니다.
3. 마지막 단계에서 승인 후 파이프라인이 순차적 업데이트를 사용하여 프로덕션 환경을 업데이트합니다.

빌드 아티팩트용 Cloud Storage 버킷 만들기

애플리케이션 패키지를 저장할 Cloud Storage 버킷을 만듭니다. 나중에 새 VM 인스턴스가 이 버킷에서 애플리케이션 패키지를 자동으로 가져올 수 있도록 Compute Engine을 구성합니다.

1. Google Cloud 콘솔에서 새로 만든 프로젝트로 전환합니다.

2. Cloud Shell을 엽니다.

   Cloud Shell로 이동

3. 시간을 절약하기 위해 프로젝트 ID와 Compute Engine 영역의 기본값을 설정합니다.

   gcloud config set project PROJECT_ID
   gcloud config set compute/zone ZONE

   PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꾸고, ZONE을 리소스를 만드는 데 사용할 영역의 이름으로 바꿉니다. 어떤 영역을 선택해야 할지 잘 모르겠으면 us-central1-a를 사용하세요.

   예:

   gcloud config set project devops-test-project-12345
   gcloud config set compute/zone us-central1-a

4. 애플리케이션 패키지를 위한 새 Cloud Storage 버킷을 만듭니다.

   gsutil mb gs://$(gcloud config get-value core/project)-artifacts
   

   모든 빌드의 애플리케이션 패키지를 유지하지 않으려면 특정 기간이 지난 파일을 삭제하도록 객체 수명 주기 규칙을 구성하는 방법을 고려해 보세요.

Azure Pipelines용 서비스 계정 설정

Azure Pipelines가 Google Cloud 프로젝트에 액세스하는 데 사용할 수 있는 Google Cloud 서비스 계정을 만듭니다.

1. Azure Pipelines에서 사용할 서비스 계정을 만듭니다.

   AZURE_PIPELINES_SERVICE_ACCOUNT=$(gcloud iam service-accounts create azure-pipelines --format "value(email)")
   

2. azure-pipelines 서비스 계정에 스토리지 객체 뷰어(roles/storage.objectViewer) 및 스토리지 객체 생성자(roles/storage.objectCreator) IAM 역할을 부여하여 Azure Pipelines가 애플리케이션 패키지를 Cloud Storage에 업로드할 수 있도록 합니다.

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/storage.objectViewer
   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/storage.objectCreator
   

3. Azure Pipelines가 VM 인스턴스를 관리할 수 있도록 Compute 관리자(roles/compute.admin) 역할을 azure-pipelines 서비스 계정에 부여합니다.

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/compute.admin
   

4. 서비스 계정 키를 생성합니다.

   gcloud iam service-accounts keys create azure-pipelines-key.json \
     --iam-account=$AZURE_PIPELINES_SERVICE_ACCOUNT
   
   cat azure-pipelines-key.json | base64 -w 0;echo
   
   rm azure-pipelines-key.json
   

   다음 단계 중 하나에서 서비스 계정 키가 필요합니다.

개발 환경 구성

먼저 개발 환경을 준비해야만 Azure Pipelines에서 배포를 자동화하도록 단계를 구성할 수 있습니다. 웹 서버 VM 인스턴스를 관리할 관리형 인스턴스 그룹을 만드는 과정이 이러한 준비 작업에 포함됩니다. HTTP 부하 분산기를 만드는 과정도 포함됩니다.

1. Cloud Shell에서 관리형 인스턴스 그룹의 서비스 계정을 만듭니다.

   DEV_SERVICE_ACCOUNT=$(gcloud iam service-accounts create clouddemo-dev --format "value(email)")
   

2. VM 인스턴스가 Cloud Storage에서 애플리케이션 패키지를 다운로드할 수 있도록 서비스 계정에 스토리지 객체 뷰어 IAM 역할(roles/storage.objectViewer)을 부여합니다.

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$DEV_SERVICE_ACCOUNT \
       --role roles/storage.objectViewer
   

3. azure-pipelines 서비스 계정에 clouddemo-dev 서비스 계정 사용 권한을 부여합니다.

   gcloud iam service-accounts add-iam-policy-binding $DEV_SERVICE_ACCOUNT \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/iam.serviceAccountUser
   

4. 표준 Windows Server 2019 Core 이미지를 사용하는 인스턴스 템플릿을 만듭니다. 각 빌드에서 새 템플릿이 생성되므로, 처음에만 이 템플릿을 사용합니다.

   gcloud compute instance-templates create clouddemo-initial \
       --machine-type n1-standard-2 \
       --image-family windows-2019-core \
       --image-project windows-cloud \
       --service-account $DEV_SERVICE_ACCOUNT \
       --scopes https://www.googleapis.com/auth/devstorage.read_only \
       --tags gclb-backend
   

5. HTTP 상태 확인을 만듭니다. 애플리케이션에 전용 상태 점검 엔드포인트가 없으므로 경로 /를 쿼리할 수 있습니다.

   gcloud compute http-health-checks create clouddemo-dev-http \
       --check-interval=10s --unhealthy-threshold=10 \
       --request-path=/
   

6. 초기 인스턴스 템플릿을 기반으로 하는 관리형 인스턴스 그룹을 만듭니다. 편의를 위해 다음 명령어를 통해 영역별 관리형 인스턴스 그룹을 만듭니다. 그러나 2개 이상의 영역에 VM 인스턴스를 배포하는 지역별 관리형 인스턴스 그룹에 대해 동일한 접근 방식을 사용할 수 있습니다.

   gcloud compute instance-groups managed create clouddemo-dev \
       --template=clouddemo-initial \
       --http-health-check=clouddemo-dev-http \
       --initial-delay=2m \
       --size=1 && \
   gcloud compute instance-groups set-named-ports clouddemo-dev --named-ports http:80
   

7. 전에 만든 HTTP 상태 확인과 관리형 인스턴스 그룹을 사용하는 부하 분산기 백엔드 서비스를 만듭니다.

   gcloud compute backend-services create clouddemo-dev-backend \
       --http-health-checks clouddemo-dev-http \
       --port-name http --protocol HTTP --global && \
   gcloud compute backend-services add-backend clouddemo-dev-backend \
       --instance-group clouddemo-dev --global \
       --instance-group-zone=$(gcloud config get-value compute/zone)
   

8. 부하 분산기 프런트엔드를 만듭니다.

   gcloud compute url-maps create clouddemo-dev --default-service clouddemo-dev-backend && \
   gcloud compute target-http-proxies create clouddemo-dev-proxy --url-map=clouddemo-dev && \
   gcloud compute forwarding-rules create clouddemo-dev-fw-rule --global --target-http-proxy clouddemo-dev-proxy --ports=80
   

9. Google 부하 분산기에서 gclb-backend 태그가 있는 인스턴스에 HTTP 요청을 보낼 수 있도록 허용하는 방화벽 규칙을 만듭니다. 나중에 웹 서비스 VM 인스턴스에 이 태그를 적용합니다.

   gcloud compute firewall-rules create gclb-backend --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gclb-backend --allow tcp:80
   

프로덕션 환경 구성

프로덕션 환경을 설정하려면 개발 환경을 구성할 때와 비슷한 일련의 단계가 요구됩니다.

1. Cloud Shell에서 HTTP 상태 확인을 만듭니다.

   gcloud compute http-health-checks create clouddemo-prod-http \
       --check-interval=10s --unhealthy-threshold=10 \
       --request-path=/
   

2. 이전에 만든 초기 인스턴스 템플릿을 기반으로 하는 또 다른 관리형 인스턴스 그룹을 만듭니다.

   gcloud compute instance-groups managed create clouddemo-prod \
       --template=clouddemo-initial \
       --http-health-check=clouddemo-prod-http \
       --initial-delay=2m \
       --size=1 && \
   gcloud compute instance-groups set-named-ports clouddemo-prod --named-ports http:80
   

3. 전에 만든 HTTP 상태 확인과 관리형 인스턴스 그룹을 사용하는 부하 분산기 백엔드 서비스를 만듭니다.

   gcloud compute backend-services create clouddemo-prod-backend --http-health-checks clouddemo-prod-http --port-name http --protocol HTTP --global && \
   gcloud compute backend-services add-backend clouddemo-prod-backend --instance-group clouddemo-prod --global --instance-group-zone=$(gcloud config get-value compute/zone)
   

4. 부하 분산기 프런트엔드를 만듭니다.

   gcloud compute url-maps create clouddemo-prod --default-service clouddemo-prod-backend && \
   gcloud compute target-http-proxies create clouddemo-prod-proxy --url-map=clouddemo-prod && \
   gcloud compute forwarding-rules create clouddemo-prod-fw-rule --global --target-http-proxy clouddemo-prod-proxy --ports=80
   

출시 파이프라인 구성

새 출시 정의를 만듭니다.

1. Azure DevOps 메뉴에서 파이프라인 > 출시를 선택합니다.
2. 새 파이프라인을 클릭합니다.
3. 템플릿 목록에서 빈 작업을 선택합니다.
4. 스테이지 이름을 입력하라는 메시지가 표시되면 Publish를 입력합니다.
5. 화면 상단에서 출시 이름을 clouddemo-ComputeEngine으로 지정합니다.
6. 파이프라인 다이어그램에서 Artifacts(아티팩트) 옆에 있는 Add(추가)를 클릭합니다.

7. 빌드를 선택하고 다음 설정을 추가합니다.

   • 소스: azure-pipelines.yml 파일이 있는 Git 저장소를 선택합니다.
   • 기본 버전: Latest
   • 소스 별칭: CloudDemo.Web

8. 추가를 클릭합니다.

9. Artifact(아티팩트) 상자에서 Continuous deployment trigger(지속적 배포 트리거)(번개 아이콘)를 클릭하여 배포 트리거를 추가합니다.

10. Continuous deployment trigger(지속적 배포 트리거)에서 스위치를 Enabled(사용 설정됨)로 설정합니다.

11. Save(저장)를 클릭합니다.

12. 원하는 경우 설명을 입력한 다음 확인을 클릭하여 확인합니다.

다음과 같은 파이프라인이 표시됩니다.

Cloud Storage에 게시

출시 정의를 만들었으므로 애플리케이션 패키지를 Cloud Storage에 게시하는 단계를 추가할 수 있습니다.

1. Azure Pipelines에서 태스크 탭으로 전환합니다.
2. Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.
   • Agent pool(에이전트 풀): Azure Pipelines
   • Agent specification(에이전트 사양): ubuntu-최신
3. Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가) 을 클릭합니다.
4. bash 태스크를 선택하고 Add(추가)를 클릭합니다.

5. 새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.

   • 표시 이름: Publish to Cloud Storage
   • 유형: 인라인

   • 스크립트:

     cat << "EOF" > CloudDemo.Mvc.deploy.ps1
         $ErrorActionPreference = "Stop"
     
         # Download application package from Cloud Storage
         gsutil cp gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).zip $env:TEMP\app.zip
     
         # Install IIS
         Enable-WindowsOptionalFeature -Online -FeatureName `
             NetFx4Extended-ASPNET45, `
             IIS-WebServerRole, `
             IIS-WebServer, `
             IIS-CommonHttpFeatures, `
             IIS-HttpErrors, `
             IIS-HttpRedirect, `
             IIS-ApplicationDevelopment, `
             IIS-HealthAndDiagnostics, `
             IIS-HttpLogging, `
             IIS-LoggingLibraries, `
             IIS-RequestMonitor, `
             IIS-HttpTracing, `
             IIS-Security, `
             IIS-RequestFiltering, `
             IIS-Performance, `
             IIS-WebServerManagementTools, `
             IIS-IIS6ManagementCompatibility, `
             IIS-Metabase, `
             IIS-DefaultDocument, `
             IIS-ApplicationInit, `
             IIS-NetFxExtensibility45, `
             IIS-ISAPIExtensions, `
             IIS-ISAPIFilter, `
             IIS-ASPNET45, `
             IIS-HttpCompressionStatic
     
         # Extract application package to wwwroot
         New-Item -ItemType directory -Path $env:TEMP\app
         Add-Type -AssemblyName System.IO.Compression.FileSystem
         [System.IO.Compression.ZipFile]::ExtractToDirectory("$env:TEMP\app.zip", "$env:TEMP\app")
         Remove-Item $env:TEMP\app.zip
         Move-Item -Path $(dir -recurse $env:TEMP\app\**\PackageTmp | % { $_.FullName }) -Destination c:\inetpub\wwwroot\app -force
     
         # Configure IIS web application pool and application
         Import-Module WebAdministration
         New-WebAppPool clouddemo-net4
         Set-ItemProperty IIS:\AppPools\clouddemo-net4 managedRuntimeVersion v4.0
         New-WebApplication -Name clouddemo -Site 'Default Web Site' -PhysicalPath c:\inetpub\wwwroot\app -ApplicationPool clouddemo-net4
     
         # Grant read/execute access to the application pool user
         &icacls C:\inetpub\wwwroot\app\ /grant "IIS AppPool\clouddemo-net4:(OI)(CI)(RX)"
     EOF
     
     gcloud auth activate-service-account \
         --quiet \
         --key-file <(echo $(ServiceAccountKey) | base64 -d)
     
     gsutil cp $(System.ArtifactsDirectory)/CloudDemo.Web/CloudDemo.Web/CloudDemo.Mvc.zip gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).zip
     gsutil cp CloudDemo.Mvc.deploy.ps1 gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1
     

   이 스크립트는 다음을 수행합니다.

   1. IIS를 구성하는 시작 스크립트를 생성합니다.
   2. 환경 변수의 서비스 계정 키를 사용하여 Google Cloud에 인증하도록 Google Cloud CLI를 구성합니다.
   3. 애플리케이션 패키지 및 시작 스크립트를 Cloud Storage에 업로드합니다.

6. 변수 탭으로 전환하고 다음 변수를 추가합니다.

   이름	값	보안 비밀
   ServiceAccountKey	이전에 azure-pipelines-deployer에 대해 생성된 서비스 계정 키.	예
   CloudDemo.ProjectId	Google Cloud 프로젝트의 프로젝트 ID
   CloudDemo.Zone	gcloud config set compute/zone을 실행할 때 앞서 지정한 영역(예: us-central1-a)

7. 저장을 클릭합니다.

8. 원하는 경우 설명을 입력한 다음 확인을 클릭하여 확인합니다.

개발 환경 배포

이제 지속적 배포를 시작하기 위한 단계를 개발 환경에 추가할 수 있습니다.

1. Azure Pipelines에서 파이프라인 탭으로 전환합니다.
2. 단계 상자에서 추가 > 새 단계를 선택합니다.
3. 템플릿 목록에서 빈 작업을 선택합니다.
4. 스테이지 이름을 입력하라는 메시지가 표시되면 Dev를 입력합니다.
5. 새로 만든 스테이지의 번개 아이콘을 클릭합니다.

6. 다음 설정을 구성합니다.

   • 트리거 선택: After stage
   • 스테이지: Publish

7. 태스크 탭 위로 마우스 커서를 가져간 다음 태스크 > Dev를 클릭합니다.

8. Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.

   • Agent pool(에이전트 풀): Azure Pipelines
   • Agent specification(에이전트 사양): ubuntu-최신

9. Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가) 을 클릭합니다.

10. bash 태스크를 선택하고 Add(추가)를 클릭합니다.

11. 새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.

    • 표시 이름: Rolling deploy
    • 유형: 인라인

    • 스크립트:

      INSTANCE_TEMPLATE=clouddemo-$(Build.BuildId)-$(Release.ReleaseId)
      
      gcloud auth activate-service-account \
          --quiet \
          --key-file <(echo $(ServiceAccountKey) | base64 -d)
      
      gcloud compute instance-templates create $INSTANCE_TEMPLATE \
        --machine-type n1-standard-2 \
        --image-family windows-2019-core \
        --image-project windows-cloud \
        --service-account clouddemo-dev@$(CloudDemo.ProjectId).iam.gserviceaccount.com \
        --scopes https://www.googleapis.com/auth/devstorage.read_only \
        --tags gclb-backend \
        --metadata sysprep-specialize-script-url=gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1 \
        --project $(CloudDemo.ProjectId) \
      
      gcloud compute instance-groups managed set-instance-template clouddemo-dev \
        --template $INSTANCE_TEMPLATE \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      
      gcloud compute instance-groups managed rolling-action start-update clouddemo-dev \
        --version template=$INSTANCE_TEMPLATE \
        --type proactive \
        --max-unavailable 0 \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      

    이 스크립트는 다음을 수행합니다.

    1. 환경 변수의 서비스 계정 키를 사용하여 Google Cloud에 인증하도록 Google Cloud CLI를 구성합니다.
    2. 이전 단계에서 생성된 시작 스크립트를 사용하는 새 인스턴스 템플릿을 만듭니다.
    3. 새 인스턴스 템플릿을 사용하도록 기존 인스턴스 그룹을 업데이트합니다. 아직은 이 명령어로 인해 기존 VM이 바뀌거나 업데이트되지는 않습니다. 그 대신 이 인스턴스 그룹의 이후 VM이 새 템플릿에서 만들어집니다.
    4. 순차적 업데이트를 시작하여 기존 인스턴스 그룹에서 기존 VM이 롤링 방식으로 새 VM으로 바뀝니다.

12. 저장을 클릭합니다.

13. 원하는 경우 설명을 입력하고 확인을 클릭하여 확인합니다.

프로덕션 환경 배포

마지막으로 프로덕션 환경에 대한 배포를 구성해야 합니다.

1. Azure Pipelines에서 파이프라인 탭으로 전환합니다.
2. 단계 상자에서 추가 > 새 단계를 선택합니다.
3. 템플릿 목록에서 빈 작업을 선택합니다.
4. 스테이지 이름을 입력하라는 메시지가 표시되면 Prod를 입력합니다.
5. 새로 만든 스테이지의 번개 아이콘을 클릭합니다.

6. 다음 설정을 구성합니다.

   • 트리거 선택: After stage
   • 스테이지: Dev
   • 사전 배포 승인: (사용 설정됨)
   • 승인자: 자신의 사용자 이름 선택

7. 태스크 탭 위로 마우스 커서를 가져간 다음 태스크 > 프로덕션을 클릭합니다.

8. Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.

   • Agent pool(에이전트 풀): Azure Pipelines
   • Agent specification(에이전트 사양): ubuntu-최신

9. Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가) 을 클릭하여 단계(phase)에 단계를 추가합니다.

10. bash 태스크를 선택하고 Add(추가)를 클릭합니다.

11. 새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.

    • 표시 이름: Rolling deploy
    • 유형: 인라인

    • 스크립트:

      INSTANCE_TEMPLATE=clouddemo-$(Build.BuildId)-$(Release.ReleaseId)
      
      gcloud auth activate-service-account \
          --quiet \
          --key-file <(echo $(ServiceAccountKey) | base64 -d)
      
      gcloud compute instance-templates create $INSTANCE_TEMPLATE \
        --machine-type n1-standard-2 \
        --image-family windows-2019-core \
        --image-project windows-cloud \
        --service-account clouddemo-prod@$(CloudDemo.ProjectId).iam.gserviceaccount.com \
        --scopes https://www.googleapis.com/auth/devstorage.read_only \
        --tags gclb-backend \
        --metadata sysprep-specialize-script-url=gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1 \
        --project $(CloudDemo.ProjectId) \
      
      gcloud compute instance-groups managed set-instance-template clouddemo-prod \
        --template $INSTANCE_TEMPLATE \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      
      gcloud compute instance-groups managed rolling-action start-update clouddemo-prod \
        --version template=$INSTANCE_TEMPLATE \
        --type proactive \
        --max-unavailable 0 \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      

12. 저장을 클릭합니다.

13. 원하는 경우 설명을 입력하고 확인을 클릭하여 확인합니다.

파이프라인 실행하기

이제 전체 파이프라인을 구성했으므로 소스 코드 변경을 수행하여 파이프라인을 테스트할 수 있습니다.

1. 로컬 컴퓨터에서 이전에 클론한 Git 저장소의 applications\clouddemo\net4\CloudDemo.Mvc\Views\Home\Index.cshtml 파일을 엽니다.
2. ViewBag.Title 값을 Home Page에서 This app runs on GKE로 변경합니다.

3. 변경사항을 커밋한 다음 Azure Pipelines로 푸시합니다.

   Visual Studio

   1. 팀 탐색기를 열고 홈 아이콘을 클릭합니다.
   2. Changes(변경사항)를 클릭합니다.
   3. Change site title과 같은 커밋 메시지를 입력합니다.
   4. 모두 커밋 후 푸시를 클릭합니다.

   명령줄

   1. 수정된 모든 파일을 스테이징합니다.

      git add -A
      

   2. 로컬 저장소에 대한 변경사항을 커밋합니다.

      git commit -m "Change site title"
      

   3. 변경사항을 Azure Pipelines로 푸시합니다.

      git push
      

4. Azure DevOps 메뉴에서 파이프라인을 선택합니다.

   빌드가 트리거됩니다.

5. 빌드가 완료되면 Pipelines(파이프라인) > Releases(출시)를 선택합니다. 출시 프로세스가 시작됩니다.

6. Release-1을 클릭하여 세부정보 페이지를 열고 Dev 스테이지의 상태가 성공으로 전환될 때까지 기다립니다.

7. Google Cloud console에서 네트워크 서비스 > 부하 분산 > clouddemo-dev를 선택합니다.

   프런트엔드의 IP 주소를 기록합니다.

8. 새 브라우저 창을 열고 다음 주소로 이동합니다.

   http://IP_ADDRESS/clouddemo/
   

   여기서 IP_ADDRESS는 프런트엔드의 IP 주소입니다.

   애플리케이션이 배포되었고 커스텀 제목을 사용하고 있는지 확인합니다.

   부하 분산기를 사용할 수 있게 될 때까지 몇 분이 걸리므로, 처음에는 오류가 표시될 수 있습니다.

9. Azure Pipelines에서 Prod(프로덕션) 단계 아래의 Approve(승인) 버튼을 클릭하여 배포를 프로덕션 환경으로 승격합니다.

   버튼이 보이지 않는 경우 먼저 이전 출시를 승인 또는 거부해야 할 수 있습니다.

10. 원하는 경우 설명을 입력한 다음 Approve(승인)를 클릭하여 확인합니다.

11. Prod(프로덕션) 환경의 상태가 Succeeded(성공)로 전환될 때까지 기다립니다.

12. Google Cloud console에서 네트워크 서비스 > 부하 분산 > clouddemo-prod를 선택합니다.

    프런트엔드의 IP 주소를 기록합니다.

13. 새 브라우저 창을 열고 다음 주소로 이동합니다.

    http://IP_ADDRESS/clouddemo/
    

    여기서 IP_ADDRESS는 프런트엔드의 IP 주소입니다.

    애플리케이션이 배포되었고 커스텀 제목을 사용하고 있는지 확인합니다.

삭제

이 튜토리얼을 완료한 후에 추가 비용이 발생하지 않도록 하려면 만든 항목을 삭제하세요.

Azure Pipelines 프로젝트 삭제

Azure Pipelines 프로젝트를 삭제하려면 Azure DevOps 서비스 문서를 참조하세요. Azure Pipelines 프로젝트를 삭제하면 모든 소스 코드 변경사항도 손실됩니다.

Google Cloud 개발 및 프로덕션 프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

• 프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

다음 단계

• 이미지 관리 권장사항 읽어보기
• Compute Engine에 고가용성 SQL Server 그룹 배포 방법 알아보기
• Google Cloud Platform에서 사용하는 .NET에 대해 읽어보기
• Visual Studio용 Cloud Tools 설치
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기