GitHub Actions 사용하여 Canary Blue-Green 배포 자동화

이 포스트에서는 GitHub Actions 를 사용하여 Canary Blue-Green 배포의 첫 번째 단계를 자동화하는 방법을 보여드립니다.

배포를 자동화하는 것은 대부분의 프로젝트의 성공에 매우 중요합니다. 하지만 단순히 코드를 배포하는 것만으로는 충분하지 않습니다. Downtime을 제한(또는 제거) 하고 장애 발생 시 신속하게 Roll Back 할 수 있는 기능도 필요합니다. Canary 배포와 Blue-Green 배포를 결합하는 것은 새 코드의 실행 가능성을 보장하기 위한 일반적인 접근 방식입니다. 이 전략에는 두 단계가 포함됩니다.

1단계: Canary 배포를 통한 격리 테스트 – 환경 외부의 격리된 노드, 서버 또는 컨테이너에 코드를 배포하고 코드가 의도한 대로 작동하는지 테스트하세요.

2단계: 프로덕션 환경에서 테스트하기 위한 Blue-Green 배포 – 코드가 Canary 배포에서 작동한다고 가정하고, 현재 버전의 서버와 함께 프로덕션 환경에서 새로 만든 서버(또는 노드 또는 컨테이너)로 코드를 포팅합니다. 그런 다음 프로덕션 트래픽의 일부를 새 버전으로 리다이렉션하여 더 높은 부하에서도 계속 잘 작동하는지 테스트합니다. 대부분의 경우 작은 비율(예: 10%)을 새 버전으로 리다이렉션하는 것으로 시작하여 새 버전이 모든 트래픽을 수신할 때까지 점진적으로 리다이렉션 비율을 늘립니다. 증분의 크기는 새 버전이 트래픽을 처리할 수 있다고 확신하는 정도에 따라 달라지며, 한 번에 새 버전으로 완전히 전환할 수도 있습니다.

애플리케이션 또는 웹사이트의 여러 버전 간에 트래픽을 분산(트래픽 분할) 하는 다양한 사용 사례에 익숙하지 않다면, 자습서에서 고급 트래픽 관리를 통해 Kubernetes의 복원력을 개선하는 방법을 읽고 Blue-Green 배포, Canary 릴리스, A/B Testing, Rate Limiting, Circuit Breaking 등에 대한 개념적 이해를 얻으세요. 이 자습서는 Kubernetes에 특화되어 있지만, 개념은 Microservices 애플리케이션에 광범위하게 적용할 수 있습니다.

목차
1. NGINX 자습서 개요
2. 전제 조건 및 설정
2-1. 전제 조건
2-2. 설정
3. 과제 1: NGINX 컨테이너 애플리케이션 생성 및 배포
4. 과제 2: Azure 컨테이너 애플리케이션 배포 자동화를 위한 권한 설정
5. 과제 3: Canary Blue-Green 배포 GitHub 작업 만들기
5-1. GitHub Repository에 Secret 추가하기
5-2. GitHub Action Workflow 파일 만들기
5-2-1. 전체 Workflow 파일
5-3. Action Workflow 실행
6. 과제 4: GitHub Actions Workflow 테스트
6-1. 성공적인 업데이트 수행
6-2. 실패한 업데이트 만들기
7. 리소스 정리

1. GitHub Actions NGINX 자습서 개요

NGINX 자습서의 네 가지 과제에서는 Azure Container Apps을 사용하여 애플리케이션의 새 버전을 배포한 다음 Azure Traffic Manager를 사용하여 이전 환경에서 새 환경으로 트래픽을 전환합니다.

Note: 이 NGINX 자습서 에서는 Azure Container Apps를 사용하지만 개념과 기술은 모든 클라우드 기반 호스트에 적용할 수 있습니다.

과제 1: NGINX 컨테이너 애플리케이션 생성 및 배포
과제 2: Azure 컨테이너 애플리케이션 배포 자동화를 위한 권한 설정
과제 3: Canary Blue-Green 배포 GitHub 작업 만들기
과제 4: GitHub Actions Workflow 테스트

2. GitHub Actions 전제 조건 및 설정

2-1. GitHub Actions 전제 조건

자신의 환경에서 이 자습서를 수행하려면 다음이 필요합니다.

Azure 계정 조직 계정을 사용할 때 권한에 문제가 발생할 수 있으므로 조직에 연결되지 않은 계정을 사용하는 것이 좋습니다.
Azure CLI
브라우저 기반 GitHub GUI 대신(또는 추가로) 사용하려는 경우 GitHub CLI를 사용할 수 있습니다.

2-2. 설정

필요한 기본 리소스를 만들고 구성합니다. 자습서용 Repository를 포크 및 복제하고, Azure CLI에 로그인한 후 Azure Container Apps 용 확장을 설치합니다.

1. 홈 디렉터리에서 microservices-march 디렉터리를 만듭니다. (다른 디렉터리 이름을 사용하고 그에 따라 지침을 조정할 수도 있습니다.)

Note: 이 자습서에서는 명령을 복사하여 터미널에 붙여넣기 쉽도록 Linux Command Line의 프롬프트가 생략되어 있습니다.

mkdir ~/microservices-march
cd ~/microservices-march

2. GitHub CLI 또는 GUI를 사용하여 Microservices March 플랫폼 Repository를 포크하고 개인 GitHub 계정에 복제합니다.

GitHub GUI를 사용하는 경우.

1. 창 오른쪽 상단 모서리에 있는 Fork를 클릭하고 소유자 메뉴에서 개인 GitHub 계정을 선택합니다.

screenshot of GitHub GUI showing fork of the repository for this tutorial

2. Repository를 로컬로 복제하고 <your_GitHub_account>를 계정 이름으로 대체합니다.

git clone https://github.com/<your_GitHub_account>/platform.git
cd platform

GitHub CLI를 사용하는 경우 다음을 실행합니다.

gh repo fork microservices-march/platform -–clone

3. Azure CLI에 로그인합니다. 프롬프트에 따라 브라우저를 사용하여 로그인합니다.

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

4. containerapp 확장 프로그램을 설치합니다.

az extension add --name containerapp -upgrade
The installed extension 'containerapp' is in preview.

3. 과제 1: NGINX 컨테이너 애플리케이션 생성 및 배포

이 초기 과제에서는 Canary Blue-Green 배포의 기준선으로 사용되는 애플리케이션의 초기 버전으로 NGINX Azure Container Apps을 생성합니다. Azure Container Apps는 컨테이너에 패키징된 애플리케이션 코드를 프로덕션 지원 컨테이너 환경에서 쉽게 실행하는 데 사용하는 Microsoft Azure 서비스입니다.

1. 컨테이너 애플리케이션에 대한 Azure 리소스 그룹을 만듭니다.

az group create --name my-container-app-rg --location westus
{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

2. 컨테이너를 Azure Container Apps에 배포합니다(이 단계는 시간이 걸릴 수 있습니다).

az containerapp up \
    --resource-group my-container-app-rg \
    --name my-container-app \
    --source ./ingress \
    --ingress external \
    --target-port 80 \
    --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

3. 2단계의 출력에서 Azure Container Registry(ACR)에서 만든 컨테이너 애플리케이션의 이름과 URL을 찾습니다. 샘플 출력에서 주황색으로 강조 표시되어 있습니다. 자습서 전체에서 명령에 표시된 변수를 출력의 값( 2단계의 샘플 출력과 다를 수 있음)으로 대체합니다:

컨테이너 애플리케이션의 이름 – image.registry 키에서 .azurecr.io 앞의 문자열입니다. 2단계의 샘플 출력에서 cac085021b77acr입니다.
컨테이너 애플리케이션의 URL – 생성된 컨테이너 애플리케이션을 시작하는 줄의 URL입니다. 2단계의 샘플 출력에서 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/입니다.

4. Blue-Green 배포에 필요한 대로 컨테이너 애플리케이션에 대한 리비전(Revision)을 활성화합니다.

az containerapp revision set-mode \
    --name my-container-app \
    --resource-group my-container-app-rg \
    --mode multiple
"Multiple"

5. (선택 사항) 컨테이너의 /health Endpoint를 Query하여 배포가 작동하는지 테스트합니다.

curl <ACR_URL>/health
OK

4. 과제 2: Azure 컨테이너 애플리케이션 배포 자동화를 위한 권한 설정

이 과제에서는 Azure 컨테이너 애플리케이션 배포를 자동화할 수 있는 JSON 토큰을 얻습니다.

먼저 Azure Container Registry(ACR)의 ID를 가져온 다음, Azure 관리 ID의 보안 주체 ID를 가져옵니다. 그런 다음 ACR에 대한 기본 제공 Azure 역할을 관리 ID에 할당하고 관리 ID를 사용하도록 컨테이너 애플리케이션을 구성합니다. 마지막으로 관리 ID에 대한 JSON 자격 증명을 얻게 되며, 이 자격 증명은 GitHub Actions에서 Azure에 인증하는 데 사용됩니다.

이 일련의 단계는 지루해 보일 수 있지만, 새 애플리케이션을 만들 때 한 번만 수행하면 프로세스를 완전히 스크립팅 할 수 있습니다. 자습서에서는 단계를 수동으로 수행하여 익숙해지도록 안내합니다.

Note: 배포를 위한 자격 증명을 만드는 이 프로세스는 Azure에만 해당됩니다.

1. 관리 ID의 보안 주체 ID를 찾습니다. 이 값은 출력의 PrincipalID 열에 표시됩니다(가독성을 위해 두 줄로 나누어 표시됩니다). 3단계에서 이 <managed_identity_principal_ID>값을로 대체합니다.

az containerapp identity assign \
    --name my-container-app \
    --resource-group my-container-app-rg \
    --system-assigned \
    --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

2. ACR에서 컨테이너 애플리케이션의 리소스 ID를 찾아 <ACR_name>을 과제 1의 3단계에서 기록한 이름으로 바꿉니다. 다음 단계에서는 이 <ACR_resource_ID>값을로 대체합니다.

az acr show --name <ACR_name> --query id --output tsv
/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

3. ACR에 대한 기본 제공 Azure 역할을 컨테이너 애플리케이션의 관리 ID에 할당하고, <managed_identity_principal_ID>를 1단계에서 얻은 관리 ID로 바꾸고, <ACR_resource_ID>를 2단계에서 얻은 리소스 ID로 바꿉니다.

az role assignment create \
    --assignee <managed_identity_principal_ID> \
    --role AcrPull \
    --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

4. ACR에서 이미지를 가져올 때 관리 ID를 사용하도록 컨테이너 애플리케이션을 구성하고 <ACR_name>을 과제 1의 3단계에서 기록한 컨테이너 애플리케이션 이름(위의 2단계에서도 사용됩니다)으로 바꿉니다.

az containerapp registry set \
    --name my-container-app \
    --resource-group my-container-app-rg \
    --server <ACR_name>.azurecr.io \
    --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

5. Azure 구독 ID를 조회합니다.

az account show --query id --output tsv
0efafl2-38ad-41w8-g49a-0ecc6723l97c

6. GitHub 작업에서 사용할 자격 증명이 포함된 JSON 토큰을 만들고, <subscription_ID>를 Azure 구독 ID로 바꿉니다. 출력을 저장하여 GitHub Repository에 Secret 추가에서 AZURE_CREDENTIALS라는 이름의 Secret 값으로 붙여 넣습니다. 알려진 문제이므로 –sdk-auth가 더 이상 사용되지 않는다는 경고는 무시해도 됩니다.

az ad sp create-for-rbac \
    --name my-container-app-rbac \
    --role contributor \
    --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg \
    --sdk-auth \
    --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

5. 과제 3: Canary Blue-Green 배포 GitHub Actions 작업 만들기

이 과제에서는 GitHub Repogitory에 Secret을 추가하고(GitHub 작업 Workflow에서 중요한 데이터를 관리하는 데 사용합니다), 작업 Workflow 파일을 만들고, 작업 Workflow를 실행합니다.

5-1. GitHub Repository에 Secret 추가하기

애플리케이션의 새 버전을 배포하려면 설정에서 포크(fork)한 GitHub Repository에 일련의 Secret을 만들어야 합니다. 이 Secret은 과제 2에서 만든 관리 ID에 대한 JSON 자격 증명과 새 버전의 NGINX 이미지를 Azure에 배포하는 데 필요한 몇 가지 중요한 배포 관련 매개 변수입니다. 다음 섹션에서는 이러한 Secret을 GitHub Action에서 사용하여 Canary Blue-Green 배포를 자동화합니다.

GitHub GUI를 사용하는 경우.

1. 포크된 GitHub Repository로 이동합니다.

2. Select Settings > Secrets 및 variables > Actions을 선택합니다.

3. New repository secret을 클릭합니다.

4. 표시된 필드에 다음 값을 입력합니다.

Name – AZURE_CREDENTIALS
Secret – 과제 2의 6단계에 나오는 JSON 자격 증명

5. Add secret 클릭합니다.

6. 3~5단계를 세 번 반복하여 표에 나열된 Secret을 만듭니다. Secret Name 및 Secret Value 열의 값을 각각 GUI의 Name 및 Secret 필드에 입력합니다. 세 번째 Secret의 경우, <ACR_name>을 과제 1의 3단계에서 기록한 컨테이너 애플리케이션에 할당된 이름으로 바꿉니다.

Secret Name	Secret Value
`CONTAINER_APP_NAME`	`my-container-app`
`RESOURCE_GROUP`	`my-container-app-rg`
`ACR_NAME`	`<ACR_name>`

7. GitHub Action Workflow 파일 만들기를 진행합니다.

GitHub CLI를 사용하는 경우.

1. Repogitory의 root에서 임시 파일을 만듭니다.

touch ~/creds.json

2. 선호하는 텍스트 편집기를 사용하여 creds.json을 열고 과제 2의 6단계에서 생성한 JSON 자격 증명을 복사합니다.

3. Secret을 생성합니다.

gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json

4. creds.json을 삭제합니다.

rm ~/creds.json

5. 이 명령을 반복하여 3개의 Secret을 더 생성합니다.

gh secret set <secret_name> --repo <your_GitHub_account>/platform

반복할 때마다 표의 Secret 이름 열에 있는 값 중 하나로 <secret_name>을 바꿉니다. 메시지가 표시되면 Secret 값 열에서 관련 값을 붙여 넣습니다. 세 번째 Secret의 경우, <ACR_name>을 과제 1의 3단계에서 기록한 컨테이너 애플리케이션에 할당된 이름으로 바꿉니다.

Secret Name	Secret Value
`CONTAINER_APP_NAME`	`my-container-app`
`RESOURCE_GROUP`	`my-container-app-rg`
`ACR_NAME`	`<ACR_name>`

5-2. GitHub Action Workflow 파일 만들기

관리 ID와 Secret이 준비되면 Canary Blue-Green 배포를 자동화하는 GitHub Action에 대한 Workflow 파일을 만들 수 있습니다.

Note: Workflow 파일은 공백이 중요한 YAML 형식으로 정의됩니다. 아래 단계에 표시된 들여 쓰기를 유지해야 합니다.

1. Action Workflow에 대한 파일을 만듭니다.

GitHub GUI를 사용하는 경우.

1. GitHub Repository로 이동합니다.

2. Action을 선택하고 > New workflow > Skip을 선택 후 workflow를 직접 설정합니다.

GitHub CLI를 사용하는 경우 .github/workflows 디렉터리를 만들고 main.yml이라는 새 파일을 만듭니다.

mkdir .github/workflows
touch .github/workflows/main.yml

2. 선호하는 텍스트 편집기를 사용하여 Workflow 텍스트를 main.yml에 추가합니다. 가장 쉬운 방법은 전체 Workflow 파일에 표시되는 텍스트를 복사하는 것입니다. 또는 이 단계에서 주석이 달린 Snippet 세트를 추가하여 파일을 수동으로 작성할 수도 있습니다.

Note: Workflow 파일은 공백이 중요한 YAML 형식으로 정의됩니다. Snippet을 복사하는 경우 들여 쓰기를 유지해야 하며, 파일을 전체 Workflow 파일과 비교하여 더욱 확실하게 확인할 수 있습니다.

Workflow의 이름을 정의합니다.

name: Deploy to Azure

Main Branch에 푸시 또는 Pull Request를 할 때 Workflow가 실행되도록 구성합니다.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

작업 섹션에서 빌드-배포 작업을 정의하여 코드를 체크아웃하고 Azure에 로그인한 다음 애플리케이션을 Azure Container App에 배포합니다.

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}\
            -g ${{ secrets.RESOURCE_GROUP }} \
            --source ${{ github.workspace }}/ingress \
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

테스트 배포 작업을 정의하여 새로 배포된 리비전(Revision)의 스테이징 URL을 가져오고 GitHub Action을 사용하여 API Endpoint /health를 Ping 하여 새 리비전(Revision)이 응답하는지 확인합니다. Health Check에 성공하면 모든 트래픽이 새로 배포된 컨테이너를 가리키도록 컨테이너 애플리케이션의 Azure Traffic Manager가 업데이트됩니다.

Note: 이전 글머리 기호에서 정의한 빌드 배포 키와 동일한 수준에서 테스트 배포 키를 들여쓰기해야 합니다.

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

5-2-1. 전체 Workflow 파일

다음은 Action Workflow 파일의 전체 텍스트입니다.

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} \
            -g ${{ secrets.RESOURCE_GROUP }} \
            --source ${{ github.workspace }}/ingress \
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

5-3. Action Workflow 실행

GitHub GUI를 사용하는 경우.

1. Commit을 클릭하고 원하는 경우 Commit 메시지를 추가한 다음 대화 상자에서 새 파일 Commit을 선택합니다. 새 Workflow 파일이 Main Branch에 병합되고 실행되기 시작됩니다.

2. Actions을 클릭하여 Workflow의 진행 상황을 모니터링합니다.

GitHub CLI를 사용하는 경우.

1. Git 스테이징 영역에 main.yml을 추가합니다.

git add .github/workflows/main.yml

2. 파일을 Commit합니다.

git commit -m "feat: create GitHub Actions workflow"

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

git push

4.Workflow의 진행 상황을 모니터링합니다.

gh workflow view main.yml --repo <your_GitHub_account>/platform

6. 과제 4: GitHub Actions Workflow 테스트

이 과제에서는 Workflow를 테스트합니다. 먼저 Ingress Load Balancer에 대한 성공적인 업데이트를 시뮬레이션하고 애플리케이션이 업데이트되었는지 확인합니다. 그런 다음 업데이트에 실패한 경우(내부 서버 오류로 이어집니다)를 시뮬레이션하고 게시된 애플리케이션이 변경되지 않았는지 확인합니다.

6-1. 성공적인 업데이트 수행

성공적인 업데이트를 생성하고 Workflow가 성공적으로 진행되는 것을 확인합니다.

GitHub GUI를 사용하는 경우.

1. Code > ingress > default.conf.template을 선택합니다.

2. 파일 편집 도구에 있는 연필 아이콘을 선택하여 편집할 default.conf.template을 엽니다.

3. 파일 끝 근처의 location /health 블록에서 다음과 같이 return 지시문을 변경합니다.

location /health {
    access_log off;
    return 200 "Successful Update!\n";
}

4. 대화 상자에서 이 Commit에 대한 새 Branch 만들기를 선택하고 Pull Request를 시작한 다음 Propose 변경을 선택합니다.

5. Pull Request 만들기를 클릭하여 Pull Request 템플릿에 액세스합니다.

6. Pull Request 만들기를 다시 클릭하여 Pull Request를 만듭니다.

7. Action을 클릭하여 Workflow의 진행 상황을 모니터링합니다.

8. Workflow가 완료되면 <ACR_URL> /health Endpoint에서 컨테이너 애플리케이션으로 이동합니다. 여기서 <ACR_URL>은 과제 1의 3단계에서 언급한 URL입니다. Successful Update! 메시지를 확인합니다.

9. 터미널 세션을 시작하고 애플리케이션에 Health Check 요청을 보낸 다음 <ACR_URL>을 과제 1의 3단계에서 기록한 값으로 다시 대체하여 메시지를 확인할 수 있습니다.

curl <ACR_URL>/health
Successful Update!

10. 실패한 업데이트를 진행합니다.

GitHub CLI를 사용하는 경우.

1. patch-1이라는 새로운 Branch를 만듭니다.

git checkout -b patch-1

2. 선호하는 텍스트 편집기에서 ingress/default.conf.template을 열고 파일 끝 근처의 location /health 블록에서 다음과 같이 반환 지시문을 변경합니다.

location /health {
    access_log off;
    return 200 "Successful Update!\n";
}

3. Git 스테이징 영역에 default.conf.template을 추가합니다.

git add ingress/default.conf.template

4. 파일을 Commit 합니다.

git commit -m "feat: update NGINX ingress"

5. 변경 사항을 GitHub에 Push 합니다.

git push --set-upstream origin patch-1

6. Pull Request(PR)을 생성합니다.

gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform

7. Workflow의 진행 상황을 모니터링합니다.

gh workflow view main.yml --repo <your_GitHub_account>/platform

8. Workflow가 완료되면 <ACR_URL>을 과제 1의 3단계에서 기록한 값으로 대체하여 애플리케이션에 Health Check 요청을 보냅니다.

curl <ACR_URL>/health
Successful Update!

6-2. 실패한 업데이트 만들기

이제 실패한 업데이트를 생성하고 Workflow가 실패하는 것을 지켜보십시오. 여기에는 기본적으로 성공적인 업데이트 만들기의 단계를 반복하지만 Return 지시문에 대해 다른 값을 사용하는 것이 포함됩니다.

GitHub GUI를 사용하는 경우.

1. Code > ingress > default.conf.template을 선택합니다.

2. 왼쪽 상단에서 Main을 선택한 다음 이전 섹션에서 생성한 patch-1로 끝나는 Branch의 이름을 선택합니다.

3. 파일 편집 도구의 있는 연필 아이콘을 선택하여 편집할 default.conf.template을 엽니다.

4. 다음과 같이 return 지시문을 변경합니다.

location /health {
    access_log off;
    return 500 "Unsuccessful Update!\n";
}

5. -patch-1 Branch에 직접 Commit을 선택한 다음 변경 사항을 Commit 합니다.

6. 작업을 선택하여 Workflow의 진행 상황을 모니터링합니다. PR의 파일이 업데이트되면 Workflowk Reload 되는 것을 확인할 수 있습니다.

7. Workflow가 완료되면 <ACR_URL>/health Endpoint에서 컨테이너 애플리케이션으로 이동합니다. 여기서 <ACR_URL>은 챌린지 1의 3단계에서 기록한 URL입니다.

Successful Update!이라는 메시지가 표시됩니다! (이전 업데이트 성공 후와 동일)라는 메시지가 표시됩니다. 역설적으로 보일 수 있지만 실제로는 업데이트 시도가 500(내부 서버 오류를 의미)이라는 상태가 발생하여 적용되지 않았으며, 이 업데이트가 실패했음을 확인시켜 줍니다.

8. 터미널 세션을 시작하고 애플리케이션에 Health Check 요청을 보낸 다음 <ACR_URL>을 과제 1의 3단계에서 기록한 값으로 다시 대체하여 메시지를 확인할 수 있습니다.

curl <ACR_URL>/health
Successful Update!

GitHub CLI를 사용하는 경우 .

1. 이전 섹션에서 생성한 patch-1 Branch를 확인하십시오.

git checkout patch-1

2. 선호하는 텍스트 편집기에서 ingress/default.conf.template을 열고 다음과 같이 return 지시문을 변경합니다.

location /health {
    access_log off;
    return 500 "Unsuccessful Update!\n";
}

3. Git 스테이징 영역에 default.conf.template을 추가합니다.

git add ingress/default.conf.template

4. 파일을 Commit합니다.

git commit -m "feat: update NGINX ingress again"

5. 변경 사항을 GitHub에 Push합니다.

git push

6. Workflow의 진행 상황을 모니터링합니다.

gh workflow view main.yml --repo <your_GitHub_account>/platform

7. Wrokflow가 완료되면 애플리케이션에 Health Check 요청을 보내 <ACR_URL>을 과제 1의 3단계에서 기록한 값으로 바꿉니다:

curl <ACR_URL>/health
Successful Update!

Successful Update!이라는 메시지가 역설적으로 보일 수 있습니다. (이전의 성공적인 업데이트 후와 동일)라는 메시지가 표시되는 것이 역설적으로 보일 수 있습니다. 역설적으로 보일 수 있지만 실제로는 업데이트 시도가 500(Internal Server Error를 의미합니다) 상태가 되어 적용되지 않았기 때문에 업데이트가 실패했음을 확인시켜 줍니다.

7. 리소스 정리

잠재적인 비용 청구를 피하기 위해 NGINX 자습서에서 배포한 Azure 리소스를 제거할 수 있습니다.

az group delete -n my-container-app-rg -y

원하는 경우 생성한 포크를 삭제할 수도 있습니다.

GitHub GUI를 사용하는 경우.

1. Settings을 클릭합니다.

2. 페이지 맨 아래로 스크롤합니다.

3. Repository 삭제를 클릭합니다.

4. <your_GitHub_account>/platform을 입력하고 결과를 이해합니다. 이 Repository 삭제를 선택합니다.

이번 NGINX 자습서에서 GitHub Actions를 사용하여 Microservices 애플리케이션의 Canary Blue-Green 배포를 수행하는 방법을 배웠습니다.

NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.

GitHub Actions 사용하여 Canary Blue-Green 배포 자동화

1. GitHub Actions NGINX 자습서 개요

2. GitHub Actions 전제 조건 및 설정

2-1. GitHub Actions 전제 조건

2-2. 설정

3. 과제 1: NGINX 컨테이너 애플리케이션 생성 및 배포

4. 과제 2: Azure 컨테이너 애플리케이션 배포 자동화를 위한 권한 설정

5. 과제 3: Canary Blue-Green 배포 GitHub Actions 작업 만들기

5-1. GitHub Repository에 Secret 추가하기

5-2. GitHub Action Workflow 파일 만들기

5-2-1. 전체 Workflow 파일

5-3. Action Workflow 실행

6. 과제 4: GitHub Actions Workflow 테스트

6-1. 성공적인 업데이트 수행

6-2. 실패한 업데이트 만들기

7. 리소스 정리

이것이 좋아요:

관련

Recent News

NGINX API Gateway – L7 Load…

Let’s Encrypt 인증서로 NGINX SSL 설정하기

NGINX Plus API Gateway로 JWT 인증…

Category

Contact Us

Company

API Gateway

Contacts

GitHub Actions 사용하여 Canary Blue-Green 배포 자동화

1. GitHub Actions NGINX 자습서 개요

2. GitHub Actions 전제 조건 및 설정

2-1. GitHub Actions 전제 조건

2-2. 설정

3. 과제 1: NGINX 컨테이너 애플리케이션 생성 및 배포

4. 과제 2: Azure 컨테이너 애플리케이션 배포 자동화를 위한 권한 설정

5. 과제 3: Canary Blue-Green 배포 GitHub Actions 작업 만들기

5-1. GitHub Repository에 Secret 추가하기

5-2. GitHub Action Workflow 파일 만들기

5-2-1. 전체 Workflow 파일

5-3. Action Workflow 실행

6. 과제 4: GitHub Actions Workflow 테스트

6-1. 성공적인 업데이트 수행

6-2. 실패한 업데이트 만들기

7. 리소스 정리

이 글이 도움이 되셨다면 SNS 또는 mail로 공유하셔서 가치를 나누세요!

이것이 좋아요:

관련

Recent News

NGINX API Gateway – L7 Load…

Let’s Encrypt 인증서로 NGINX SSL 설정하기

NGINX Plus API Gateway로 JWT 인증…

Category

Popular Tag

Contact Us

Newsletter