다음을 통해 공유

Azure App Service 연속 배포

  • 아티클

참고 항목

2024년 6월 1일부터, 새로 만들어진 모든 App Service 앱에는 명명 규칙 <app-name>-<random-hash>.<region>.azurewebsites.net을 사용하여 고유한 기본 호스트 이름을 생성할 수 있는 옵션이 제공됩니다. 기존 앱 이름은 변경되지 않은 상태로 유지됩니다.

예: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

자세한 내용은 App Service 리소스의 고유 기본 호스트 이름을 참조하세요.

Azure App Service는 최신 업데이트를 끌어옴으로써 GitHub, Bitbucket 및 Azure Repos 리포지토리에서 지속적인 배포를 가능하게 합니다.

리포지토리 준비

Azure App Service 빌드 서버에서 자동화된 빌드 기능을 가져오려면 리포지토리 루트에 프로젝트의 올바른 파일이 있는지 확인합니다.

런타임 루트 디렉터리 파일
ASP.NET(Windows만 해당) *.sln, *.csproj 또는 default.aspx
ASP.NET Core *.sln 또는 *.csproj
PHP index.php
Ruby(Linux만 해당) Gemfile
Node.JS server.js, app.js 또는 package.json(시작 스크립트 포함)
Python *.py, requirements.txt 또는 runtime.txt
HTML default.htm, default.html, default.asp, index.htm, index.html 또는 iisstart.htm
WebJobs 연속 WebJobs의 경우 App_Data/jobs/continuous 아래 <job_name>/run.<extension> 또는 트리거된 웹 작업의 경우 App_Data/jobs/triggered입니다. 자세한 내용은 Kudu WebJobs 설명서를 참조하세요.
함수 Azure Functions에 대한 연속 배포를 참조하세요.

배포를 사용자 지정하려면 리포지토리 루트에 .deployment 파일을 포함합니다. 자세한 내용은 배포 사용자 지정 및 사용자 지정 배포 스크립트를 참조하세요.

참고 항목

Visual Studio를 사용하는 경우 Visual Studio에서 자동으로 리포지토리를 만들도록 합니다. 프로젝트는 Git을 통해 즉시 배포할 준비가 됩니다.

배포 원본 구성

  1. Azure Portal에서 App Service 앱의 관리 페이지로 이동합니다.

  2. 왼쪽 창에서 배포 센터를 선택합니다. 그런 다음, 설정을 선택합니다.

  3. 원본 상자에서 CI/CD 옵션 중 하나를 선택합니다.

    배포 원본 선택 방법을 보여 주는 스크린샷

계속하려면 빌드 공급자에 해당하는 탭을 선택합니다.

  1. GitHub Actions는 기본 빌드 공급자입니다. 공급자를 변경하려면 공급자 변경>App Service 빌드 서비스>확인을 선택합니다.

  2. 처음으로 GitHub에서 배포하는 경우 권한 부여를 선택하고 권한 부여 프롬프트를 따릅니다. 다른 사용자의 리포지토리에서 배포하려면 계정 변경을 선택합니다.

  3. GitHub로 Azure 계정에 권한 부여한 후 원하는 조직, 리포지토리 및 분기를 선택합니다.

    조직 또는 리포지토리를 찾을 수 없는 경우 GitHub에 대한 추가 권한을 사용하도록 설정해야 할 수 있습니다. 자세한 내용은 조직의 리포지토리에 대한 액세스 관리를 참조하세요.

  4. 보안 강화를 위해 인증 유형에서 사용자 할당 ID를 선택합니다. 자세한 내용은 질문과 대답을 참조하세요.

    참고 항목

    Azure 계정에 사용자 할당 ID 옵션에 필요한 권한이 있는 경우 Azure는 사용자 할당 관리 ID를 만듭니다. 그렇지 않은 경우 Azure 관리자와 협력하여 앱에 필요한 역할이 있는 ID를 만든 다음, 여기 드롭다운에서 선택합니다.

  5. (선택 사항) 변경 내용을 저장하기 전에 파일을 보려면 파일 미리 보기를 선택합니다. App Service는 앱의 언어 스택 설정을 기반으로 워크플로 템플릿을 선택하고 선택한 GitHub 리포지토리에 커밋합니다.

  6. 저장을 선택합니다.

    선택한 리포지토리 및 분기의 새 커밋이 이제 App Service 앱에 지속적으로 배포됩니다. 로그 탭에서 커밋 및 배포를 추적할 수 있습니다.

지속적 배포 사용 안 함

  1. Azure Portal에서 App Service 앱의 관리 페이지로 이동합니다.

  2. 왼쪽 창에서 배포 센터를 선택합니다. 그런 후 설정>연결 끊기를 선택합니다.

    Azure Portal에서 App Service 앱과 클라우드 폴더의 동기화를 해제하는 방법을 보여 주는 스크린샷

  3. 기본적으로 GitHub Actions 워크플로 파일은 리포지토리에 유지되지만 앱에 대한 배포는 트리거됩니다. 리포지토리에서 파일을 삭제하려면 워크플로 파일 삭제를 선택합니다.

  4. 확인을 선택합니다.

빌드 공급자란?

배포 센터의 배포 원본에 따라 빌드 공급자에 대해 선택할 수 있는 몇 가지 옵션이 표시될 수 있습니다. 빌드 공급자는 빌드, 테스트 및 배포를 자동화하여 Azure App Service로 CI/CD 솔루션을 빌드하는 데 도움을 줍니다.

배포 센터에 있는 빌드 공급자 옵션에 국한되지는 않지만 App Service를 사용하면 신속하게 설정할 수 있으며 일부 통합 배포 로깅 환경을 제공할 수 있습니다.

GitHub Actions 빌드 공급자는 GitHub 배포에만 사용할 수 있습니다. 앱의 배포 센터에서 구성된 경우 CI/CD 설정을 위해 다음 작업을 완료합니다.

  • App Service에 대한 빌드 및 배포 작업을 처리하기 위해 GitHub Actions 워크플로 파일을 GitHub 리포지토리에 저장합니다.
  • 기본 인증의 경우 앱의 게시 프로필을 GitHub 비밀로 추가합니다. 워크플로 파일은 이 비밀을 사용하여 App Service에서 인증합니다.
  • 사용자 할당 ID의 경우 사용자 할당 ID 옵션은 GitHub Actions에 대해 무엇을 수행하나요?를 참조하세요.
  • 워크플로 실행 로그에서 정보를 캡처하여 배포 센터의 로그 탭에 표시합니다.

다음과 같은 방법으로 GitHub Actions 빌드 공급자를 사용자 지정할 수 있습니다.

  • 워크플로 파일이 GitHub 리포지토리에서 생성된 후 이를 사용자 지정합니다. 자세한 내용은 GitHub Actions의 워크플로 구문을 참조하세요. azure/webapps-deploy 작업을 사용하여 워크플로가 App Service에 배포되도록 합니다.
  • 선택한 분기가 보호되는 경우에도 구성을 저장하지 않고 워크플로 파일을 미리 본 다음, 리포지토리에 수동으로 추가할 수 있습니다. 이 방법은 Azure Portal과의 로그 통합을 제공하지 않습니다.
  • 기본 인증 또는 사용자 할당 ID를 사용하는 대신 Microsoft Entra ID의 서비스 주체를 사용하여 배포할 수도 있습니다. 포털에서는 구성할 수 없습니다.

배포하는 동안 앱에서 진행되는 작업

공식적으로 지원되는 모든 배포 방법은 앱의 /home/site/wwwroot 폴더에서 파일을 변경합니다. 이러한 파일은 앱을 실행하는 데 사용됩니다. 따라서 잠긴 파일로 인해 배포가 실패할 수 있습니다. 모든 파일이 동시에 업데이트되는 것은 아니기 때문에 배포하는 동안 앱이 예상과 다르게 동작할 수도 있습니다. 이러한 동작은 고객용 앱에는 바람직하지 않습니다. 이러한 문제를 방지하는 다음과 같은 몇 가지 방법이 있습니다.

자주 묻는 질문

기본 인증을 사용하지 않도록 설정한 경우 GitHub Actions 빌드 공급자가 기본 인증에서 작동하나요?

아니요. GitHub Actions를 사용자 할당 ID 옵션과 함께 사용해 보세요.

자세한 내용은 기본 인증을 사용하지 않고 배포를 참조하세요.

사용자 할당 ID 옵션은 GitHub Actions에 대해 무엇을 수행하나요?

GitHub Actions 원본에서 사용자 할당 ID를 선택하면 App Service는 GitHub Actions에서 권장되는 OpenID Connect 인증을 사용하도록 설정하기 위해 Azure 및 GitHub에서 필요한 모든 리소스를 구성합니다.

특히 App Service는 다음 작업을 수행합니다.

  • Azure에서 사용자가 할당한 관리 ID와 GitHub에서 선택한 리포지토리 및 분기 간에 페더레이션 자격 증명을 만듭니다.
  • 선택한 GitHub 리포지토리의 페더레이션 자격 증명에서 비밀 AZURE_CLIENT_ID, AZURE_TENANT_ID 및 AZURE_SUBSCRIPTION_ID를 만듭니다.
  • 앱에 ID를 할당합니다.

GitHub 리포지토리의 GitHub Actions 워크플로에서 Azure/login 작업을 사용하여 OpenID Connect를 통해 앱을 인증할 수 있습니다. 예를 보려면 GitHub 리포지토리에 워크플로 파일 추가를 참조하세요.

Azure 계정에 필요한 권한이 있는 경우 App Service는 사용자 할당 관리 ID를 만들고 자동으로 구성합니다. 이 ID는 앱의 ID 페이지에 표시되지 않습니다. Azure 계정에 필요한 권한이 없으면 필요한 역할이 있는 기존 ID를 선택해야 합니다.

"관리 ID에 역할 기반 액세스를 할당하고 페더레이션된 자격 증명을 구성할 수 있는 권한이 이 앱에 충분하지 않습니다."라는 오류가 표시되는 이유는 무엇인가요?

이 메시지는 Azure 계정에 GitHub Actions에 대한 사용자 할당 관리 ID를 만드는 데 필요한 권한이 없음을 나타냅니다. 필요한 권한(앱에 따라 범위가 지정됨)은 다음과 같습니다.

  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.ManagedIdentity/userAssignedIdentities/write

기본적으로 사용자 액세스 관리자 역할과 소유자 역할에는 이러한 권한이 이미 있지만 기여자 역할에는 없습니다. 필요한 권한이 없는 경우 Azure 관리자와 협력하여 웹사이트 기여자 역할이 있는 사용자 할당 관리 ID를 만듭니다. 배포 센터의 GitHub>ID 드롭다운에서 ID를 선택할 수 있습니다.

대체 단계에 대한 자세한 내용은 GitHub Actions를 사용하여 App Service에 배포를 참조하세요.

"이 ID에는 이 앱에 대한 쓰기 권한이 없습니다. 다른 ID를 선택하거나 관리자와 협력하여 이 앱의 ID에 웹사이트 기여자 역할을 부여하세요."라는 오류가 표시되는 이유는 무엇인가요?

이 메시지는 선택한 사용자 할당 관리 ID에 GitHub 리포지토리와 App Service 앱 간에 OpenID Connect를 사용하도록 설정하는 데 필요한 역할이 없음을 나타냅니다. ID에는 앱에서 소유자, 기여자, 웹사이트 기여자 역할 중 하나가 있어야 합니다. ID에 필요한 최소 권한 역할은 웹사이트 기여자입니다.

추가 리소스