App Service에 배포
개발 팀마다 요구 사항이 다르기 때문에 클라우드 서비스에 대한 효율적인 배포 파이프라인 구현에 어려움을 겪을 수 있습니다. App Service는 자동 배포와 수동 배포를 모두 지원합니다.
자동화된 배포
자동화된 배포 또는 연속 배포는 최종 사용자에게 최소한의 영향을 주면서 빠르고 반복적인 패턴으로 새 기능 및 버그 수정을 푸시하는 데 사용되는 프로세스입니다.
Azure는 여러 원본에서 직접 자동화 배포를 지원합니다. 다음 옵션을 사용할 수 있습니다.
- Azure DevOps Services: 코드를 Azure DevOps Services에 푸시하고, 클라우드에서 코드를 빌드하고, 테스트를 실행하고, 코드에서 릴리스를 생성하고, 마지막으로 코드를 Azure 웹앱에 푸시할 수 있습니다.
- GitHub: Azure는 GitHub에서 직접 자동화 배포를 지원합니다. 자동화된 배포를 위해 GitHub 리포지토리를 Azure에 연결하면 GitHub의 프로덕션 분기에 푸시하는 모든 변경 내용이 자동으로 배포됩니다.
- Bitbucket: GitHub와 유사하므로 Bitbucket을 사용하여 자동화 배포를 구성할 수 있습니다.
수동 배포
코드를 Azure에 수동으로 푸시하는 데 사용할 수 있는 몇 가지 옵션이 있습니다.
- Git: App Service 웹앱은 원격 리포지토리로 추가할 수 있는 Git URL 기능을 제공합니다. 원격 리포지토리에 푸시하면 앱이 배포됩니다.
- CLI:
webapp up은 앱을 패키지하고 배포하는az명령줄 인터페이스의 기능입니다. 다른 배포 방법과 달리az webapp up에서는 App Service 웹앱이 아직 만들어지지 않은 경우 새 웹앱을 자동으로 만들 수 있습니다. - Zip 배포:
curl또는 유사한 HTTP 유틸리티를 사용하여 애플리케이션 파일의 ZIP을 App Service에 보냅니다. - FTP/S: FTP 또는 FTPS는 App Service를 포함한 많은 호스팅 환경에 코드를 푸시하는 기존 방법입니다.
배포 슬롯 사용
가능하면 새 프로덕션 빌드를 배포할 때 배포 슬롯을 사용합니다. 표준 App Service 플랜 계층 이상을 사용하는 경우 스테이징 환경에 앱을 배포한 다음 스테이징 슬롯과 프로덕션 슬롯을 교환할 수 있습니다. 교환 작업을 수행하면 프로덕션 규모와 일치하도록 하는 데 필요한 작업자 인스턴스가 발생하므로 가동 중지 시간을 없앨 수 있습니다.
지속적으로 코드 배포
프로젝트에 테스트, QA 및 스테이징에 대한 분기가 지정된 경우 각 분기는 스테이징 슬롯에 지속적으로 배포되어야 합니다. 이를 통해 관련자는 배포된 분기를 쉽게 평가하고 테스트할 수 있습니다.
지속적으로 컨테이너 배포
Azure Container Registry 또는 기타 Container Registry의 사용자 지정 컨테이너의 경우 이미지를 스테이징 슬롯에 배포하고 프로덕션으로 전환하여 가동 중지 시간을 방지합니다. 컨테이너 레지스트리에 이미지를 푸시하고 웹앱에서 이미지 태그를 업데이트해야 하기 때문에 자동화는 코드 배포보다 더 복잡합니다.
- 이미지 빌드 및 태그 지정: 빌드 파이프라인의 일부로 git 커밋 ID, 타임스탬프 또는 기타 식별 가능한 정보로 이미지에 태그를 지정합니다. 기본값인 "최신" 태그를 사용하지 않는 것이 좋습니다. 그러지 않으면 현재 배포된 코드를 추적하기가 까다롭기 때문에 디버깅이 훨씬 더 어려워집니다.
- 태그된 이미지 푸시: 이미지가 빌드되고 태그가 지정되면 파이프라인은 이미지를 컨테이너 레지스트리에 푸시합니다. 다음 단계에서 배포 슬롯은 컨테이너 레지스트리에서 태그가 지정된 이미지를 가져옵니다.
- 새 이미지 태그로 배포 슬롯 업데이트: 이 속성이 업데이트되면 사이트가 자동으로 다시 시작되고 새 컨테이너 이미지를 끌어옵니다.