Azure Container Apps에서 변경 내용 업데이트 및 배포
클라우드에서 컨테이너화된 애플리케이션을 개발할 때 변경 관리가 어려울 수 있습니다. 결국 고객에게 필요한 것은 변경 내용을 추적하고, 가동 시간을 보장하며, 롤백을 원활하게 처리하는 메커니즘을 제공하는 지원입니다.
Azure Container Apps의 변경 관리는 각 컨테이너 앱 버전의 스냅샷인 수정 버전으로 구동됩니다.
수정 버전의 주요 특징은 다음과 같습니다.
변경 불가능: 일단 설정된 수정 버전은 변경할 수 없습니다.
버전 관리: 수정 버전은 컨테이너 앱 버전의 레코드 역할을 하며, 다양한 단계에서 컨테이너 앱의 상태를 캡처합니다.
자동 프로비전: 컨테이너 앱을 처음으로 배포하면 초기 수정 버전이 자동으로 만들어집니다.
변경 범위 제한: 수정 버전은 정적 상태로 유지되지만, 애플리케이션 범위 변경 내용은 모든 수정 버전에 영향을 줄 수 있으며 수정 버전 범위 변경 내용은 새 수정 버전을 만듭니다.
기록 레코드: 기본적으로 비활성 수정 버전 100개에 액세스할 수 있지만 이 임계값을 수동으로 조정할 수 있습니다.
여러 수정 버전: 여러 수정 버전을 동시에 실행할 수 있습니다. 이 기능은 다른 버전의 앱을 동시에 관리해야 하는 경우에 특히 유용합니다.
수명 주기
각 수정 버전은 상태와 가용성의 영향을 받는 특정 상태를 거칩니다. 수명 주기 동안 컨테이너 앱은 프로비전하는 중, 실행 중 및 비활성 상태를 거칩니다.
프로비전 상태
새 수정 버전을 만들면 컨테이너 앱은 시작 및 준비 상태 검사를 거칩니다. 이 단계에서 프로비전 상태는 컨테이너 앱의 진행률을 추적하는 가이드 역할을 합니다.
| 상태 | 설명 |
|---|---|
| 프로비전 | 수정 버전이 확인 프로세스 중에 있습니다. |
| 프로비전됨 | 수정 버전이 모든 검사를 통과했습니다. |
| 프로비전 실패로 표시됩니다. | 수정 버전을 확인하는 중에 문제가 발생했습니다. |
실행 상태
컨테이너 앱이 성공적으로 프로비전되면 수정 버전이 운영 단계로 들어갑니다. 실행 상태는 컨테이너 앱의 상태와 기능을 모니터링하는 데 도움이 됩니다.
| 상태 | 설명 |
|---|---|
| 프로비전 | 수정 버전이 확인 프로세스 중에 있습니다. |
| 0으로 스케일링 | 실행 중인 복제본이 0개이고, 새 복제본을 프로비전하지 않습니다. 스케일링 규칙이 트리거되면 컨테이너 앱이 새 복제본을 만들 수 있습니다. |
| 활성화 중 | 실행 중인 복제본이 0개이고, 프로비전 중인 복제본이 하나 있습니다. |
| 활성화 실패 | 첫 번째 복제본을 프로비전하지 못했습니다. |
| 스케일링 중/처리 중 | 스케일 인 또는 스케일 아웃이 발생 중입니다. 다른 복제본이 프로비전되는 동안 하나 이상의 복제본이 실행 중입니다. |
| 실행 중 | 하나 이상의 복제본이 실행 중입니다. 보고할 문제가 없습니다. |
| 실행 중(최대) | 최대 수량(수정 버전의 스케일링 규칙에 따라)의 복제본이 실행 중입니다. 보고할 문제가 없습니다. |
| 프로비전 해제 | 수정 버전이 활성에서 비활성으로 전환 중이며, 만든 리소스를 제거합니다. |
| 성능 저하됨 | 수정 버전의 복제본 중 하나 이상이 실패 상태입니다. 특정 문제에 대한 실행 상태 세부 정보를 확인하세요. |
| 실패함 | 심각한 오류로 인해 수정 버전이 실패했습니다. 실행 상태는 세부 정보를 제공합니다. 일반적인 원인은 다음과 같습니다. • 종료 • 종료 코드 137 |
비활성 상태
수정 버전이 비활성 상태로 전환될 수도 있습니다. 이러한 수정 버전은 프로비전 중 또는 실행 중 상태가 되지 없습니다. 그러나 Azure Container Apps는 이러한 수정 버전 목록을 유지 관리하여, 비활성 항목을 최대 100개까지 수용합니다. 언제든지 수정 버전을 활성화할 수 있습니다.
비활성 수정 버전 제한 변경
containerapp create 또는 containerapp update 명령에서 --max-inactive-revisions 매개 변수를 사용하여 Container Apps가 추적하는 비활성 수정 버전 수를 제어할 수 있습니다.
이 예제에서는 비활성 수정 버전 50개를 추적하는 새 컨테이너 앱을 만드는 방법을 보여줍니다.
az containerapp create --max-inactive-revisions 50
수정 모드
Azure Container Apps는 두 가지 수정 버전 모드를 지원합니다. 선택하는 모드에 따라 동시에 활성화되는 앱의 수정 버전 수가 결정됩니다.
| 수정 모드 | 설명 | 기본값 |
|---|---|---|
| 단일 | 새 수정 버전은 자동으로 프로비전되고, 활성화되고, 원하는 크기로 스케일링됩니다. 모든 복제본이 스케일링 규칙에 정의된 대로 실행 중이면 트래픽이 이전 버전에서 새 버전으로 전환됩니다. 업데이트가 실패하면 트래픽이 이전 수정 버전을 가리키는 상태로 유지됩니다. 이전 수정 버전은 자동으로 프로비전 해제됩니다. | 예 |
| 여러 | 활성 수정 버전을 여러 개 만들고, 수정 버전 간에 트래픽을 분할하고, 이전 수정 버전을 프로비전 해제하는 시기를 선택할 수 있습니다. 이 수준의 제어는 앱의 여러 버전을 테스트하거나, 파란색-녹색 테스트를 수행하거나, 앱 업데이트를 완전히 제어하는 데 유용합니다. 자세한 내용은 트래픽 분할을 참조하세요. |
레이블
외부 HTTP 트래픽이 있는 컨테이너 앱의 경우 레이블은 트래픽을 특정 수정 버전으로 전달합니다. 레이블은 레이블이 할당된 수정 버전으로 트래픽을 라우팅하는 데 사용할 수 있는 고유한 URL을 제공합니다.
수정 버전 간에 트래픽을 전환하려면 레이블을 수정 버전 간에 이동할 수 있습니다.
- 레이블은 수정 버전 간에 이동할 때 동일한 URL을 유지합니다.
- 레이블은 한 번에 하나의 수정 버전에만 적용할 수 있습니다.
- 레이블이 있는 수정 버전에는 트래픽 분할에 대한 할당이 필요하지 않습니다.
- 레이블은 앱이 다중 수정 모드인 경우에 가장 유용합니다.
- 레이블, 트래픽 분할 또는 둘 다를 사용하도록 설정할 수 있습니다.
레이블은 새 수정 버전을 테스트하는 데 유용합니다. 예를 들어 테스트 사용자 집합에 대한 액세스 권한을 부여하려는 경우 레이블의 URL을 제공할 수 있습니다. 그런 다음 사용자를 다른 수정 버전으로 이동하려는 경우 레이블을 해당 수정 버전으로 이동할 수 있습니다.
레이블은 트래픽 분할과 독립적으로 작동합니다. 트래픽 분할은 트래픽 비율에 따라 컨테이너 앱의 애플리케이션 URL로 가는 트래픽을 수정 버전으로 분산합니다. 트래픽이 레이블의 URL로 전달되면 트래픽은 하나의 특정 수정 버전으로 라우팅됩니다.
레이블 이름은 다음과 같아야 합니다.
- 소문자 영숫자 또는 대시(
-)로 구성됩니다. - 알파벳 문자로 시작합니다.
- 알파벳 문자로 끝납니다.
레이블은 다음 조건을 충족해야 합니다.
- 연속되는 두 개의 대시(
--)가 없습니다. - 64자를 초과하지 않습니다.
Azure Portal의 컨테이너 앱의 수정 버전 관리 페이지에서 레이블을 관리할 수 있습니다.
레이블 URL은 수정 버전 세부 정보 창에서 찾을 수 있습니다.
가동 중지 시간을 0으로 배포
Container Apps를 사용하면 단일 수정 버전 모드에서 새 수정 버전을 만들 때 앱의 가동 중지 시간이 발생하지 않습니다. 새 수정 버전이 준비될 때까지 기존 활성 수정 버전이 비활성화되지 않습니다.
수신을 사용하도록 설정하면 새 수정 버전이 준비될 때까지 기존 수정 버전이 트래픽의 100%를 계속 수신합니다.
새 수정 버전은 다음 조건을 충족할 때 준비된 것으로 간주됩니다.
- 수정 버전이 성공적으로 프로비전되었습니다.
- 수정 버전이 이전 수정 버전 복제본 수와 일치하도록(새 수정 버전의 최소 및 최대 복제본 수에 따라) 스케일 업되었습니다.
- 모든 복제본이 시작 및 준비 상태 프로브를 통과했습니다.
여러 수정 버전 모드에서는 수정 버전이 활성화되거나 비활성화되는 시점과 수신 트래픽을 수신하는 수정 버전을 고객이 제어할 수 있습니다. latestRevision이 true로 설정된 상태로 트래픽 분할 규칙이 구성되면 트래픽이 준비될 때까지 최신 수정 버전으로 전환되지 않습니다.
여러 수정 버전 사용
단일 수정 버전 모드가 기본이지만, 수정 버전 관리 방법을 철저하게 제어해야 할 때가 있습니다.
여러 수정 버전 모드를 사용하면 수정 버전을 수동으로 유연하게 관리할 수 있습니다. 예를 들어 여러 수정 버전 모드를 사용하면 각 수정 버전에 할당되는 트래픽의 양을 정확하게 결정할 수 있습니다.
트래픽 분할
다음 다이어그램에서는 두 개의 수정 버전이 있는 컨테이너 앱을 보여 줍니다.
이 시나리오에서는 컨테이너 앱이 다음 상태에 있다고 가정합니다.
- 수신가 사용하도록 설정되어 HTTP 또는 TCP를 통해 컨테이너 앱을 사용할 수 있습니다.
- 첫 번째 수정 버전이 Revision 1로 배포되었습니다.
- 컨테이너가 업데이트된 후 새 수정 버전이 Revision 2로 활성화되었습니다.
- 트래픽 분할 규칙은 Revision 1이 요청의 80%를 수신하고 Revision 2가 나머지 20%를 수신하도록 구성됩니다.
직접 수정 버전 액세스
라우팅 규칙을 사용하여 트래픽을 수정 버전으로 전환하는 대신 특정 URL에 대한 요청에 수정 버전을 사용하려는 경우가 있습니다. 여러 수정 버전 모드를 사용하면 도메인에 들어오는 모든 요청을 최신 수정 버전으로 보낼 수 있으며, 이전 수정 버전에 대한 요청은 레이블을 통해 직접 액세스할 수 있습니다.
활성화 상태
여러 수정 버전 모드에서는 수정 버전을 필요한 대로 활성화하거나 비활성화할 수 있습니다. 활성 수정 버전은 작동 중이고 요청을 처리할 수 있지만, 비활성 수정 버전은 휴면 상태로 유지됩니다.
Container Apps는 비활성 수정 버전에 대한 요금을 부과하지 않습니다. 그러나 사용 가능한 총 수정 버전 수가 제한되어 있으며, 100개를 초과하면 가장 오래된 수정 버전이 제거됩니다.
변경 형식
컨테이너 앱에 대한 변경은 수정 버전-범위 또는 애플리케이션-범위 변경의 두 가지 범주에 속합니다. 수정 버전-범위 변경은 앱을 배포할 때 새 수정 버전을 트리거하지만 애플리케이션 범위 변경은 그렇지 않습니다.
수정 버전-범위 변경
컨테이너 앱이 수정 버전-범위 변경으로 업데이트되면 새 수정 버전이 만들어집니다. 변경 내용은 배포된 수정 버전으로 제한되며 다른 수정 버전에는 영향을 주지 않습니다.
수정 버전-범위 변경은 컨테이너 앱 리소스 템플릿의 properties.template 섹션에서 매개 변수에 대한 모든 변경 내용입니다.
해당 매개 변수는 다음과 같습니다.
- 수정 버전 접미사
- 컨테이너 구성 및 이미지
- 컨테이너 애플리케이션에 대한 스케일링 규칙
애플리케이션 범위 변경
애플리케이션-범위가 변경된 컨테이너 앱을 배포하는 경우:
- 변경 내용은 모든 수정 버전에 전역적으로 적용됩니다.
- 새 수정 버전이 만들어지지 않습니다.
애플리케이션-범위 변경은 컨테이너 앱 리소스 템플릿의 properties.configuration 섹션에서 매개 변수에 대한 모든 변경으로 정의됩니다.
해당 매개 변수는 다음과 같습니다.
수정 버전 사용자 지정
이름 지정 규칙 또는 버전 관리 전략에 더 부합하도록 수정 버전 이름 및 레이블을 사용자 지정할 수 있습니다.
이름 접미사
Container Apps의 모든 수정 버전에는 고유 식별자가 할당됩니다. 이름이 자동으로 생성되지만, 수정 버전 이름을 개인 설정할 수 있습니다.
수정 버전 이름의 일반적인 형식은 다음과 같습니다.
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
예를 들어 album-api라는 컨테이너 앱이 있고 수정 버전 접미사를 first-revision으로 결정하면 전체 수정 버전 이름은 album-api-first-revision입니다.
수정 버전 접미사 이름은 다음 조건을 충족해야 합니다.
- 소문자 영숫자 또는 대시(
-)로만 구성됩니다. - 알파벳 문자로 시작합니다.
- 알파벳 문자로 끝납니다.
이름이 다음 조건을 충족해야 합니다.
- 연속되는 두 개의 대시(
--)가 없습니다. - 64자를 초과하지 않습니다.
ARM 템플릿의 수정 버전 접미사 설정은 Azure CLI az containerapp create 및 az containerapp update 명령을 통해 또는 Azure Portal을 통해 수정 버전을 만들 때 할 수 있습니다.
사용 사례
다음은 컨테이너 앱에서 수정 버전을 사용하는 일반적인 사용 사례입니다. 이 목록은 Container Apps 수정 버전을 사용하는 목적 또는 기능의 전체 목록이 아닙니다.
릴리스 관리
수정 버전은 새 앱 버전을 도입하는 프로세스를 간소화합니다. 업데이트 또는 새 기능을 배포할 준비가 되면 현재 라이브 버전에 영향을 주지 않고 새 수정 버전을 만들 수 있습니다. 이 방법은 원활한 전환을 보장하며 최종 사용자의 중단을 최소화합니다.
이전 버전으로 되돌리기
경우에 따라 안정적인 이전 버전 앱으로 신속하게 되돌려야 할 때가 있습니다. 필요한 경우 컨테이너 앱의 이전 수정 버전으로 롤백할 수 있습니다.
A/B 테스트
다른 앱 버전을 테스트하려는 경우 수정 버전에서 A/B 테스트를 지원할 수 있습니다. 일부 사용자를 새 수정 버전으로 라우팅하고, 피드백을 수집하고, 실제 데이터를 기반으로 정보에 입각한 결정을 내릴 수 있습니다.
파란색-녹색 배포
수정 버전은 파란색-녹색 배포 전략을 지원합니다. 병렬 수정 버전 2개가 있으면(파란색은 라이브 버전용, 녹색은 새 버전용) 새 수정 버전에서 점진적으로 단계를 진행할 수 있습니다. 새 버전의 안정성과 성능에 대한 확신이 있으면 트래픽을 완전히 녹색 환경으로 전환해도 됩니다.