자습서: GitHub 로 마이크로서비스 배포 자동화

오늘 살펴볼 주제는 GitHub 로 마이크로서비스 배포를 자동화 하는 방법입니다. 대부분의 프로젝트 성공에는 배포 자동화가 중요합니다. 그러나 코드를 배포하는 것만으로는 충분하지 않습니다. 다운타임을 제한하거나 없앨 수 있어야 하며, 실패가 발생한 경우 빠르게 롤백할 수 있는 기능이 필요합니다. Canary 배포와 Blue-Green 배포를 결합하는 것은 새로운 코드가 운영 가능한지 확인하는 데 일반적으로 사용되는 접근 방식입니다. 이 전략에는 두 단계가 포함됩니다.

  • Step 1: 격리 테스트를 위한 Canary 배포 – 환경 외부의 격리된 노드, 서버 또는 컨테이너에 코드를 배포하고 코드가 의도한 대로 작동하는지 테스트합니다.
  • Step 2: 운영 환경에서 Blue-Green 배포를 통한 테스트 – Canary 배포에서 코드가 작동하는 것으로 가정하고, 현재 버전의 서버 옆에 운영 환경에서 새로운 서버(또는 노드 또는 컨테이너)에 코드를 이동시킵니다. 그런 다음 일부 운영 트래픽을 새 버전으로 리다이렉션하여 더 높은 부하 하에서도 잘 작동하는지 테스트합니다. 보통은 운영 트래픽의 일부(예: 10%)를 새 버전으로 리다이렉션하고, 점진적으로 증가시켜서 새 버전이 모든 트래픽을 받을 때까지 증가시킵니다. 증분의 크기는 새 버전이 트래픽을 처리할 수 있는 정도에 대한 신뢰도에 따라 다릅니다. 필요에 따라 새 버전으로 완전히 전환하는 것도 가능합니다.

앱 또는 웹사이트의 다른 버전 간에 트래픽을 분배하는 다양한 사용 사례에 대해 익숙하지 않은 경우 (트래픽 분할), NGINX팀 블로그의 “고급 트래픽 관리로 Kubernetes의 복원력을 개선하는 방법“를 읽어보세요. 이를 통해 Blue-Green 배포, Canary 배포, A/B Testing, 비율 제한, 회로 차단 등의 개념적 이해를 얻을 수 있습니다. 블로그는 Kubernetes에 특화되어 있지만, 이러한 개념은 마이크로서비스 앱에 넓게 적용될 수 있습니다.

목차

1. GitHub 튜토리얼 개요
2. 전제 조건 및 설정
2-1. 전제 조건
2-2. 설정
3. 과제 1: NGINX 컨테이너 앱 생성 및 배포
4. 과제 2: Azure 컨테이너 앱 배포 자동화를 위한 권한 설정
5. 과제 3: 카나리아 blue-green deployment 만들기 GitHub 작업
5-1. GitHub 리포지토리에 Secret 추가
5-2. GitHub 작업 워크플로 파일 만들기
5-3. 작업 워크플로 실행
6. 과제 4: GitHub Actions 워크플로 테스트
6-1. 성공적인 업데이트
6-2. 실패한 업데이트 만들기
7. 리소스정리
8. 다음 단계

1. GitHub 튜토리얼 개요

이 튜토리얼에서는 GitHub Actions를 사용하여 Canary Blue-Green 배포의 첫 번째 단계를 자동화하는 방법을 보여줍니다. 튜토리얼의 네 가지 과제에서는 Microsoft Azure Container Apps를 사용하여 애플리케이션의 새 버전을 배포하고, Azure Traffic Manager를 사용하여 트래픽을 이전 환경에서 새 환경으로 전환합니다.

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

2. 전제 조건 및 설정

2-1. 전제 조건

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

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

2-2. 설정

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

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

참고: 자습서 전체에서 Linux 명령줄의 프롬프트는 생략되어 명령을 터미널에 더 쉽게 복사하고 붙여넣을 수 있습니다.

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

2. GitHub CLI 또는 GUI를 사용하여 Microservices March 플랫폼 리포지토리를 개인 GitHub 계정으로 fork하고 복제합니다.

  • GitHub GUI를 사용하는 경우:

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

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

2. 리포지토리를 로컬로 복제하고 를 계정 이름으로 대체합니다.

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 컨테이너 앱을 만듭니다. 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단계의 출력에서 ACR(Azure Container Registry)에서 만든 컨테이너 앱의 이름과 URL을 찾습니다. 샘플 출력에서 주황색으로 강조 표시됩니다. 자습서 전체에서 명령의 표시된 변수에 대해 출력의 값(2단계의 샘플 출력과 다름)을 대체합니다.

  • 컨테이너 앱 이름 – image.registry key에서 .azurecr.io 앞의 문자열입니다. 2단계의 샘플 출력에서 cac085021b77acr입니다.
    후속 명령에서 을 이 문자열로 대체하십시오.
  • 컨테이너 앱의 URL – 생성된 컨테이너 앱을 시작하는 줄의 URL입니다. 2단계의 샘플 출력에서 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/입니다.
    후속 명령에서 을 이 URL로 대체하십시오.

4. Blue-Green 배포에 필요한 대로 컨테이너 앱에 대한 개정을 활성화합니다.

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

5. (선택 사항) 컨테이너에서 /health 엔드포인트를 쿼리하여 배포가 작동하는지 테스트합니다.

curl <ACR_URL>/health
OK

4. 과제 2: Azure 컨테이너 앱 배포 자동화를 위한 권한 설정

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

먼저 Azure Container Registry (ACR)의 ID를 얻은 다음 Azure 관리 ID에 대한 주체 ID를 얻습니다. 그런 다음 내장된 Azure 역할을 관리 ID에 할당하고, 컨테이너 앱을 관리 ID를 사용하도록 구성합니다. 마지막으로 GitHub Actions가 Azure에 인증하기 위해 관리 ID의 JSON 자격 증명을 얻습니다.

이러한 단계 집합은 지루해 보일 수 있지만, 새 애플리케이션을 생성할 때에만 한 번 수행하면 되며, 프로세스를 완전히 스크립트화할 수 있습니다. 튜토리얼에서는 단계를 수동으로 수행하여 익숙해지도록 안내하고 있습니다.

참고: 배포용 자격 증명을 만드는 이 프로세스는 Azure에만 적용됩니다.

1. 관리 ID의 주체 ID를 조회하세요. 주체 ID는 출력의 PrincipalID 열에 나타납니다 (가독성을 위해 두 줄로 나뉩니다). 이 값을 Step 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의 Step 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> 자리에는 Step 1에서 얻은 관리 ID를 대체하고, <ACR_resource_ID> 자리에는 Step 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의 Step 3에서 기록한 컨테이너 앱 이름을 대체하시면 됩니다 (앞서 Step 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 Action에서 사용할 자격 증명을 포함하는 JSON 토큰을 생성합니다. <subscription_ID> 자리에는 Azure 구독 ID를 대체하고, 생성된 출력을 “GitHub 리포지토리에 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 작업

이 과제에서는 GitHub 리포지토리(GitHub 작업 워크플로에서 중요한 데이터를 관리하는 데 사용됨)에 secret을 추가하고, 작업 워크플로 파일을 만들고, 작업 워크플로를 실행합니다.

5-1. GitHub 리포지토리에 Secret 추가

새로운 애플리케이션 버전을 배포하기 위해 GitHub 리포지토리에 일련의 secret을 생성해야 합니다. 이 secret들은 과제 2에서 생성한 관리되는 ID의 JSON 자격 증명과, NGINX 이미지를 Azure에 배포하기 위해 필요한 민감한 배포 관련 매개 변수입니다. 다음 섹션에서는 이러한 secret들을 GitHub Actions에서 사용하여 Canary Blue-Green 배포를 자동화합니다.

  • GitHub GUI를 사용하는 경우:

1. 분기된 GitHub 리포지토리로 이동합니다.

2. 설정 > 암호 및 변수 > 작업을 선택합니다.

3. 새 저장소 secret을 클릭하십시오.

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

  • Name – AZURE_CREDENTIALS
  • Secret – 과제 2의 6단계에서 얻은 JSON 자격 증명

5. secret 추가를 클릭합니다.

6. 위의 단계 3-5를 세 번 반복하여 테이블에 나열된 secret을 생성하세요. GUI의 “Name” 필드에는 secret 이름 열의 값을 입력하고, “Secret” 필드에는 secret 값 열의 값을 입력하세요. 세 번째 secret의 경우, <ACR_name>을(를) 과제 1의 단계 3에서 기록한 컨테이너 앱에 할당된 이름으로 대체하세요.

Secret NameSecret Value
CONTAINER_APP_NAMEmy-container-app
RESOURCE_GROUPmy-container-app-rg
ACR_NAME<ACR_name>

7. GitHub 작업 워크플로 파일 만들기로 진행합니다.

  • GitHub CLI를 사용하는 경우:

1. 리포지토리의 루트에서 임시 파일을 만듭니다.

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개 더 만듭니다.

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

각 반복에 대해 <secret_name>을 테이블의 Secret Name 열의 값 중 하나로 대체하세요. 프롬프트에서 Secret Value 열의 연관된 값을 붙여넣으세요. 세 번째 비밀 값에 대해서는 <ACR_name>을 과제 1의 단계 3에서 기록한 컨테이너 앱의 이름으로 대체하세요.

Secret NameSecret Value
CONTAINER_APP_NAMEmy-container-app
RESOURCE_GROUPmy-container-app-rg
ACR_NAME<ACR_name>

5-2. GitHub 작업 워크플로 파일 만들기

관리 ID 및 암호가 있으면 Canary Blue-Green 배포를 자동화하는 GitHub 작업에 대한 워크플로 파일을 만들 수 있습니다.

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

1. 작업 워크플로에 대한 파일을 만듭니다.

  • GitHub GUI를 사용하는 경우:
    1. GitHub 리포지토리로 이동합니다.
    2. 작업 > 새 워크플로 > 건너뛰기를 선택하고 워크플로를 직접 설정합니다.
  • GitHub CLI를 사용하는 경우 .github/workflows 디렉터리를 만들고 main.yml이라는 새 파일을 만듭니다.
mkdir .github/workflows
touch .github/workflows/main.yml

2. 선호하는 텍스트 편집기를 사용하여 워크플로우의 텍스트를 main.yml에 추가합니다. 가장 쉬운 방법은 Full Workflow File에 나타나는 텍스트를 복사하는 것입니다. 또는 이 단계에서 주석이 달린 스니펫 세트를 추가하여 파일을 수동으로 빌드할 수 있습니다.

참고: 워크플로 파일은 공백이 중요한 YAML 형식으로 정의됩니다. 스니펫을 복사하는 경우 들여쓰기를 유지해야 합니다(확실히 하려면 파일을 전체 워크플로 파일과 비교하십시오.

  • 워크플로의 이름을 정의합니다.
name: Deploy to Azure
  • 기본 분기에 대한 푸시 또는 풀 요청이 있을 때 실행할 워크플로를 구성합니다.
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
  • 새로 배포된 개정의 스테이징 URL을 가져오고 GitHub 작업을 사용하여 API 엔드포인트 /health를 ping하여 새 개정이 응답하는지 확인하는 테스트 배포 작업을 정의합니다. 상태 검사가 성공하면 컨테이너 앱의 Azure Traffic Manager가 새로 배포된 컨테이너의 모든 트래픽을 가리키도록 업데이트됩니다.
    참고: 이전 항목에서 정의한 build-deploy key와 동일한 수준에서 test-deployment key를 들여쓰기해야 합니다.
 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"

Full Workflow File

작업 워크플로 파일의 전체 텍스트입니다.

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. 작업 워크플로 실행

  • GitHub GUI를 사용하는 경우:

1. 커밋 시작을 클릭하고 원하는 경우 커밋 메시지를 추가한 다음 대화 상자에서 새 파일 커밋을 선택합니다. 새 워크플로 파일이 기본 분기에 병합되고 실행되기 시작합니다.

2. 작업을 클릭하여 워크플로의 진행 상황을 모니터링합니다.

  • GitHub CLI를 사용하는 경우:

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

git add .github/workflows/main.yml

2. 파일을 커밋합니다.

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

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

git push

4. 워크플로의 진행 상황을 모니터링합니다.

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

6. 과제 4: GitHub Actions 워크플로 테스트

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

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

성공적인 업데이트를 생성하고 워크플로가 성공하는지 확인합니다.

  • GitHub GUI를 사용하는 경우:

1. 코드 > 수신 > default.conf.template을 선택합니다.

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

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

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

4. 대화 상자에서 이 커밋에 대한 새 분기 만들기를 선택하고 풀 요청을 시작한 다음 변경 사항 제안을 선택합니다.

5. 풀 요청 템플릿에 액세스하려면 풀 요청 만들기를 클릭합니다.

6. 풀 요청 생성을 다시 클릭하여 풀 요청을 생성합니다.

7. 작업을 클릭하여 워크플로의 진행 상황을 모니터링합니다.

8. 워크플로가 완료되면 <ACR_URL>/health 엔드포인트에서 컨테이너 앱으로 이동합니다. 여기서는 과제 1의 3단계에서 기록한 URL입니다. 성공적인 업데이트를 확인하세요!

9. 터미널 세션을 시작하고 앱에 health check 요청을 전송하여 메시지를 확인할 수 있습니다. 은 다시 과제 1의 3단계에서 기록한 값으로 바꿉니다.

curl <ACR_URL>/health
Successful Update!

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

  • GitHub CLI를 사용하는 경우:

1. patch-1이라는 새 분기를 만듭니다.

git checkout -b patch-1

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

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

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

git add ingress/default.conf.template

4. 파일을 커밋합니다.

git commit -m "feat: update NGINX ingress"

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

git push --set-upstream origin patch-1

6. 풀 요청(PR)을 생성합니다.

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

7. 워크플로의 진행 상황을 모니터링합니다.

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

8. 워크플로가 완료되면 을 과제 1의 3단계에서 기록한 값으로 대체하여 앱에 health check 요청을 보냅니다.

curl <ACR_URL>/health
Successful Update!

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

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

  • GitHub GUI를 사용하는 경우:

1. 코드 > 수신 > default.conf.template을 선택합니다.

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

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

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

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

5. -patch-1 분기에 직접 커밋을 선택한 다음 변경 사항 커밋을 선택합니다.

6. 작업을 선택하여 워크플로의 진행 상황을 모니터링합니다. PR의 파일이 업데이트되면 워크플로가 다시 실행됩니다.

7. 워크플로가 완료되면 <ACR_URL>/health 엔드포인트에서 컨테이너 앱으로 이동합니다. 여기서 은 과제 1의 3단계에서 기록한 URL입니다.

메시지는 성공적인 업데이트입니다! (이전의 성공적인 업데이트 이후와 동일). 역설적으로 들릴 수 있지만 실제로는 이 업데이트가 실패했음을 확인합니다. 업데이트 시도 결과 상태 500(내부 서버 오류를 의미)이 발생하고 적용되지 않았습니다.

8. 터미널 세션을 시작하고 앱에 health check 요청을 전송하여 메시지를 확인할 수 있습니다. 은 다시 과제 1의 3단계에서 기록한 값으로 바꿉니다.

curl <ACR_URL>/health
Successful Update!
  • GitHub CLI를 사용하는 경우:

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

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. 파일을 커밋합니다.

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

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

git push

6. 워크플로의 진행 상황을 모니터링합니다.

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

7. 워크플로가 완료되면 을 과제 1의 3단계에서 기록한 값으로 대체하여 앱에 health check 요청을 보냅니다.

curl <ACR_URL>/health
Successful Update!

메시지가 업데이트 성공!이라는 것이 역설적으로 들릴 수 있습니다. (이전의 성공적인 업데이트 이후와 동일). 역설적으로 들릴 수 있지만 실제로는 이 업데이트가 실패했음을 확인합니다. 업데이트 시도 결과 상태 500(내부 서버 오류를 의미)이 발생하고 적용되지 않았습니다.

7. 리소스 정리

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

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

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

  • GitHub GUI를 사용하는 경우:
    1. 설정을 클릭합니다.
    2. 페이지 맨 아래로 스크롤하십시오.
    3. 이 리포지토리 삭제를 클릭합니다.
    4. <your_GitHub_account>/platform을 입력하고 결과를 이해합니다. 이 리포지토리 삭제를 선택합니다.
  • GitHub CLI를 사용하는 경우:
gh repo delete <your_GitHub_account>/platform -yes

8. 다음 단계

축하합니다! GitHub Actions를 사용하여 마이크로서비스 애플리케이션의 Canary Blue-Green 배포를 수행하는 방법을 배웠습니다. DevOps에 대한 지식을 계속 탐색하고 향상시키기 위해 GitHub 문서에서 다음 기사들을 확인해보세요:

만약 Canary 배포의 두 번째 단계(운영 환경에서의 테스트)를 시도해보고 싶다면, NGINX팀 블로그에서 발행된 Microservices March 2022 튜토리얼인 “Kubernetes Canary 배포로 가동 시간 및 복원력 향상“를 확인해보세요. 이 튜토리얼은 NGINX Service Mesh를 사용하여 새로운 앱 버전으로 점진적으로 전환하는 방법을 다룹니다. 만약 당신의 배포가 서비스 메시(NGINX Service Mesh)를 필요로 하는 복잡성을 갖추지 않았거나 Kubernetes를 사용하지 않는다면, 단순한 Ingress Controller나 로드 밸런서만을 사용한 배포에도 여전히 해당 원칙들이 적용될 수 있습니다.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

아래 뉴스레터를 구독하고 NGINX의 최신 정보들을 빠르게 전달 받아보세요.