엔드투엔드 배포 이해

  • 5분

Pipelines는 필요에 맞게 다양한 방법으로 구성할 수 있는 유연한 도구입니다. 본 단원에서는 파이프라인을 사용하여 Azure 인프라 구성을 포함하여 전체 솔루션을 배포하고 다른 배포 작업을 수행하는 방법을 알아봅니다.

파이프라인은 몇 개입니까?

일부 조직에서는 Azure 환경을 관리하는 팀이 환경에서 실행되는 코드를 개발하는 팀과 다릅니다. 이러한 상황에서는 특정 영역을 담당하는 팀이 각각 소유한 여러 파이프라인 생성을 시도하는 경우가 많습니다. 예를 들어 웹 사이트의 Azure 리소스를 배포하는 Bicep 코드를 배포하는 하나의 파이프라인과 웹 사이트 애플리케이션을 배포하는 또 다른 파이프라인을 만들 수 있습니다.

이 방법을 사용하면 파이프라인을 관리하는 방법이 어느 정도 유연해질 수 있지만 모든 것을 동기화 상태로 유지하는 것은 어려울 수 있습니다. 예를 들어 웹 사이트 팀이 빌드하는 기능을 사용하도록 설정하기 위해 Azure App Service 앱에 새 설정이 필요하다고 가정해 보겠습니다. 인프라 배포 파이프라인이 성공적으로 완료될 때까지 애플리케이션 배포 파이프라인을 실행할 수 없습니다. 또한 인프라 파이프라인에서 만든 Azure 리소스의 이름과 같은 데이터를 파이프라인 간에 전송하는 것이 복잡해질 수 있습니다.

대신 구성 요소가 여러 사람 또는 여러 팀에서 관리되더라도 솔루션에 필요한 모든 것을 배포하는 단일 파이프라인을 만드는 것이 좋습니다. Git 및 Azure DevOps와 같은 도구를 사용하여 작업을 조율할 수 있습니다. 새 기능이 추가되면 분기를 사용하여 Bicep 파일에 필요한 변경 내용을 적용할 수 있습니다. 또한 변경 사항을 통합하고 릴리스할 준비가 되면 단일 파이프라인이 솔루션을 빌드하고 배포하는 데 필요한 모든 단계를 수행합니다. 단일 파이프라인은 동기화 상태를 벗어날 가능성을 줄입니다.

팁

솔루션에 대한 코드를 빌드하는 경우 작동 방식을 테스트할 수 있도록 자주 배포해야 할 수 있습니다. 애플리케이션 코드와 함께 인프라를 배포하면 파이프라인이 느리게 실행되고 진행이 중단될 수 있습니다.

이 위치에 있는 경우 개발 환경에 대한 인프라 배포를 사용하지 않도록 설정하는 것이 좋습니다. 이를 위해 경로 필터, 파이프라인 템플릿 및 조건을 사용할 수 있습니다. 그러나 다른 환경에서는 전체 배포 순서를 그대로 유지해야 합니다.

컨트롤 플레인 및 데이터 플레인

많은 Azure 리소스는 액세스를 위해 두 ‘플레인’을 제공합니다. ‘컨트롤 플레인’은 리소스를 배포하고 구성합니다. 데이터 플레인을 사용하면 리소스의 기능에 액세스할 수 있습니다.

Bicep 파일을 만들고 배포할 때 컨트롤 플레인과 상호 작용합니다. Azure에서 컨트롤 플레인은 Azure Resource Manager입니다. Resource Manager를 사용하여 각 리소스의 구성을 정의합니다.

그러나 파이프라인에는 단순히 컨트롤 플레인과 상호 작용하는 것 이상의 작업이 필요한 경우가 많습니다. 예를 들어 다른 작업을 수행해야 할 수 있습니다.

  • 스토리지 계정에 BLOB를 업로드합니다.
  • 데이터베이스 스키마를 수정합니다.
  • 타사 서비스에 대한 API 호출을 수행합니다.
  • 기계 학습 모델의 업데이트를 트리거합니다.
  • Azure App Service 앱에 웹 사이트 배포
  • 가상 머신에 소프트웨어를 배포합니다.
  • 타사 공급자에 DNS(도메인 이름 서버) 항목을 등록합니다.

엔드투엔드 파이프라인을 고려할 때 일반적으로 Azure 리소스를 배포한 다음, 해당 리소스의 데이터 평면에 대해 일련의 작업을 수행해야 합니다. 경우에 따라 컨트롤 플레인을 사용하여 대부분의 배포를 수행하고 소수의 구성만 남아 있으므로 이러한 작업을 배포의 마지막 구간이라고 합니다.

참고

일부 리소스는 컨트롤 플레인과 데이터 플레인 간에 명확한 구분이 없습니다. 여기에는 Azure Data Factory와 Azure API Management가 포함됩니다. 두 서비스 모두 Bicep을 사용하여 완전히 자동화된 배포를 지원하지만 특별한 고려 사항이 필요합니다. 모듈 마지막 부분에 있는 요약 페이지에서 자세한 정보에 대한 링크를 찾을 수 있습니다.

데이터 플레인 작업을 수행하는 방법

리소스의 데이터 평면과 상호 작용하는 배포 파이프라인을 만들 때 다음 세 가지 일반적인 방법 중에서 원하는 방법을 사용할 수 있습니다.

  • Resource Manager 배포 스크립트
  • 파이프라인 스크립트
  • 파이프라인 작업

Resource Manager 배포 스크립트는 Bicep 파일 내에서 정의됩니다. 이러한 스크립트는 Bash 또는 PowerShell 스크립트를 실행하고 Azure CLI 또는 Azure PowerShell cmdlet과 상호 작용할 수 있습니다. 배포 스크립트가 Azure로 인증될 수 있도록 관리 ID를 만들고, Azure는 배포 스크립트를 실행하는 데 필요한 다른 리소스를 자동으로 프로비전하고 관리합니다.

배포 스크립트는 배포 프로세스 내에서 기본 스크립트를 실행해야 하는 경우에 적합합니다. 그러나 파이프라인의 다른 요소에 대한 액세스 권한을 쉽게 제공하지는 않습니다.

배포 파이프라인 내에서 사용자의 자체적인 논리를 실행할 수도 있습니다. Azure Pipelines은 수행해야 하는 일반적인 작업의 풍부한 ‘작업’ 에코시스템을 제공합니다. 요구 사항을 충족하는 작업을 찾을 수 없는 경우 ‘스크립트’를 사용하여 사용자의 자체적인 Bash 또는 PowerShell 코드를 실행할 수 있습니다. 파이프라인 작업 및 스크립트는 파이프라인의 에이전트에서 실행됩니다. 사용 중인 서비스의 데이터 평면에 대한 작업 또는 스크립트를 인증해야 하는 경우가 많으며, 인증하는 방법은 서비스에 따라 다릅니다.

파이프라인 작업 및 스크립트는 유연성과 제어를 제공합니다. 또한 곧 알아볼 파이프라인 아티팩트에 액세스할 수 있습니다. 본 모듈에서는 파이프라인 스크립트 및 작업에 중점을 둡니다. 모듈의 마지막 부분에 있는 요약 페이지에서 Resource Manager 배포 스크립트에 관한 자세한 내용 링크를 확인할 수 있습니다.

출력

파이프라인은 일반적으로 Bicep 파일을 배포하여 Azure 리소스를 만들고 구성합니다. 그런 다음 파이프라인의 다음 부분은 해당 리소스의 데이터 플레인과 상호 작용합니다. 리소스와 상호 작용할 수 있도록 파이프라인 작업 및 단계에는 사용자가 생성한 Azure 리소스에 대한 정보가 필요합니다.

예를 들어 스토리지 계정을 배포하는 Bicep 파일이 있다고 가정해 보겠습니다. 파이프라인에서 스토리지 계정을 배포한 다음, 일부 BLOB를 스토리지 계정의 BLOB 컨테이너에 업로드하려고 합니다. BLOB를 업로드하는 파이프라인 작업은 연결할 스토리지 계정의 이름과 파일을 업로드할 BLOB 컨테이너의 이름을 알고 있어야 합니다.

Bicep 파일이 Azure 리소스의 이름을 결정하도록 하는 것이 좋습니다. 매개 변수, 변수 또는 식을 사용하여 스토리지 계정 및 BLOB 컨테이너의 이름을 만들 수 있습니다. 그러면 Bicep 파일은 각 리소스의 이름을 제공하는 출력을 노출할 수 있습니다. 파이프라인의 이후 단계에서 출력 값을 읽을 수 있습니다. 이렇게 하면 파이프라인 정의가 환경 간에 변경될 수 있는 이름 또는 기타 정보를 하드 코딩할 필요가 없습니다. 또한 정의는 Bicep 파일에 정의된 규칙을 기반으로 할 필요가 없습니다.

Azure Pipelines를 사용하면 ‘파이프라인 변수’를 사용하여 출력 값을 전파할 수 있습니다. 파이프라인 스크립트 내에서 파이프라인 변수의 값을 설정할 수 있습니다. 다음과 같이 Azure Pipelines가 해석 방식을 파악하는 특수한 형식의 로그 출력을 사용합니다.

stages:
- stage: Stage1
  jobs:
  - job: Job1
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

      # Read the variable's value.
      - script:
          echo $(myVariableName)

한 작업에서 변수를 만들지만 동일한 단계의 다른 작업에서 액세스하려는 경우 매핑해야 합니다.

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

파이프라인 단계에서 변수에 액세스하려면 변수를 매핑해야 하지만 다른 구문을 사용합니다.

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

- stage: Stage3
  dependsOn: Stage2
  jobs:
  - job: Job4
    variables: # Map the variable to this stage.
      myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
    - script: |
        echo $(myVariableName)

Bicep 출력 및 파이프라인 변수를 사용하여 Bicep 코드를 배포한 다음, 배포의 일부로 리소스에 대해 다양한 작업을 수행하는 다단계 파이프라인을 만들 수 있습니다.