Azure Developer CLI를 사용하여 전체 스택 배포

프런트 엔드 및 백 엔드 서비스를 결합하는 전체 스택 애플리케이션은 최신 웹 개발에서 일반적인 패턴입니다. Azure 개발자 CLI(azd)는 프런트 엔드 및 백 엔드가 별도의 서비스로 호스트되는 전체 스택 애플리케이션 배포를 지원합니다. 이 문서에서는 전체 스택 애플리케이션을 사용하여 azd 배포하는 방법을 설명하고 효과적인 배포를 위한 전략 및 이점을 강조 표시합니다.

전체 스택 배포란?

전체 스택 배포 구성은 azd 보통 다음과 같이 구성됩니다.

• 프런트 엔드 서비스: React, Angular, Vue 또는 Blazor와 같은 프레임워크를 사용하여 빌드되는 사용자 연결 웹 애플리케이션입니다. 프런트 엔드는 정적 사이트 또는 컨테이너화된 애플리케이션으로 호스트될 수 있습니다.
• 백 엔드 서비스: 비즈니스 논리, 데이터 액세스 및 통합을 처리하는 API 또는 서비스 계층입니다. 백 엔드는 일반적으로 컨테이너 또는 서버리스 함수로 호스트됩니다.
• 공유 리소스: 데이터베이스, 스토리지 계정, 키 자격 증명 모음 및 두 서비스에서 사용할 수 있는 기타 Azure 리소스.

사용하면 azd두 서비스를 단일 azure.yaml 파일로 정의하고 인프라를 코드(Bicep 또는 Terraform)로 사용하여 함께 프로비전할 수 있습니다.

Azure 개발자 CLI 수명 주기

Azure 개발자 CLI는 고유한 수명 주기 이벤트를 사용하여 구조화된 워크플로를 따릅니다.

1. 패키지: 애플리케이션 소스 코드를 빌드하고 배포를 위한 아티팩트 준비
2. 프로비전: Bicep 또는 Terraform을 사용하여 Azure 인프라 리소스를 만들거나 업데이트합니다.
3. 배포: 프로비전된 인프라에 패키지된 애플리케이션 코드를 배포합니다.

이 azd up 명령은 세 단계를 모두 순차적으로 실행합니다. 각 단계를 독립적으로 실행할 수도 있으며, 보다 세부적인 제어를 위해 azd package, azd provision, 및 azd deploy을 사용할 수 있습니다. 이 수명 주기를 이해하는 것은 특히 타이밍과 순서가 중요한 전체 스택 배포에서 서비스 간의 종속성을 관리하는 데 필수적입니다.

수명 주기 및 워크플로 사용자 지정에 대한 azd 자세한 내용은 azd up 워크플로 탐색을 참조하세요.

인프라 디자인 고려 사항

전체 스택 애플리케이션 azd을 디자인할 때 프런트 엔드 및 백 엔드에 적합한 Azure 호스팅 서비스를 선택합니다.

서비스 유형	호스팅 옵션	사용 사례
프런트 엔드	Azure Static Web Apps, Azure App Service, Azure Container Apps	정적 사이트, SPA, 서버 렌더링 앱
백 엔드	Azure Container Apps, Azure App Service, Azure Functions, Azure Kubernetes Service	API, 마이크로 서비스, 서버리스 함수

Azure에서 애플리케이션을 호스팅하는 방법에 대해 자세히 알아봅니다.

프런트 엔드 및 백 엔드 애플리케이션 간의 상호 종속성 이해

전체 스택 배포는 각 서비스가 완전히 구성되기 전에 서로에 대한 정보가 필요한 순환 종속성 문제가 발생하는 경우가 많습니다. 이러한 상호 종속성을 이해하면 효과적인 배포 워크플로를 디자인하는 데 도움이 됩니다.

프런트 엔드에는 백 엔드 URL이 필요합니다. 프런트 엔드 애플리케이션은 일반적으로 빌드 시간 또는 런타임에 백 엔드 API 엔드포인트 URL을 알고 있어야 합니다. 그러나 백 엔드 서비스에는 Azure에 배포될 때까지 URL이 없습니다.

백 엔드에는 프런트 엔드 URL이 필요합니다. 백 엔드 서비스는 CORS 정책을 구성하기 위해 프런트 엔드 URL이 필요할 수 있지만 프런트 엔드에는 배포될 때까지 URL이 없습니다.

공유 리소스 종속성: 두 서비스 모두 데이터베이스, 키 자격 증명 모음 또는 스토리지 계정과 같은 공유 리소스에 따라 달라질 수 있습니다. 이러한 리소스는 두 서비스를 사용하도록 구성하기 전에 프로비전되어야 합니다.

환경별 구성: 다양한 환경(개발, 스테이징, 프로덕션)에는 다른 엔드포인트 URL 및 구성이 필요하지만 프로비전이 완료될 때까지 이러한 값을 알 수 없습니다.

구성 전략 이해

Azure 개발자 CLI는 다음 두 가지 방법을 통해 이러한 상호 종속성을 처리합니다.

• 배포 시간 구성: 프로비전 및 배포 중 종속성 해결
• 런타임 구성: 애플리케이션 실행 시 종속성 구성 연기

이러한 접근 방식은 애플리케이션을 빌드할 때 내리는 디자인 결정을 나타냅니다. 하나의 전략을 단독으로 사용하거나 아키텍처 및 요구 사항에 따라 둘 다 결합할 수 있습니다.

배포 시간 구성

배포 시 구성은 단계 azd provision와 azd deploy 동안 서비스 연결과 구성이 결정되어 잠기게 된다는 것을 의미합니다. 이 방법을 사용하면 실행을 시작하기 전에 특정 엔드포인트 URL, 연결 문자열 및 기타 종속성 정보를 사용하여 서비스를 구성합니다. 이 구성은 환경 변수 또는 배포로 패키지된 구성 파일에서 배포된 서비스 환경의 일부가 됩니다.

인프라 우선 프로비전: azd up을(를) 실행할 때 또는 azd provision를 실행하면, 인프라를 먼저 만듭니다. 이 단계에서는 배포를 시작하기 전에 필요한 URL 및 연결 문자열을 생성하여 종속 서비스에 필요한 정보가 있는지 확인합니다.

출력 변수: Bicep 및 Terraform은 프로비전 후 URL 및 연결 문자열과 같은 값을 출력할 수 있습니다. 이러한 출력은 배포 단계 중에 환경 변수로 사용할 수 있게 되므로 시작하기 전에 올바른 엔드포인트로 서비스를 구성할 수 있습니다.

순차적 배포: 복잡한 시나리오의 경우 특정 순서로 서비스를 배포해야 할 수 있습니다. azd 사용하여 배포 순서를 제어하여 종속 서비스가 배포되기 전에 필수 구성 요소 서비스가 실행되고 있는지 확인합니다.

컨테이너 업서트 패턴: AVM(Azure Verified Modules)은 '2단계 워크플로'에서 container-app-upsert원활하게 작동하는 것과 같은 azd 컨테이너 앱 패턴을 제공합니다. 프로비전하는 동안 인프라 및 초기 컨테이너가 만들어집니다. 배포 중에 azd는 데이터베이스 연결 문자열이나 서비스 URL 같은 프로비전 중 생성된 값을 포함하도록 업데이트된 환경 변수를 사용하여 컨테이너 이미지를 업서트합니다. 이 패턴은 인프라가 먼저 존재하도록 허용한 다음 필요한 모든 종속성 정보로 컨테이너 구성을 업데이트하여 닭과 달걀 문제를 해결합니다.

컨테이너 API 백 엔드를 사용하는 React 프런트 엔드에 대한 예제 워크플로:

1. azd up은 패키지, 프로비전 및 배포 단계를 순차적으로 실행합니다.
2. 프로비전하는 동안 Bicep은 AVM container-app-upsert 모듈을 사용하여 Azure Container Apps 인프라를 만들고 백 엔드 API URL을 출력합니다.
3. 배포 azd 하는 동안 프런트 엔드에 대한 API URL을 포함하여 올바른 환경 변수를 사용하여 두 컨테이너를 자동으로 업서트합니다.
4. 두 서비스 모두 올바른 구성으로 시작합니다. azd up 또는 azd deploy의 향후 실행은 컨테이너를 새로운 구성 값으로 업데이트합니다.

런타임 구성

런타임 구성을 사용하면 배포하는 동안 대신 애플리케이션이 실행되면 애플리케이션이 구성을 로드할 수 있습니다. 이 방법은 애플리케이션을 다시 배포하지 않고도 서비스 엔드포인트, 연결 문자열 및 정책을 업데이트할 수 있는 유연성을 제공합니다.

구성 원본: 애플리케이션은 다음 두 가지 기본 원본에서 런타임 구성을 로드할 수 있습니다.

• 로컬 구성 파일: 애플리케이션과 함께 구성 파일(예: config.json구성 파일)을 배포합니다. 애플리케이션은 시작 시 이 파일을 로드하여 현재 엔드포인트 URL, 인증 설정 및 기타 구성 값을 가져옵니다. 이 방법은 애플리케이션이 브라우저에서 시작될 때 구성을 가져올 수 있는 React, Angular, Vue 및 Blazor WebAssembly와 같은 클라이언트 쪽 프레임워크에 적합합니다.

• 클라우드 구성 서비스: Azure App Configuration 또는 유사한 서비스를 사용하여 모든 환경에서 구성을 중앙에서 관리합니다. 애플리케이션은 시작 시 또는 요청 시 구성 서비스를 쿼리하여 현재 값을 검색합니다. 이 방법은 여러 서비스에 조정된 구성 업데이트가 필요한 마이크로 서비스 아키텍처에 유용합니다.

이점: 두 방법 중 하나를 사용하면 다시 배포하지 않고 구성 변경 내용을 즉시 사용할 수 있습니다. 배포 파이프라인을 통해 구성 파일을 업데이트하거나 Azure Portal을 통해 Azure App Configuration 의 값을 변경합니다. 애플리케이션이 구성을 다시 시작하거나 새로 고치면 새 값이 선택됩니다. 이 패턴은 다음 경우에 특히 유용합니다.

• 백 엔드 API URL, 인증 엔드포인트 및 마이크로 서비스 위치를 검색해야 하는 프런트 엔드 애플리케이션
• 프런트 엔드 URL이 변경됨에 따라 CORS 정책을 업데이트해야 하는 백 엔드 서비스
• 개발, 스테이징 및 프로덕션 환경에서 서로 다른 구성이 필요한 서비스

백 엔드 API를 검색하는 React 프런트 엔드에 대한 예제 워크플로:

1. 실행 azd up 하여 인프라를 프로비전하고 두 서비스를 모두 배포합니다.
2. 배포 후 후크는 백 엔드 URL이 포함된 파일을 생성 config.json 하고 프런트 엔드의 스토리지 위치에 업로드합니다.
3. React 앱은 시작 시 config.json를 가져와 API 엔드포인트를 발견합니다.
4. 나중에 엔드포인트를 업데이트하려면 프런트 엔드를 다시 배포하지 않고 수정 config.json 합니다.

이 방법은 빌드 시 모든 콘텐츠가 미리 렌더링되는 정적으로 생성된 사이트에서는 작동하지 않습니다.

배포 워크플로 계획

전체 스택 배포를 디자인할 때 다음 요소를 고려합니다.

1. 종속성 식별: 다른 서비스의 정보가 필요한 서비스를 매핑합니다. 단방향 종속성(예: 데이터베이스에 따라 API)의 경우 프로비전 플랫폼(Bicep 또는 Terraform)은 자동으로 순서를 처리합니다. 순환 종속성(예: 시작 시 서로의 URL이 모두 필요한 프런트 엔드 및 백 엔드 서비스)의 경우 배포 시간 또는 런타임 구성 전략을 사용하여 조정을 디자인해야 합니다.
2. 배포 전 프로비전: 애플리케이션 코드를 배포하기 전에 모든 인프라가 있는지 확인합니다.
3. 환경 변수 사용: azd 환경 변수를 사용하여 인프라와 애플리케이션 계층 간에 구성을 전달합니다.
4. 여러 환경에 대한 디자인: 개발, 스테이징 및 프로덕션 환경에서 구성이 어떻게 다른지 계획합니다.
5. 배포 순서 고려: 일부 시나리오에서는 특정 순서로 서비스를 배포해야 할 수 있습니다.

이 azd up 명령은 프로비저닝을 자동으로 실행한 다음 단일 워크플로에서 배포를 실행하여 대부분의 배포 시나리오를 처리합니다. 표준 단일 애플리케이션의 경우 이 방법은 잘 작동하며 최소한의 구성이 필요합니다.

순환 종속성이 있는 전체 스택과 같이 더 복잡한 배포의 경우:

• 서비스 순서 구성: 파일에서 azure.yaml 배포하려는 순서대로 서비스를 정의합니다. 기본적으로 서비스를 병렬로 배포하는 동안 azd후크를 사용하여 필요한 경우 순차적 배포를 적용할 수 있습니다.

• 워크플로 사용자 지정 단계: 파일에서 사용자 지정 azd up 속성을 정의하여 기본 workflows 워크플로를 재정의합니다azure.yaml. 예를 들어 애플리케이션 소스 코드를 빌드하기 전에 프로비저닝을 실행하도록 기본 동작을 변경할 수 있습니다.

  name: todo-nodejs-mongo
  metadata:
    template: todo-nodejs-mongo@0.0.1-beta
  workflows:
    up: 
      steps:
        - azd: provision
        - azd: package
        - azd: deploy
  

  이 패턴은 프로비전이 완료된 후에만 사용할 수 있는 구성 값이 빌드 프로세스에 필요한 경우에 유용합니다.

• 별도의 프로비전 및 배포: azd up을 사용하지 않고, azd provision와 azd deploy을 별도의 명령으로 실행합니다. 이 분리는 애플리케이션 코드를 배포하기 전에 인프라 구성을 확인해야 하거나 배포 문제를 해결할 때 유용합니다. 인프라를 한 번 프로비전한 다음 다시 프로비전하지 않고 애플리케이션 코드를 여러 번 배포하고 다시 배포할 수 있습니다.

• 후크로 사용자 지정: 파일에 후크 사전 및 사후 후크를azure.yaml 추가하여 프로비전 및 배포 단계 간에 사용자 지정 논리를 실행합니다. 후크를 사용하여 구성 파일을 채웁니다. 환경 상태의 유효성을 검사하거나 복잡한 배포 시퀀스를 조정합니다.

모범 사례

전체 스택 애플리케이션을 빌드할 azd때 다음 모범 사례를 따릅니다.

1. 종속성 미리 매핑: 디자인 단계에서 다른 서비스의 정보가 필요한 서비스를 식별합니다. Bicep 또는 Terraform이 자동으로 처리하는 단방향 종속성과 배포 시간 또는 런타임 구성 전략이 필요한 순환 종속성을 구분합니다.
2. 올바른 구성 전략 선택: 배포 시 서비스가 구성을 잠가야 하는 경우 배포 시간 구성을 사용합니다. 다시 배포하지 않고 구성을 업데이트하는 유연성이 필요한 경우 런타임 구성을 사용합니다. 적절한 경우 두 전략을 결합합니다.
3. Azure 확인된 모듈(AVM) 사용: Bicep 모듈인 Azure Verified Modules를 container-app-upsert 같은 컨테이너 앱에서 활용합니다. 이러한 패턴은 azd의 2단계 워크플로와 원활하게 작동하여 순환 종속성을 해결합니다.
4. 필요한 경우 워크플로 사용자 지정: 간단한 배포의 경우 기본 설정과 함께 사용합니다 azd up . 순환 종속성이 있는 복잡한 시나리오의 경우 파일의 workflows 속성을 azure.yaml 사용자 지정하여 패키지, 프로비전 및 배포 단계의 순서를 제어합니다.
5. 런타임 구성 활용: 환경 전반에서 유연성을 극대화하려면 Azure App Configuration 또는 로컬 구성 파일을 사용하여 다시 배포하지 않고 업데이트할 수 있는 서비스 엔드포인트 및 설정을 관리합니다.
6. 환경 간 테스트: 서비스 URL 및 구성이 다른 개발, 스테이징 및 프로덕션 환경에서 구성 전략이 올바르게 작동하는지 확인합니다.

다음 단계

• Azure 개발자 CLI를 사용하여 Azure Container Apps에 배포
• 전체 스택 배포 템플릿
• Azure 개발자 CLI 템플릿 개요
• azd up 워크플로 살펴보기