티스토리 뷰
이 시점에서 커밋이 기본 브랜치로 푸시 될 때마다 스테이징 슬롯에 코드를 배포하는 GitHub 액션에 빌드된 CI/CD 파이프라인이 있다. 이 글에서는 프로덕션 및 스테이징 슬롯을 교체하여 프로덕션 트래픽에 새 빌드를 릴리스하는 방법을 학습한다. 또한 프로덕션 트래픽의 일정 비율을 스테이징 환경으로 라우팅하여 다음 빌드가 완전히 릴리스되기 전에 테스트하는 방법도 배운다.
슬롯 교체(swap)
웹앱에 대한 Azure Portal을 연다. 왼쪽 메뉴에서 Deployment slots을 선택한다. 사이트 슬롯 목록을 보여주는 새 블레이드가 열힌다. production 및 staging 슬롯이 표시된다. 상단의 Swap 버튼을 클릭한다.
Swap 버튼은 스왑 후 발생할 구성 변경 사항을 미리 볼 수 있는 테이블을 가지는 컨텍스트 메뉴를 열어준다. 앱 설정은 환경 변수로 앱에 노출되는 key-value 구성이다. 향후 기사에서는 앱 설정에 대해 자세히 다룰 것이다. 메뉴 하단의 교체를 클릭하여 슬롯을 교체한다.
동작이 완료되어 프로덕션 사이트로 이동하면 샘플 애플리케이션이 표시된다! 이제 스테이징 슬롯에 샘플 애플리케이션이 있고 스테이징 슬롯에는 도움말 텍스트가 있는 자리 표시자 HTML 페이지가 있다.
커스텀 컨테이너에 슬롯을 사용할 수도 있다.
체크포인트
지금까지 메인 브랜치에 푸시가 발생할 때마다 GitHub 액션 워크 플로를 트리거하는 GitHub 저장소가 있다. 워크 플로는 애플리케이션을 빌드하고 사이트의 스테이징 슬롯에 배포한다. 스테이징 사이트를 사용하여 최신 변경 사항을 검증 할 수 있다. 준비가 되면 교체 버튼 (또는 CLI 명령)을 사용하여 슬롯을 교체한다.
대규모 팀에서 작업하는 경우 테스트, QA, 카나리아 테스트, A/B 테스트 등을 위한 슬롯을 만들 수 있다. 다음은 여러 슬롯의 사용 사례이다.
- 마스터 브랜치를 "testing" 슬롯에 지속적으로 배포하여 개발자가 브랜치를 pull 하지 않고 변경 사항을 쉽게 검증하고 로컬로 실행한다.
- 빌드를 QA 슬롯으로 교체하여 구성이 프로덕션 슬롯과 더 유사하도록 한다. 새로운 빌드는 QA 또는 인수(acceptance)팀에 의해 철저히 테스트된다.
- 프로덕션 트래픽의 일부에 대해 빌드를 테스트하는 staging 슬롯으로 스왑한다. 여기서의 구성은 production 슬롯과 일치해야 한다.
- production 슬롯으로 교환하여 새 빌드를 완전히 릴리즈 한다.
배포와 릴리스 간에는 암시적인 차이가 있다. 이 구분에 대한 자세한 내용은 이 문서를 참조한다.
프로덕션에서 테스트하기
프로덕션에서의 테스트는 완전한 릴리스 전에 새로운 배포를 테스트하기 위해 프로덕션 트래픽을 활용하는 일반적인 관행이다. 이것은 트래픽 쉐도우잉, 미러링 또는 카나리닝과 같은 활동을 가리키는 총칭이다. 트래픽 섀도잉과 미러링은 흥미로운 주제지긴 하지만, 이 글의 범위를 벗어난다. 나머지 섹션에서는 프로덕션에 배포하기 전에 App Service를 사용하여 새 배포를 캐너리하는 방법에 대해 설명한다.
구성
Azure Portal에서 Deployment Slots 메뉴로 이동한다. 슬롯 테이블에 Traffic %열이 표시된다. 기본적으로 모든 트래픽은 프로덕션 슬롯으로 라우팅됩니다. 스테이징 슬롯에서 트래픽 비율을 10%로 설정해본다. 그런 다음 Save를 클릭한다. 간단한 변경으로 프로덕션 트래픽의 10 분의 1이 이제 새 빌드로 이동한다! 이 방법을 "카나리아 배포" 또는 "빌드 카나리아 화" 라고 한다.
"카나리아 배포"라는 용어는 "탄광의 카나리아" 관용구에서 유래했다.
텔레메트리 태그하기
이제 일부 프로덕션 트래픽이 새 빌드로 라우팅되었으므로 배포 성공 여부를 모니터링하여 오류, 느린 코드 경로 또는 기타 예상치 못한 문제를 파악하는 것이 좋다. Application Insights, Splunk 또는 Dynatrace와 같은 애플리케이션 모니터링 도구를 사용하는 경우 스테이징 슬롯에서 오는 메트릭 및 로그에 태그를 지정하여 보고서와 대시 보드에서 데이터를 적절하게 분할 할 수 있다.
클라이언트 측 코드의 경우 슬롯은 슬롯 이름과 함께 쿠키 x-ms-routing-name을 노출한다. 이 쿠키를 검색하고 나가는 지표 또는 로그에 태그를 지정할 수 있다. 모니터링 서비스의 대시 보드에서 이 태그의 데이터를 필터링하거나 분할 할 수 있다.
서버 측 코드의 경우 슬롯은 호스트 이름과 슬롯 이름을 포함하는 환경 변수 WEBSITE_HOSTNAME을 노출한다. 클라이언트 측 쿠키와 마찬가지로 환경 변수의 값을 가져와 로그 또는 메트릭에 태그를 지정할 수 있다.
x-ms-routing-name 쿼리 매개 변수를 사용하여 클라이언트를 슬롯에 수동으로 라우팅 할 수 있다.
요약
축하한다! 이제 최신 배포를 릴리스하는 방법을 알았다. 또한 새 빌드를 완전히 출시하기 전에 프로덕션 트래픽의 일정 비율을 카나리아 테스트로 라우팅 할 수도 있다. 다음 글 에서는 인증서, 도메인, 네트워크 보안 및 고급 구성에 대해 다룰 것이다.
'Azure 기타' 카테고리의 다른 글
[특집 시리즈] Zero to Hero with App Service, 5부: Azure 앱 서비스로의 애플리케이션 마이그레이션 (0) | 2021.07.19 |
---|---|
[특집 시리즈] Zero to Hero with App Service, 4부: 커스텀 도메인 추가 및 보호 (0) | 2021.07.12 |
[특집 시리즈] Zero to Hero with App Service, 2부: 지속적인 통합과 전달 (0) | 2021.06.28 |
[특집 시리즈] Zero to Hero with App Service, 1부: 설정 (0) | 2021.06.21 |
Linux용 Windows 하위 시스템 설치 (1) | 2019.11.22 |