블로그 | NGINX

NGINX 튜토리얼: GitHub Actions를 사용하여 마이크로서비스 Canary 배포를 자동화하는 방법

NGINX-F5-수평-검정-유형-RGB의 일부
크리스토퍼 해리슨 썸네일
크리스토퍼 해리슨
2023년 3월 21일 게시

이 게시물은 Microservices March 2023의 개념을 실제로 구현하는 데 도움이 되는 4가지 튜토리얼 중 하나입니다. 마이크로서비스 제공 시작하기 :

 

대부분의 프로젝트의 성공을 위해서는 배포를 자동화하는 것이 중요합니다. 하지만 단순히 코드를 배포하는 것만으로는 충분하지 않습니다. 또한 가동 중지 시간을 제한하거나 없애야 하며, 장애 발생 시 신속하게 롤백할 수 있는 기능도 필요합니다. 카나리아 배포 와 블루-그린 배포를 결합하는 것은 새로운 코드의 실행 가능성을 보장하는 일반적인 접근 방식입니다. 이 전략에는 두 단계가 포함됩니다.

  • 1단계: 격리된 환경에서 테스트하기 위한 카나리아 배포 – 환경 외부의 격리된 노드, 서버 또는 컨테이너에 코드를 배포하고 코드가 의도한 대로 작동하는지 테스트합니다.
  • 2단계: 프로덕션에서 테스트하기 위한 블루-그린 배포 - 카나리아 배포에서 코드가 작동한다고 가정하고 현재 버전의 서버와 함께 프로덕션 환경에서 새로 생성된 서버(또는 노드나 컨테이너)로 코드를 이식합니다. 그런 다음 일부 프로덕션 트래픽을 새 버전으로 리디렉션하여 더 높은 부하에서도 계속 잘 작동하는지 테스트합니다. 대부분의 경우, 처음에는 적은 비율(예: 10%)을 새 버전으로 유도한 다음, 새 버전이 모든 트래픽을 받을 때까지 점진적으로 늘리는 방식으로 시작합니다. 증가 규모는 새 버전이 트래픽을 얼마나 처리할 수 있는지에 대한 확신에 따라 달라집니다. 한 단계만으로 새 버전으로 완전히 전환할 수도 있습니다.

앱이나 웹사이트의 여러 버전 간에 트래픽을 분산하는 다양한 사용 사례( 트래픽 분할 )에 익숙하지 않은 경우 블로그에서 고급 트래픽 관리를 사용하여 Kubernetes의 복원력을 개선하는 방법을 읽어보고 블루-그린 배포, 카나리아 릴리스, A/B 테스트, 속도 제한, 회로 차단 등에 대한 개념적 이해를 얻으세요. 이 블로그는 Kubernetes에 국한되어 있지만, 개념은 마이크로서비스 앱에도 광범위하게 적용할 수 있습니다.

튜토리얼 개요

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

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

필수 구성 요소 및 설정

필수 조건

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

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

설정

필요한 기본 리소스를 생성하고 구성합니다. 튜토리얼의 리포지토리를 포크하고 복제한 다음 Azure CLI에 로그인하고 Azure Container Apps용 확장을 설치합니다.

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

    메모: 튜토리얼 전체에서 Linux 명령줄의 프롬프트는 생략되어 터미널에 명령을 복사하여 붙여 넣기가 더 쉬워졌습니다.

    mkdir ~/microservices-marchcd ~/microservices-march

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

    • GitHub GUI를 사용하는 경우:

      1. 창의 오른쪽 상단에 있는 Fork를 클릭하고 Owner 메뉴에서 개인 GitHub 계정을 선택하세요.

        이 튜토리얼의 저장소 포크를 보여주는 GitHub GUI의 스크린샷

      2. 계정 이름을 대체하여 로컬 저장소를 복제합니다. <귀하의 GitHub 계정>:

        git 클론 https://github.com/<귀하의 GitHub 계정>/platform.gitcd 플랫폼

    • GitHub CLI를 사용하는 경우 다음을 실행하세요.

      gh repo fork microservices-march/platform -–clone

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

    az 로그인 [ { "cloudName": "AzureCloud", "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e", "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c", "isDefault": true, "managedByTenants": [], "name": "Azure 구독 1", "상태": "활성화됨", "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "user": { "name": "user@example.com", "type": "user" } } ]

  4. containerapp 확장 프로그램을 설치하세요:

    az extension add --name containerapp -upgrade 설치된 확장 프로그램 'containerapp'은 미리보기에 있습니다.

도전 1: NGINX 컨테이너 앱 생성 및 배포

이 초기 과제에서는 카나리아 블루-그린 배포의 기준으로 사용되는 애플리케이션의 초기 버전인 NGINX Azure Container App을 만듭니다. Azure Container Apps는 프로덕션에 적합한 컨테이너 환경에서 컨테이너에 패키징된 애플리케이션 코드를 쉽게 실행하는 데 사용하는 Microsoft Azure 서비스입니다.

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

    az 그룹 생성 --이름 내 컨테이너 앱 rg --위치 westus { "id": "/구독/0efafl2-38ad-41w8-g49a-0ecc6723l97c/리소스그룹/내 컨테이너 앱 rg", "위치: "westus", "managedBy": null, "이름": "내 컨테이너 앱 rg", "속성": { "provisioningState": "성공" }, "태그": null, "유형": "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 ... - 이미지: 레지스트리: cac085021b77acr .azurecr.io 저장소: my-container-app 태그: "20230315212413756768" 다이제스트: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... 런타임 종속성: 레지스트리: registry.hub.docker.com 리포지토리: library/nginx 태그: "1.23" 다이제스트: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} 실행 ID: cf1이 27초 후에 성공했습니다. 리소스 그룹 my-container-app-rg에 Containerapp my-container-app을 생성합니다. 이름이 "ca2ffbce7810acrazurecrio-cac085021b77acr"인 레지스트리 비밀번호를 비밀로 추가합니다. 컨테이너 앱이 생성되었습니다. https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ 에서 앱에 액세스하세요.

  3. 2단계의 출력에서 Azure Container Registry (ACR)에 만든 컨테이너 앱의 이름과 URL을 찾습니다. 샘플 출력에서는 주황색으로 강조 표시되어 있습니다. 튜토리얼 전체에서 명령에 표시된 변수는 2단계의 샘플 출력과 다른 출력 값에서 대체됩니다.

    • 컨테이너 앱 이름 – image.registry 키에서 .azurecr.io 앞의 문자열입니다. 2단계의 샘플 출력에서는 cac085021b77acr 입니다.

      이 문자열을 다음으로 대체하세요. <ACR_이름> 이후 명령에서는.

    • 컨테이너 앱의 URL – Container app created로 시작하는 줄의 URL입니다. 2단계의 샘플 출력에서는 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ 입니다.

      이 URL을 다음으로 대체하세요. <ACR_URL> 이후 명령에서는.

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

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

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

    컬 <ACR_URL>/건강좋아요

도전 2: Azure 컨테이너 앱 배포 자동화를 위한 권한 설정

이 챌린지에서는 Azure 컨테이너 앱 배포를 자동화하는 데 필요한 JSON 토큰을 얻습니다.

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

이러한 단계들은 지루해 보일 수 있지만, 새로운 애플리케이션을 만들 때 한 번만 수행하면 되며, 프로세스를 완전히 스크립팅할 수 있습니다. 튜토리얼에서는 각 단계를 직접 수행하여 익숙해지도록 합니다.

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

  1. 관리되는 ID의 주체 ID를 찾으세요. 이는 출력의 PrincipalID 열에 나타납니다(읽기 편하도록 두 줄로 나뉩니다). 이 값을 다음으로 대체합니다. <관리되는 ID 주체 ID> 3단계:

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

  2. ACR에서 컨테이너 앱의 리소스 ID를 찾아 교체합니다. <ACR_이름> 3단계에서 기록한 이름으로 도전 1. 이 값을 다음으로 대체합니다. <ACR_리소스_ID> 다음 단계에서:

    az acr show --name <ACR_이름> --쿼리 ID --출력 tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

  3. 컨테이너 앱의 관리되는 ID에 ACR에 대한 기본 제공 Azure 역할을 할당하여 대체합니다. <관리되는 ID 주체 ID> 1단계에서 얻은 관리 ID를 사용하여 <ACR_리소스_ID> 2단계에서 얻은 리소스 ID를 사용하여:

    az 역할 할당 생성 \ --assignee <관리되는 ID 주체 ID> \
--역할 AcrPull \
--범위 <ACR_리소스_ID>
{
"조건": null,
"조건버전": null,
"생성자": null,
"생성일": "2023-03-15T20:28:40.831224+00:00", "위임된 관리 ID 리소스 ID": null, "설명": null, "ID": "/구독/0efafl2-38ad-41w8-g49a-0ecc6723l97c/리소스 그룹/내-컨테이너-앱-rg/공급자/Microsoft.컨테이너 레지스트리/레지스트리/cac085021b77acr/공급자/Microsoft.권한 부여/역할 할당/f0773943-8769-44c6-a820-ed16007ff249", "이름": "f0773943-8769-44c6-a820-ed16007ff249", "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f", "principalType": "서비스 주체", "리소스 그룹": "내 컨테이너 앱 rg", "역할 정의 ID": "/구독/60e32142-384b-43r8-9329-0ecc67dca94c/공급자/Microsoft.권한 부여/역할 정의/7fd21dda-4fd3-4610-a1ca-43po272d538d", "범위": "/구독/0efafl2-38ad-41w8-g49a-0ecc6723l97c/리소스 그룹/내 컨테이너 앱 rg/공급자/Microsoft.ContainerRegistry/레지스트리/cac085021b77acr", "유형": "Microsoft.Authorization/roleAssignments", "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d", "updatedOn": "2023-03-15T20:28:41.127243+00:00" }

  4. ACR에서 이미지를 가져올 때 관리되는 ID를 사용하도록 컨테이너 앱을 구성합니다. <ACR_이름> 3단계에서 기록한 컨테이너 앱 이름을 사용하여 도전 1 (위의 2단계에서도 사용됨):

    az 컨테이너 앱 레지스트리 세트 \ --name my-container-app \
--resource-group my-container-app-rg \
--server <ACR_이름>.azurecr.io \
--아이덴티티 시스템
[
{
"identity": "시스템",
"passwordSecretRef": "",
"server": "cac085021b77acr.azurecr.io",
"username": ""
}
]

  5. Azure 구독 ID를 찾으세요.

    az 계정 표시 --쿼리 ID --출력 tsv 0efafl2-38ad-41w8-g49a-0ecc6723l97c

  6. GitHub 작업에서 사용할 자격 증명을 포함하는 JSON 토큰을 생성하여 다음을 대체합니다. <구독_ID> Azure 구독 ID를 사용하여 붙여넣을 출력을 저장합니다. AZURE 자격 증명 안에 GitHub 저장소에 비밀 추가. --sdk-auth가 더 이상 사용되지 않는다는 경고는 무시해도 됩니다. 이는 알려진 문제 입니다.

    az ad sp create-for-rbac \ --name my-container-app-rbac \
--role contributor \
--scopes /subscriptions/<구독_ID>/resourceGroups/my-container-app-rg \
--sdk-auth \
--출력 json
옵션 '--sdk-auth'는 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.
...
{
"clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er", "클라이언트 시크릿": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe", "구독 ID": "0efafl2-38ad-41w8-g49a-0ecc6723l97c", "테넌트 ID": "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/" }

도전 3: Canary Blue-Green 배포 GitHub 작업 만들기

이 챌린지에서는 GitHub 저장소에 비밀을 추가하고 (GitHub Action 워크플로에서 중요한 데이터를 관리하는 데 사용됨), Action 워크플로 파일을 만들고 , Action 워크플로를 실행합니다 .

비밀 관리에 대한 자세한 소개는 블로그의 마이크로서비스에 대한 두 번째 튜토리얼인 3월 23일, 컨테이너에서 비밀을 안전하게 관리하는 방법을 참조하세요.

GitHub 저장소에 비밀 추가

애플리케이션의 새 버전을 배포하려면 설정 에서 포크한 GitHub 저장소에 일련의 비밀을 만들어야 합니다. 비밀은 챌린지 2 에서 생성된 관리 ID에 대한 JSON 자격 증명과 Azure에 NGINX 이미지의 새 버전을 배포하는 데 필요한 일부 중요한 배포 관련 매개변수입니다. 다음 섹션 에서는 GitHub Action에서 이러한 비밀을 사용하여 카나리아 블루-그린 배포를 자동화합니다.

  • GitHub GUI를 사용하는 경우:

    1. 포크된 GitHub 저장소로 이동합니다.
    2. 설정 > 비밀 및 변수 > 작업을 선택합니다.
    3. 새로운 저장소 비밀을 클릭합니다.

    4. 표시된 필드에 다음 값을 입력하세요.

      • 이름 – AZURE_CREDENTIALS
      • 비밀 – 챌린지 2 의 6단계에서 얻은 JSON 자격 증명
    5. 비밀 추가를 클릭합니다.

    6. 표에 나열된 비밀을 만들려면 3~5단계를 3번 반복하세요. 비밀 이름 및 비밀 값 열의 값을 각각 GUI의 이름 및 비밀 필드에 입력합니다. 세 번째 비밀은 다음과 같이 대체합니다. <ACR_이름> 3단계에서 기록한 컨테이너 앱에 할당된 이름을 사용하여 도전 1.

      비밀 이름 비밀 가치
      컨테이너 앱 이름 내 컨테이너 앱
      리소스 그룹 내 컨테이너 앱 rg
      ACR_이름 <ACR_이름>
    7. GitHub Action Workflow 파일을 만듭니다 .

  • GitHub CLI를 사용하는 경우:

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

      ~/creds.json을 터치하세요
    2. 선호하는 텍스트 편집기를 사용하여 creds.json을 열고 챌린지 2 의 6단계에서 만든 JSON 자격 증명을 복사합니다.

    3. 비밀을 만드세요:

      gh 비밀 설정 AZURE_CREDENTIALS --repo <귀하의 GitHub 계정>/플랫폼 < ~/creds.json

    4. creds.json 삭제:

      rm ~/creds.json

    5. 세 개의 비밀을 더 생성하려면 이 명령을 반복하세요.

      gh 시크릿 세트 <비밀_이름> --저장소 <귀하의 GitHub 계정>/플랫폼

      각 반복마다 다음을 교체합니다. <비밀_이름> 값 중 하나를 사용하여 비밀 이름 표의 열. 프롬프트에서 비밀 값 열에서 연관된 값을 붙여넣습니다. 세 번째 비밀은 다음과 같이 대체합니다. <ACR_이름> 3단계에서 기록한 컨테이너 앱에 할당된 이름을 사용하여 도전 1.

      비밀 이름 비밀 가치
      컨테이너 앱 이름 내 컨테이너 앱
      리소스 그룹 내 컨테이너 앱 rg
      ACR_이름 <ACR_이름>

GitHub Action 워크플로 파일 만들기

관리되는 ID와 비밀이 준비되면 카나리아 블루-그린 배포를 자동화하는 GitHub Action에 대한 워크플로 파일을 만들 수 있습니다.

메모: 워크플로 파일은 YAML 형식으로 정의되며, 공백은 중요합니다. 아래 단계에서 표시된 들여쓰기를 반드시 유지하세요.

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

    • GitHub GUI를 사용하는 경우:

      1. GitHub 저장소로 이동합니다.
      2. 작업 > 새 워크플로 > 건너뛰기 및 직접 워크플로 설정을 선택하세요.

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

      mkdir .github/workflowstouch .github/workflows/main.yml

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

    메모: 워크플로 파일은 YAML 형식으로 정의되며, 공백은 중요합니다. 스니펫을 복사하는 경우 들여쓰기를 유지해야 합니다. (확실히 확인하려면 파일을 전체 워크플로 파일 과 비교하세요.)

    • 워크플로 이름을 정의합니다.

      이름: Azure에 배포

    • 메인 브랜치에 푸시 또는 풀 요청이 이루어질 때 실행되도록 워크플로를 구성합니다.

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

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

      jobs: build-deploy: runs-on: ubuntu-22.04 steps: - name: 코드베이스 사용을 확인하세요: actions/checkout@v3 - name: Azure에 로그인하려면 다음을 사용합니다. azure/login@v1 with: creds:${{ secrets.AZURE_CREDENTIALS } } - 이름: 컨테이너 앱 빌드 및 배포 실행: | # 컨테이너 앱 확장을 수동으로 추가 az extension add --name containerapp --upgrade # Azure CLI를 사용하여 업데이트 배포 az containerapp up -n${{ secrets.CONTAINER_APP_NAME } }\ -g${{ secrets.RESOURCE_GROUP } } \ --원천${{ github.workspace } }/ingress \ --레지스트리 서버${{ secrets.ACR_NAME } }.azurecr.io

    • 새로 배포된 개정판의 스테이징 URL을 가져오고 GitHub Action을 사용하여 API 엔드포인트 /health 에 ping을 보내 새 개정판이 응답하는지 확인하는 테스트 배포 작업을 정의합니다. 상태 검사에 성공하면 컨테이너 앱의 Azure Traffic Manager가 업데이트되어 모든 트래픽이 새로 배포된 컨테이너를 가리키도록 합니다.

      메모: 이전 항목에서 정의한 빌드- 배포 키와 동일한 수준에서 테스트-배포 키를 들여쓰기해야 합니다.

        테스트 배포: 필요 사항: 빌드 배포 실행: ubuntu-22.04 단계: - 이름: Azure에 로그인하려면 다음을 사용합니다. azure/login@v1 with: creds:${{ secrets.AZURE_CREDENTIALS } } - 이름: 새 컨테이너 이름 가져오기 실행: | # containerapp 확장 프로그램을 수동으로 추가 az extension add --name containerapp --upgrade # 마지막으로 배포된 개정판 이름 가져오기 REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # 마지막으로 배포된 개정판의 fqdn을 가져옵니다 REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # env vars에 값 저장 echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: 테스트 배포 ID: test-deployment uses: jtalk/url-health-check-action@v3 # 엔드포인트를 터치하기 위한 마켓플레이스 작업: url: "https://${{ env.REVISION_FQDN } }/health" # 스테이징 엔드포인트 - 이름: 배포 성공: | echo "배포 성공! 새로운 개정판 활성화" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --수정-가중치 "${{ env.REVISION_NAME } }=100"

전체 워크플로 파일

이는 Action 워크플로 파일의 전체 텍스트입니다.

이름: Azure에 배포: push: branches: - main pull_request: branches: - main jobs: build-deploy: runs-on: ubuntu-22.04 steps: - name: 코드베이스 사용을 확인하세요: actions/checkout@v3 - name: Azure에 로그인하려면 다음을 사용합니다. azure/login@v1 with: creds:${{ secrets.AZURE_CREDENTIALS } } - 이름: 컨테이너 빌드 및 배포 실행: | # containerapp 확장을 수동으로 추가 az extension add --name containerapp -upgrade # Azure CLI를 사용하여 업데이트 배포 az containerapp up -n${{ secrets.CONTAINER_APP_NAME } } \ -g${{ secrets.RESOURCE_GROUP } } \ --원천${{ github.workspace } }/ingress \ --레지스트리 서버${{ secrets.ACR_NAME } }.azurecr.io 테스트 배포: 필요 사항: 빌드 배포 실행: ubuntu-22.04 단계: - 이름: Azure에 로그인하려면 다음을 사용합니다. azure/login@v1 with: creds:${{ secrets.AZURE_CREDENTIALS } } - 이름: 새 컨테이너 이름 가져오기 실행: | # Azure CLI용 containerapp 확장 프로그램 설치 az extension add --name containerapp --upgrade # 마지막으로 배포된 개정판 이름 가져오기 REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # 마지막으로 배포된 개정판의 fqdn을 가져옵니다 REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # env vars에 값 저장 echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: 테스트 배포 ID: test-deployment uses: jtalk/url-health-check-action@v3 # 엔드포인트를 터치하기 위한 마켓플레이스 작업: url: "https://${{ env.REVISION_FQDN } }/health" # 스테이징 엔드포인트 - 이름: 배포 성공: | echo "배포 성공! 새로운 개정판 활성화" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --수정-가중치 "${{ env.REVISION_NAME } }=100"

작업 워크플로 실행

  • GitHub GUI를 사용하는 경우:

    1. 시작 커밋을 클릭하고 원하는 경우 커밋 메시지를 추가한 다음 대화 상자에서 새 파일 커밋을 선택합니다. 새로운 워크플로 파일이 메인 브랜치에 병합되고 실행이 시작됩니다.
    2. 작업을 클릭하여 워크플로 진행 상황을 모니터링합니다.

  • GitHub CLI를 사용하는 경우:

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

      git add .github/workflows/main.yml

    2. 파일을 커밋합니다.

      git commit -m "feat: GitHub Actions 워크플로 생성"

    3. 변경 사항을 GitHub에 푸시하세요:

      git 푸시

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

      gh 워크플로 뷰 main.yml --repo <귀하의 GitHub 계정>/플랫폼

도전 4: GitHub Actions 워크플로 테스트

이 챌린지에서는 워크플로를 테스트합니다. 먼저 Ingress 로드 밸런서의 업데이트가 성공적으로 완료되었는지 시뮬레이션하고 애플리케이션이 업데이트되었는지 확인합니다. 그런 다음 실패한 업데이트(내부 서버 오류로 이어짐)를 시뮬레이션하고 게시된 애플리케이션이 변경되지 않은지 확인합니다.

성공적인 업데이트 만들기

성공적인 업데이트를 만들고 워크플로가 성공하는 모습을 살펴보세요.

  • GitHub GUI를 사용하는 경우:

    1. 코드 > ingress > default.conf.template을 선택합니다.
    2. 도구 설명이 있는 연필 아이콘을 선택하여 default.conf.template을 편집용으로 엽니다. 이 파일을 편집하세요 .

    3. 파일 끝 부분에 있는 location /health 블록에서 return 지시문을 표시된 대로 변경합니다.

      위치 /건강 {
액세스 로그 오프;
return 200 "업데이트 성공!\n";
}
    4. 대화 상자에서 이 커밋에 대한 새 브랜치 만들기 및 풀 리퀘스트 시작을 선택한 다음 변경 사항 제안을 선택합니다.
    5. 풀 리퀘스트 템플릿에 액세스하려면 풀 리퀘스트 만들기를 클릭하세요.
    6. 다시 '풀 리퀘스트 만들기'를 클릭하여 풀 리퀘스트를 만듭니다.
    7. 작업을 클릭하여 워크플로 진행 상황을 모니터링합니다.
    8. 워크플로가 완료되면 컨테이너 앱으로 이동합니다. <ACR_URL>/건강 종료 지점, 여기서 <ACR_URL> 3단계에서 기록한 URL입니다. 도전 1. 업데이트가 성공적으로 완료되었습니다 ! 라는 메시지를 확인하세요.

    9. 터미널 세션을 시작하고 앱에 상태 확인 요청을 보내어 메시지를 확인할 수 있습니다. <ACR_URL> 3단계에서 기록한 값으로 도전 1:

      컬 <ACR_URL>/건강성공적으로 업데이트되었습니다!
    10. 실패한 업데이트를 진행합니다.

  • GitHub CLI를 사용하는 경우:

    1. patch-1 이라는 새로운 브랜치를 만듭니다.

      git checkout -b 패치-1

    2. 선호하는 텍스트 편집기에서 ingress/default.conf.template을 열고 파일 끝부분에 있는 location /health 블록에서 return 지시문을 표시된 대로 변경합니다.

      위치 /건강 {
액세스 로그 오프;
return 200 "업데이트 성공!\n";
}

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

      git add ingress/default.conf.template

    4. 파일을 커밋합니다.

      git commit -m "feat: NGINX ingress 업데이트"

    5. 변경 사항을 GitHub에 푸시하세요:

      git push --set-upstream origin 패치-1

    6. 풀 리퀘스트(PR)를 만드세요:

      gh pr create --head patch-1 --fill --repo <귀하의_GitHub_계정> /platform

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

      gh 워크플로 뷰 main.yml --repo <귀하의 GitHub 계정>/플랫폼

    8. 워크플로가 완료되면 앱에 상태 확인 요청을 보내어 교체합니다. <ACR_URL> 3단계에서 기록한 값으로 도전 1:

      컬 <ACR_URL>/건강
업데이트 성공!

실패한 업데이트 만들기

이제 실패한 업데이트를 만들고 워크플로가 실패하는 모습을 살펴보세요. 기본적으로 성공적인 업데이트 수행 의 단계를 반복하지만 반환 지시문에 다른 값을 적용하는 것입니다.

  • GitHub GUI를 사용하는 경우:

    1. 코드 > ingress > default.conf.template을 선택합니다.
    2. 왼쪽 상단에서 main을 선택한 다음, 이전 섹션 에서 만든 patch-1 로 끝나는 브랜치 이름을 선택합니다.
    3. 도구 설명이 있는 연필 아이콘을 선택하여 default.conf.template을 편집용으로 엽니다. 이 파일을 편집하세요 .

    4. 표시된 대로 반환 지침을 변경하세요.

      location /health {
access_log off;
return 500 "업데이트 실패!\n";
}
    5. -patch-1 브랜치에 직접 커밋을 선택한 다음 변경 내용 커밋을 선택합니다.
    6. 워크플로 진행 상황을 모니터링하려면 작업을 선택하세요. PR의 파일이 업데이트되면 워크플로가 다시 실행되는지 확인하세요.

    7. 워크플로가 완료되면 컨테이너 앱으로 이동합니다. <ACR_URL>/건강 종료 지점, 여기서 <ACR_URL> 3단계에서 기록한 URL입니다. 도전 1.

       

      메시지가 업데이트 성공 ! (이전의 업데이트 성공과 동일)이라는 점에 유의하세요. 역설적으로 보일 수 있지만 실제로는 이 업데이트가 실패했음을 확인합니다. 업데이트 시도로 인해 상태가 다음과 같이 되었습니다.500 ( 내부 서버 오류를 의미) 적용되지 않았습니다.

    8. 터미널 세션을 시작하고 앱에 상태 확인 요청을 보내어 메시지를 확인할 수 있습니다. <ACR_URL> 3단계에서 기록한 값으로 도전 1:

      컬 <ACR_URL>/건강성공적으로 업데이트되었습니다!

  • GitHub CLI를 사용하는 경우:

    1. 이전 섹션 에서 만든 patch-1 브랜치를 확인하세요.

      git 체크아웃 패치-1

    2. 원하는 텍스트 편집기에서 ingress/default.conf.template을 열고 return 지시문을 표시된 대로 다시 변경하세요.

      location /health {
access_log off;
return 500 "업데이트 실패!\n";
}

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

      git add ingress/default.conf.template

    4. 파일을 커밋합니다.

      git commit -m "feat: NGINX ingress를 다시 업데이트하세요"

    5. 변경 사항을 GitHub에 푸시하세요:

      git 푸시

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

      gh 워크플로 뷰 main.yml --repo <귀하의 GitHub 계정>/플랫폼

    7. 워크플로가 완료되면 앱에 상태 확인 요청을 보내어 교체합니다. <ACR_URL> 3단계에서 기록한 값으로 도전 1:

      컬 <ACR_URL>/건강성공적으로 업데이트되었습니다!

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

자원 정리

추후에 발생할 수 있는 요금 청구를 피하기 위해 튜토리얼에서 배포한 Azure 리소스를 제거하는 것이 좋습니다.

az 그룹 삭제 -n my-container-app-rg -y

원하시면 생성한 포크를 삭제할 수도 있습니다.

  • GitHub GUI를 사용하는 경우:

    1. 설정을 클릭하세요.
    2. 페이지 맨 아래로 스크롤하세요.
    3. 이 저장소 삭제를 클릭합니다.
    4. 유형 <귀하의 GitHub 계정>/플랫폼 그리고 선택하세요 결과를 이해합니다. 이 저장소를 삭제합니다..

  • GitHub CLI를 사용하는 경우:

    gh repo 삭제 <귀하의 GitHub 계정>/플랫폼 -예

다음 단계

축하해요! GitHub Actions를 사용하여 마이크로서비스 앱의 카나리아 블루-그린 배포를 수행하는 방법을 배웠습니다. GitHub 문서에서 다음 문서를 확인하여 DevOps에 대한 지식을 계속 탐구하고 키우세요.

카나리아 배포의 두 번째 단계(운영 환경에서의 테스트)를 시도할 준비가 되었다면 블로그에서 2022년 3월 마이크로서비스 튜토리얼 '카나리아 배포로 가동 시간과 복원력 개선'을 확인하세요. NGINX Service Mesh를 사용하여 점진적으로 새로운 앱 버전으로 전환합니다. 배포가 아직 서비스 메시가 필요할 만큼 복잡하지 않거나 Kubernetes를 사용하지 않는 경우에도 이러한 원칙은 Ingress 컨트롤러나 로드 밸런서만 사용하는 간단한 배포에 여전히 적용됩니다.

마이크로서비스 교육을 계속하려면 2023년 3월 마이크로서비스를 확인하세요. 3단원 '자동화를 통해 마이크로서비스 배포 가속화' 에서는 배포 자동화에 대해 자세히 알아봅니다.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."