다음을 통해 공유

Azure Container Apps에서 Python 웹앱에 대한 지속적인 배포 구성

  • 아티클

이 문서는 Python 웹앱을 컨테이너화하고 Azure Container Apps에 배포하는 방법에 대한 자습서의 일부입니다. Container Apps를 사용하면 복잡한 인프라를 관리하지 않고 컨테이너화된 앱을 배포할 수 있습니다.

자습서의 이 부분에서는 컨테이너 앱에 대한 CD(지속적인 배포 또는 배달)를 구성하는 방법에 대해 알아봅니다. CD는 앱 개발 워크플로의 자동화인 CI/CD(지속적인 통합/지속적인 업데이트)에 대한 DevOps 사례의 일부입니다. 특히 지속적인 배포를 위해 GitHub Actions를 사용합니다.

이 서비스 다이어그램은 이 문서에서 다루는 구성 요소인 CI/CD 구성을 강조 표시합니다.

자습서의 서비스 스크린샷 - Azure Container Apps에 Python 앱 배포. 강조 표시된 섹션은 CI/CD(지속적인 통합) 관련 부분입니다.

필수 조건

지속적인 배포를 설정하려면 다음이 필요합니다.

  • Azure Container Registry 및 Azure Container Apps의 컨테이너 앱을 포함하는 이 자습서 시리즈의 이전 문서에서 만든 리소스 및 해당 구성입니다.

  • 샘플 코드(Django 또는 Flask)를 포크하고 Azure Container Apps에서 연결할 수 있는 GitHub 계정입니다. (분기하는 대신 샘플 코드를 다운로드한 경우 로컬 리포지토리를 GitHub 계정에 푸시해야 합니다.)

  • 필요에 따라 Git 이 개발 환경에 설치되어 코드를 변경하고 GitHub의 리포지토리로 푸시합니다. 또는 GitHub에서 직접 변경할 수 있습니다.

컨테이너에 대한 CD 구성

이 자습서의 이전 문서에서는 Azure Container Apps에서 컨테이너 앱을 만들고 구성했습니다. 구성의 일부는 Azure Container Registry에서 Docker 이미지를 끌어와는 것이었습니다. 컨테이너 앱을 처음 설정할 때와 같이 컨테이너 수정 버전을 만들 때 레지스트리에서 컨테이너 이미지를 가져옵니다.

이 섹션에서는 GitHub Actions 워크플로를 사용하여 지속적인 배포를 설정합니다. 연속 배포를 사용하면 트리거를 기반으로 새 Docker 이미지 및 컨테이너 수정 버전이 만들어집니다. 이 자습서의 트리거는 PR(끌어오기 요청)과 같이 리포지토리의 기본 분기를 변경하는 것입니다. 트리거되면 워크플로는 새 Docker 이미지를 만들고, Azure Container Registry로 푸시하고, 새 이미지를 사용하여 컨테이너 앱을 새 수정 버전으로 업데이트합니다.

Azure CLI 명령은 Azure Cloud Shell에서 실행하거나 Azure CLI가 설치된 워크스테이션에서 실행할 수 있습니다.

Windows 컴퓨터의 Git Bash 셸에서 명령을 실행하는 경우 계속하기 전에 다음 명령을 입력합니다.

export MSYS_NO_PATHCONV=1

1단계. az ad sp create-for-rbac 명령을 사용하여 서비스 주체를 만듭니다.

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

여기서

  • <app-name> 은 서비스 주체에 대한 선택적 표시 이름입니다. 옵션을 해제 --name 하면 GUID가 표시 이름으로 생성됩니다.
  • <subscription-ID> 는 Azure에서 구독을 고유하게 식별하는 GUID입니다. 구독 ID를 모르는 경우 az account show 명령을 실행하고 출력의 id 속성에서 복사할 수 있습니다.
  • <resource-group-name> 은 Azure Container Apps 컨테이너를 포함하는 리소스 그룹의 이름입니다. RBAC(역할 기반 액세스 제어)는 리소스 그룹 수준에 있습니다. 이 자습서의 이전 문서의 단계를 수행한 경우 리소스 그룹 이름은 다음과 같습니다 pythoncontainer-rg.

다음 단계, 특히 클라이언트 ID(속성), 클라이언트 암호(appId속성) 및 테넌트 ID(passwordtenant속성)에 대해 이 명령의 출력을 저장합니다.

2단계. az containerapp github-action add 명령을 사용하여 GitHub Actions를 구성합니다.

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

여기서

  • <resource-group-name> 은 리소스 그룹의 이름입니다. 이 자습서를 따르는 경우 "pythoncontainer-rg"입니다.
  • <https://github.com/userid/repo> 는 GitHub 리포지토리의 URL입니다. 이 자습서의 단계를 수행하는 경우 GitHub 사용자 ID가 있는 위치 userid 또는 https://github.com/userid/msdocs-python-django-azure-container-appshttps://github.com/userid/msdocs-python-flask-azure-container-apps그 위치입니다.
  • <registry-name> 은 이 자습서에서 만든 기존 Container Registry 또는 사용할 수 있는 컨테이너 레지스트리입니다.
  • <client-id>는 이전 az ad sp create-for-rbac 명령의 appId 속성 값입니다. ID는 000000000-0000-0000-0000-0000-000000000 형식의 GUID입니다.
  • <tenant-id>는 이전 az ad sp create-for-rbac 명령의 tenant 속성 값입니다. ID는 클라이언트 ID와 유사한 GUID이기도 합니다.
  • <client-secret>은 이전 az ad sp create-for-rbac 명령의 password 속성 값입니다.

지속적인 배포 구성에서 서비스 주체 는 GitHub Actions가 Azure 리소스에 액세스하고 수정할 수 있도록 하는 데 사용됩니다. 리소스에 대한 액세스는 서비스 주체에 할당된 역할에 의해 제한됩니다. 서비스 주체에 컨테이너 앱이 포함된 리소스 그룹에 기본 제공 기여자 역할이 할당되었습니다.

포털에 대한 단계를 수행한 경우 서비스 주체가 자동으로 생성됩니다. Azure CLI에 대한 단계를 수행한 경우 연속 배포를 구성하기 전에 먼저 서비스 주체를 명시적으로 만들었습니다.

GitHub Actions를 사용하여 웹앱 다시 배포

이 섹션에서는 샘플 리포지토리의 포크된 복사본을 변경하고 변경 내용이 웹 사이트에 자동으로 배포되도록 확인합니다.

아직 없는 경우 샘플 리포지토리(Django 또는 Flask)의 포크를 만듭니다. Git을 사용하는 명령줄에서 GitHub 또는 개발 환경에서 직접 코드를 변경할 수 있습니다.

1단계. 샘플 리포지토리의 포크로 이동하여 주 분기에서 시작합니다.

샘플 리포지토리의 포크를 보여 주는 스크린샷과 주 분기에서 시작합니다.

2단계. 변경합니다.

  • /templates/base.html 파일로 이동합니다. (Django의 경우 경로는 restaurant_review/templates/restaurant_review/base.html)입니다.
  • 편집을 선택하고 "Azure Restaurant Review" 구를 "Azure Restaurant Review - 재배포됨"으로 변경합니다.

샘플 리포지토리의 포크에서 템플릿 파일을 변경하는 방법을 보여 주는 스크린샷

3단계 변경 내용을 주 분기에 직접 커밋합니다.

  • 편집하는 페이지의 아래쪽에서 커밋 단추를 선택합니다.
  • 커밋은 GitHub Actions 워크플로를 시작합니다.

샘플 리포지토리의 포크에서 템플릿 파일의 변경 내용을 커밋하는 방법을 보여 주는 스크린샷

참고 항목

주 분기에서 직접 변경하는 것을 보여 줬습니다. 일반적인 소프트웨어 워크플로에서는 기본이 아닌 분기를 변경한 다음 PR(끌어오기 요청)을 만들어 해당 변경 사항을 기본으로 병합합니다. 또한 PR은 워크플로를 시작합니다.

GitHub Actions 정보

워크플로 기록 보기

1단계. GitHub에서 샘플 리포지토리의 포크로 이동하여 작업 탭을 엽니다.

리포지토리에 대한 GitHub Actions를 보고 워크플로를 보는 방법을 보여 주는 스크린샷

워크플로 암호

리포지토리에 추가된 .github/workflows/<workflow-name>.yml 워크플로 파일에 워크플로의 빌드 및 컨테이너 앱 업데이트 작업에 필요한 자격 증명에 대한 자리 표시자가 표시됩니다. 자격 증명 정보는 보안/비밀 및 변수 작업 아래의 리포지토리 설정에 암호화되어 저장됩니다./

GitHub Actions 비밀이 GitHub에 저장되는 위치를 확인하는 방법을 보여 주는 스크린샷

자격 증명 정보가 변경되면 여기에서 업데이트할 수 있습니다. 예를 들어 Azure Container Registry 암호가 다시 생성되는 경우 REGISTRY_PASSWORD 값을 업데이트해야 합니다. 자세한 내용은 GitHub 설명서의 암호화된 비밀을 참조하세요.

OAuth 권한 있는 앱

지속적인 배포를 설정할 때 Azure Container Apps에 GitHub 계정에 대한 권한 있는 OAuth 앱 권한을 부여합니다. Container Apps는 권한 있는 액세스를 사용하여 .github/workflows/<workflow-name>.yml GitHub Actions YML 파일을 만듭니다. 계정의 통합/애플리케이션에서 권한 있는 앱을 보고 권한을 취소할 수 있습니다.

GitHub에서 사용자에 대한 권한 있는 앱을 보는 방법을 보여 주는 스크린샷

문제 해결 팁

Azure CLI az ad sp create-for-rba 명령을 사용하여 서비스 주체를 설정하는 동안 오류가 발생했습니다.

  • "InvalidSchema: 연결 어댑터를 찾을 수 없음"이 포함된 오류가 표시됩니다.

    • 실행 중인 셸을 확인합니다. Bash 셸을 사용하는 경우 다음과 같이 MSYS_NO_PATHCONV 변수를 export MSYS_NO_PATHCONV=1설정합니다. 자세한 내용은 Git Bash 셸에서 Azure CLI를 사용하여 서비스 주체를 만들 수 없고 연결 어댑터를 찾을 수 없는 GitHub 문제를 참조하세요.

  • "둘 이상의 애플리케이션에 동일한 표시 이름이 있습니다."가 포함된 오류가 표시됩니다.

    • 이 오류는 서비스 주체에 대한 이름이 이미 사용되었음을 나타냅니다. 다른 이름을 선택하거나 인수를 --name 해제하면 GUID가 표시 이름으로 자동으로 생성됩니다.

GitHub Actions 워크플로가 실패했습니다.

  • 워크플로의 상태를 확인하려면 리포지토리의 작업 탭으로 이동합니다.
  • 실패한 워크플로가 있는 경우 워크플로 파일을 드릴인합니다. "빌드" 및 "배포"라는 두 가지 작업이 있어야 합니다. 실패한 작업의 경우 작업 태스크의 출력을 확인하여 문제를 찾습니다.
  • "TLS 핸드셰이크 시간 제한"이라는 오류 메시지가 표시되면 리포지토리의 작업 탭에서 트리거 자동 배포를 선택하여 워크플로를 수동으로 실행하여 시간 초과가 일시적인 문제인지 확인합니다.
  • 이 자습서와 같이 컨테이너 앱에 대한 지속적인 배포를 설정하는 경우 워크플로 파일(.github/workflows/<workflow-name>.yml)이 자동으로 만들어집니다. 이 자습서에서는 이 파일을 수정할 필요가 없습니다. 변경한 경우 변경 내용을 되돌리고 워크플로를 시도합니다.

웹 사이트에는 기본 분기에 병합한 변경 내용이 표시되지 않습니다.

  • GitHub에서: GitHub Actions 워크플로가 실행되었고 워크플로를 트리거하는 분기에 변경 내용이 있는지 확인합니다.
  • Azure Portal에서: 분기를 변경한 후 타임스탬프를 사용하여 새 Docker 이미지가 만들어졌는지 확인하려면 Azure Container Registry를 확인합니다.
  • Azure Portal에서 컨테이너 앱의 로그를 확인합니다. 프로그래밍 오류가 있는 경우 여기에 표시됩니다.
    • 컨테이너 앱으로 이동 | 수정 관리 | <활성 컨테이너> | 수정 세부 정보 | 콘솔 로그
    • 열의 순서를 선택하여 "생성 시간", "Stream_s" 및 "Log_s"을 표시합니다. 가장 최근의 로그를 먼저 정렬하고 "Stream_s" 열에서 Python stderr 및 stdout 메시지를 찾습니다. Python 'print' 출력은 stdout 메시지입니다.
  • Azure CLI를 사용하여 az containerapp logs show 명령을 사용합니다.

지속적인 배포의 연결을 끊으면 어떻게 되나요?

  • 지속적인 배포 중지는 리포지토리에서 컨테이너 앱의 연결을 끊는 것을 의미합니다. 연결을 끊려면 다음을 수행합니다.

    • Azure Portal에서 컨테이너 앱으로 이동하여 연속 배포 리소스를 선택하고 연결을 끊습니다.
    • Azure CLI를 사용하여 az container app github-action remove 명령을 사용합니다.

  • 연결을 끊은 후 GitHub 리포지토리에서 다음을 수행합니다.

    • .github/workflows/<workflow-name>.yml 파일이 리포지토리에서 제거됩니다.
    • 비밀 키는 제거되지 않습니다.
    • Azure Container Apps는 GitHub 계정에 대한 권한 있는 OAuth 앱 유지됩니다.

  • 연결이 끊긴 후 Azure에서 다음을 수행합니다.

    • 컨테이너는 마지막으로 배포된 컨테이너와 함께 남아 있습니다. 새 컨테이너 수정 버전이 최신 이미지를 선택하게 되도록 컨테이너 앱을 Azure Container Registry와 다시 연결할 수 있습니다.
    • 연속 배포에 대해 만들어지고 사용되는 서비스 주체는 삭제되지 않습니다.

다음 단계

자습서를 완료하고 추가 비용이 발생하지 않으려면 사용된 리소스를 제거합니다. 리소스 그룹을 제거하면 그룹의 모든 리소스가 제거되며 리소스를 제거하는 가장 빠른 방법입니다. 리소스 그룹을 제거하는 방법의 예는 Containerize 자습서 정리를 참조 하세요.

이 자습서를 빌드하려는 경우 수행할 수 있는 몇 가지 다음 단계는 다음과 같습니다.