이 튜토리얼에서는 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 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
Azure DevOps 사용 시 부과될 수 있는 요금은 Azure DevOps 가격 책정 페이지를 참조하세요.
시작하기 전에
일반적으로 ID 및 액세스 관리(IAM) 역할 및 권한을 개별적으로 부여할 수 있도록 개발 및 프로덕션 워크로드에 별도의 프로젝트를 사용하는 것이 좋습니다. 이 튜토리얼에서는 편의상 개발, 프로덕션 환경에 대해 단일 프로젝트를 사용합니다.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Enable the Compute Engine and Cloud Storage APIs.
- Azure DevOps 계정과 관리자 액세스 권한이 있어야 합니다. 아직 Azure DevOps 계정이 없는 경우 Azure DevOps 홈페이지에서 가입하면 됩니다.
Azure DevOps 프로젝트 만들기
Azure DevOps를 사용하여 소스 코드를 관리하고, 빌드 및 테스트를 실행하고, Compute Engine으로의 배포를 조정합니다. 시작하려면 Azure DevOps 계정에서 새 프로젝트를 만듭니다.
- Azure DevOps 홈페이지(https://dev.azure.com/YOUR_AZURE_DEVOPS_ACCOUNT_NAME)로 이동합니다.
- 새 프로젝트를 클릭합니다.
- 프로젝트 이름을 입력합니다(예:
CloudDemo
). - 표시 유형을 비공개로 설정하고 만들기를 클릭합니다.
- 프로젝트를 만든 후 왼쪽 메뉴에서 저장소를 클릭합니다.
- 가져오기를 클릭하여 GitHub에서
dotnet-docs-samples
저장소를 포크한 후 다음 값을 설정합니다.- 저장소 유형:
Git
- 클론 URL:
https://github.com/GoogleCloudPlatform/dotnet-docs-samples.git
- 저장소 유형:
가져오기를 클릭합니다.
가져오기 프로세스가 완료되면
dotnet-docs-samples
저장소의 소스 코드가 표시됩니다.메뉴에서 Repos(저장소) > Branches(브랜치)를 클릭합니다.
main
브랜치 위로 마우스를 이동합니다. ... 버튼이 오른쪽에 표시됩니다.... > Set as default branch(기본 브랜치로 설정)를 클릭합니다.
지속적 빌드
이제 Azure Pipelines를 사용하여 빌드 파이프라인을 설정할 수 있습니다. Git 저장소로 푸시되는 커밋마다 Azure Pipelines는 코드를 빌드하고, 이를 ZIP 파일로 패키징하고, 결과 패키지를 내부 Azure Pipelines 스토리지에 게시합니다.
나중에 Azure Pipelines 스토리지의 패키지를 사용하여 이를 Compute Engine에 배포하는 출시 파이프라인을 구성합니다.
빌드 정의 만들기
Azure Pipelines에서 YAML 구문을 사용하는 새 빌드 정의를 만듭니다.
- Visual Studio 또는 명령줄
git
클라이언트를 사용하여 새 Git 저장소를 클론합니다. - 저장소 루트에서
azure-pipelines.yml
이라는 파일을 만듭니다. 다음 코드를 복사하여 파일에 붙여넣습니다.
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)'
모든 변경사항을 커밋하고 Azure Pipelines로 푸시합니다.
Visual Studio
- 팀 탐색기를 열고 홈 아이콘을 클릭합니다.
- Changes(변경사항)를 클릭합니다.
Add pipeline definition
과 같은 커밋 메시지를 입력합니다.- 모두 커밋 후 푸시를 클릭합니다.
명령줄
수정된 모든 파일을 스테이징합니다.
git add -A
로컬 저장소에 대한 변경사항을 커밋합니다.
git commit -m "Add pipeline definition"
Azure DevOps에 변경사항을 푸시합니다.
git push
Azure DevOps 메뉴에서 파이프라인를 선택한 후 파이프라인 만들기를 클릭합니다.
Azure 저장소 Git를 선택합니다.
저장소를 선택합니다.
파이프라인 YAML 검토 페이지에서 실행을 클릭합니다.
새 빌드가 트리거됩니다. 빌드가 완료되려면 2분 정도 걸릴 수 있습니다. 빌드가 끝나면 웹 애플리케이션의 모든 파일이 포함된 애플리케이션 패키지
CloudDemo.Mvc.zip
을 내부 Azure Pipelines 아티팩트 스토리지 영역에서 사용할 수 있습니다.
지속적으로 배포
이제 Azure Pipelines가 커밋마다 코드를 자동으로 빌드하므로, 배포 작업에 집중할 수 있습니다.
다른 지속적 통합 시스템과 달리 Azure Pipelines는 빌드와 배포를 구분하며, 배포와 관련된 모든 태스크에 출시 관리라는 특수 도구 세트를 제공합니다.
Azure Pipelines 출시 관리는 다음과 같은 개념을 바탕으로 합니다.
- 출시는 앱의 특정 버전을 구성하고 일반적으로 빌드 프로세스의 결과인 아티팩트 집합을 의미합니다.
- 배포는 출시를 가져와서 특정 환경에 배포하는 프로세스를 의미합니다.
- 배포는 일련의 태스크을 수행하며 작업별로 그룹화할 수 있습니다.
- 단계를 사용하여 파이프라인을 세분화하고 개발 및 테스트 환경과 같은 여러 환경으로의 배포를 조정할 수 있습니다.
새 빌드가 완료될 때마다 출시 파이프라인이 트리거되도록 설정합니다. 파이프라인은 다음 3가지 단계로 구성됩니다.
- 첫 번째 단계에서는 파이프라인이 Azure Pipelines 아티팩트 스토리지 영역에서 애플리케이션 패키지를 가져와서 Compute Engine에서 패키지에 액세스할 수 있도록 클라우드 스토리지 버킷에 게시합니다.
- 두 번째 단계에서는 파이프라인이 순차적 업데이트를 사용하여 개발 환경을 업데이트합니다.
- 마지막 단계에서 승인 후 파이프라인이 순차적 업데이트를 사용하여 프로덕션 환경을 업데이트합니다.
빌드 아티팩트용 Cloud Storage 버킷 만들기
애플리케이션 패키지를 저장할 Cloud Storage 버킷을 만듭니다. 나중에 새 VM 인스턴스가 이 버킷에서 애플리케이션 패키지를 자동으로 가져올 수 있도록 Compute Engine을 구성합니다.
- Google Cloud 콘솔에서 새로 만든 프로젝트로 전환합니다.
Cloud Shell을 엽니다.
시간을 절약하기 위해 프로젝트 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
애플리케이션 패키지를 위한 새 Cloud Storage 버킷을 만듭니다.
gsutil mb gs://$(gcloud config get-value core/project)-artifacts
모든 빌드의 애플리케이션 패키지를 유지하지 않으려면 특정 기간이 지난 파일을 삭제하도록 객체 수명 주기 규칙을 구성하는 방법을 고려해 보세요.
Azure Pipelines용 서비스 계정 설정
Azure Pipelines가 Google Cloud 프로젝트에 액세스하는 데 사용할 수 있는 Google Cloud 서비스 계정을 만듭니다.
Azure Pipelines에서 사용할 서비스 계정을 만듭니다.
AZURE_PIPELINES_SERVICE_ACCOUNT=$(gcloud iam service-accounts create azure-pipelines --format "value(email)")
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
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
서비스 계정 키를 생성합니다.
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 부하 분산기를 만드는 과정도 포함됩니다.
Cloud Shell에서 관리형 인스턴스 그룹의 서비스 계정을 만듭니다.
DEV_SERVICE_ACCOUNT=$(gcloud iam service-accounts create clouddemo-dev --format "value(email)")
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
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
표준 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
HTTP 상태 확인을 만듭니다. 애플리케이션에 전용 상태 점검 엔드포인트가 없으므로 경로
/
를 쿼리할 수 있습니다.gcloud compute http-health-checks create clouddemo-dev-http \ --check-interval=10s --unhealthy-threshold=10 \ --request-path=/
초기 인스턴스 템플릿을 기반으로 하는 관리형 인스턴스 그룹을 만듭니다. 편의를 위해 다음 명령어를 통해 영역별 관리형 인스턴스 그룹을 만듭니다. 그러나 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
전에 만든 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)
부하 분산기 프런트엔드를 만듭니다.
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
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
프로덕션 환경 구성
프로덕션 환경을 설정하려면 개발 환경을 구성할 때와 비슷한 일련의 단계가 요구됩니다.
Cloud Shell에서 HTTP 상태 확인을 만듭니다.
gcloud compute http-health-checks create clouddemo-prod-http \ --check-interval=10s --unhealthy-threshold=10 \ --request-path=/
이전에 만든 초기 인스턴스 템플릿을 기반으로 하는 또 다른 관리형 인스턴스 그룹을 만듭니다.
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
전에 만든 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)
부하 분산기 프런트엔드를 만듭니다.
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
출시 파이프라인 구성
새 출시 정의를 만듭니다.
- Azure DevOps 메뉴에서 파이프라인 > 출시를 선택합니다.
- 새 파이프라인을 클릭합니다.
- 템플릿 목록에서 빈 작업을 선택합니다.
- 스테이지 이름을 입력하라는 메시지가 표시되면
Publish
를 입력합니다. - 화면 상단에서 출시 이름을
clouddemo-ComputeEngine
으로 지정합니다. - 파이프라인 다이어그램에서 Artifacts(아티팩트) 옆에 있는 Add(추가)를 클릭합니다.
빌드를 선택하고 다음 설정을 추가합니다.
- 소스:
azure-pipelines.yml
파일이 있는 Git 저장소를 선택합니다. - 기본 버전:
Latest
- 소스 별칭:
CloudDemo.Web
- 소스:
추가를 클릭합니다.
Artifact(아티팩트) 상자에서 Continuous deployment trigger(지속적 배포 트리거)(번개 아이콘)를 클릭하여 배포 트리거를 추가합니다.
Continuous deployment trigger(지속적 배포 트리거)에서 스위치를 Enabled(사용 설정됨)로 설정합니다.
Save(저장)를 클릭합니다.
원하는 경우 설명을 입력한 다음 확인을 클릭하여 확인합니다.
다음과 같은 파이프라인이 표시됩니다.
Cloud Storage에 게시
출시 정의를 만들었으므로 애플리케이션 패키지를 Cloud Storage에 게시하는 단계를 추가할 수 있습니다.
- Azure Pipelines에서 태스크 탭으로 전환합니다.
- Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.
- Agent pool(에이전트 풀): Azure Pipelines
- Agent specification(에이전트 사양): ubuntu-최신
- Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가) 을 클릭합니다.
- bash 태스크를 선택하고 Add(추가)를 클릭합니다.
새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.
- 표시 이름:
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
이 스크립트는 다음을 수행합니다.
- IIS를 구성하는 시작 스크립트를 생성합니다.
- 환경 변수의 서비스 계정 키를 사용하여 Google Cloud에 인증하도록 Google Cloud CLI를 구성합니다.
- 애플리케이션 패키지 및 시작 스크립트를 Cloud Storage에 업로드합니다.
- 표시 이름:
변수 탭으로 전환하고 다음 변수를 추가합니다.
이름 값 보안 비밀 ServiceAccountKey
이전에 azure-pipelines-deployer
에 대해 생성된 서비스 계정 키.예 CloudDemo.ProjectId
Google Cloud 프로젝트의 프로젝트 ID CloudDemo.Zone
gcloud config set compute/zone
을 실행할 때 앞서 지정한 영역(예:us-central1-a
)저장을 클릭합니다.
원하는 경우 설명을 입력한 다음 확인을 클릭하여 확인합니다.
개발 환경 배포
이제 지속적 배포를 시작하기 위한 단계를 개발 환경에 추가할 수 있습니다.
- Azure Pipelines에서 파이프라인 탭으로 전환합니다.
- 단계 상자에서 추가 > 새 단계를 선택합니다.
- 템플릿 목록에서 빈 작업을 선택합니다.
- 스테이지 이름을 입력하라는 메시지가 표시되면
Dev
를 입력합니다. - 새로 만든 스테이지의 번개 아이콘을 클릭합니다.
다음 설정을 구성합니다.
- 트리거 선택:
After stage
- 스테이지:
Publish
- 트리거 선택:
태스크 탭 위로 마우스 커서를 가져간 다음 태스크 > Dev를 클릭합니다.
Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.
- Agent pool(에이전트 풀): Azure Pipelines
- Agent specification(에이전트 사양): ubuntu-최신
Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가)
을 클릭합니다.bash 태스크를 선택하고 Add(추가)를 클릭합니다.
새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.
- 표시 이름:
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)
이 스크립트는 다음을 수행합니다.
- 환경 변수의 서비스 계정 키를 사용하여 Google Cloud에 인증하도록 Google Cloud CLI를 구성합니다.
- 이전 단계에서 생성된 시작 스크립트를 사용하는 새 인스턴스 템플릿을 만듭니다.
- 새 인스턴스 템플릿을 사용하도록 기존 인스턴스 그룹을 업데이트합니다. 아직은 이 명령어로 인해 기존 VM이 바뀌거나 업데이트되지는 않습니다. 그 대신 이 인스턴스 그룹의 이후 VM이 새 템플릿에서 만들어집니다.
- 순차적 업데이트를 시작하여 기존 인스턴스 그룹에서 기존 VM이 롤링 방식으로 새 VM으로 바뀝니다.
- 표시 이름:
저장을 클릭합니다.
원하는 경우 설명을 입력하고 확인을 클릭하여 확인합니다.
프로덕션 환경 배포
마지막으로 프로덕션 환경에 대한 배포를 구성해야 합니다.
- Azure Pipelines에서 파이프라인 탭으로 전환합니다.
- 단계 상자에서 추가 > 새 단계를 선택합니다.
- 템플릿 목록에서 빈 작업을 선택합니다.
- 스테이지 이름을 입력하라는 메시지가 표시되면
Prod
를 입력합니다. - 새로 만든 스테이지의 번개 아이콘을 클릭합니다.
다음 설정을 구성합니다.
- 트리거 선택:
After stage
- 스테이지:
Dev
- 사전 배포 승인: (사용 설정됨)
- 승인자: 자신의 사용자 이름 선택
- 트리거 선택:
태스크 탭 위로 마우스 커서를 가져간 다음 태스크 > 프로덕션을 클릭합니다.
Agent job(에이전트 작업)을 클릭하고 다음 설정을 구성합니다.
- Agent pool(에이전트 풀): Azure Pipelines
- Agent specification(에이전트 사양): ubuntu-최신
Agent job(에이전트 작업) 옆의 Add a task to agent job(에이전트 작업에 태스크 추가)
을 클릭하여 단계(phase)에 단계를 추가합니다.bash 태스크를 선택하고 Add(추가)를 클릭합니다.
새로 추가된 작업을 클릭하고 다음 설정을 구성합니다.
- 표시 이름:
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)
- 표시 이름:
저장을 클릭합니다.
원하는 경우 설명을 입력하고 확인을 클릭하여 확인합니다.
파이프라인 실행하기
이제 전체 파이프라인을 구성했으므로 소스 코드 변경을 수행하여 파이프라인을 테스트할 수 있습니다.
- 로컬 컴퓨터에서 이전에 클론한 Git 저장소의
applications\clouddemo\net4\CloudDemo.Mvc\Views\Home\Index.cshtml
파일을 엽니다. ViewBag.Title
값을Home Page
에서This app runs on GKE
로 변경합니다.변경사항을 커밋한 다음 Azure Pipelines로 푸시합니다.
Visual Studio
- 팀 탐색기를 열고 홈 아이콘을 클릭합니다.
- Changes(변경사항)를 클릭합니다.
Change site title
과 같은 커밋 메시지를 입력합니다.- 모두 커밋 후 푸시를 클릭합니다.
명령줄
수정된 모든 파일을 스테이징합니다.
git add -A
로컬 저장소에 대한 변경사항을 커밋합니다.
git commit -m "Change site title"
변경사항을 Azure Pipelines로 푸시합니다.
git push
Azure DevOps 메뉴에서 파이프라인을 선택합니다.
빌드가 트리거됩니다.
빌드가 완료되면 Pipelines(파이프라인) > Releases(출시)를 선택합니다. 출시 프로세스가 시작됩니다.
Release-1을 클릭하여 세부정보 페이지를 열고 Dev 스테이지의 상태가 성공으로 전환될 때까지 기다립니다.
Google Cloud console에서 네트워크 서비스 > 부하 분산 > clouddemo-dev를 선택합니다.
프런트엔드의 IP 주소를 기록합니다.
새 브라우저 창을 열고 다음 주소로 이동합니다.
http://IP_ADDRESS/clouddemo/
여기서
IP_ADDRESS
는 프런트엔드의 IP 주소입니다.애플리케이션이 배포되었고 커스텀 제목을 사용하고 있는지 확인합니다.
부하 분산기를 사용할 수 있게 될 때까지 몇 분이 걸리므로, 처음에는 오류가 표시될 수 있습니다.
Azure Pipelines에서 Prod(프로덕션) 단계 아래의 Approve(승인) 버튼을 클릭하여 배포를 프로덕션 환경으로 승격합니다.
버튼이 보이지 않는 경우 먼저 이전 출시를 승인 또는 거부해야 할 수 있습니다.
원하는 경우 설명을 입력한 다음 Approve(승인)를 클릭하여 확인합니다.
Prod(프로덕션) 환경의 상태가 Succeeded(성공)로 전환될 때까지 기다립니다.
Google Cloud console에서 네트워크 서비스 > 부하 분산 > clouddemo-prod를 선택합니다.
프런트엔드의 IP 주소를 기록합니다.
새 브라우저 창을 열고 다음 주소로 이동합니다.
http://IP_ADDRESS/clouddemo/
여기서
IP_ADDRESS
는 프런트엔드의 IP 주소입니다.애플리케이션이 배포되었고 커스텀 제목을 사용하고 있는지 확인합니다.
삭제
이 튜토리얼을 완료한 후에 추가 비용이 발생하지 않도록 하려면 만든 항목을 삭제하세요.
Azure Pipelines 프로젝트 삭제
Azure Pipelines 프로젝트를 삭제하려면 Azure DevOps 서비스 문서를 참조하세요. Azure Pipelines 프로젝트를 삭제하면 모든 소스 코드 변경사항도 손실됩니다.
Google Cloud 개발 및 프로덕션 프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- 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 아키텍처 센터 살펴보기