다음을 통해 공유


환경 만들기 및 대상 지정

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

이 문서에서는 Azure Pipelines 환경을 만들고 대상으로 지정하는 방법을 설명합니다. 환경은 파이프라인의 배포를 사용하여 대상으로 지정할 수 있는 리소스 컬렉션입니다.

환경은 파이프라인이 소프트웨어를 배포하는 논리적 대상을 나타냅니다. 일반적인 환경 이름은 개발, 테스트, QA, 스테이징 및 프로덕션입니다.

참고 항목

Azure DevOps 환경은 클래식 파이프라인에서 사용할 수 없습니다. 클래식 파이프라인의 경우 배포 그룹은 비슷한 기능을 제공합니다.

환경은 다음과 같은 이점을 제공합니다.

  • 배포 기록입니다. 파이프라인 이름 및 실행 세부 정보는 환경 및 해당 리소스에 대한 배포에 대해 기록됩니다. 동일한 환경 또는 리소스를 대상으로 하는 여러 파이프라인의 컨텍스트에서 환경의 배포 기록을 사용하여 변경 원본을 식별할 수 있습니다.

  • 커밋 및 작업 항목의 추적 가능성 환경을 대상으로 하는 파이프라인 실행 내에서 작업을 볼 수 있습니다. 환경에 새로 배포된 커밋 및 작업 항목을수도 있습니다. 추적 기능을 사용하면 코드 변경 커밋 또는 기능/버그 수정 작업 항목이 환경에 도달했는지 여부를 추적할 수 있습니다.

  • 진단 리소스 상태입니다. 애플리케이션이 원하는 상태에서 작동하는지 여부를 확인할 수 있습니다.

  • 보안. 환경을 대상으로 지정할 수 있는 사용자 및 파이프라인을 지정하여 환경을 보호할 수 있습니다.

환경은 리소스 자체가 실제 배포 대상을 나타내는 리소스 그룹입니다. Azure Pipelines 환경은 현재 Kubernetes가상 머신 리소스 유형을 지원합니다.

YAML 파이프라인이 존재하지 않는 환경을 참조하는 경우:

  • 작업을 수행하는 사용자가 알려져 있고 권한을 할당할 수 있는 경우 Azure Pipelines는 자동으로 환경을 만듭니다.

  • Azure Pipelines에 작업을 수행하는 사용자에 대한 정보가 없는 경우(예: 외부 코드 편집기에서 YAML 업데이트) 파이프라인이 실패합니다.

필수 조건

환경을 추가하려면 다음 필수 구성 요소가 필요합니다.

환경 만들기

첫 번째 환경을 만들려면 다음을 수행합니다.

  1. Azure DevOps 조직에 https://dev.azure.com/{yourorganization} 로그인하고 프로젝트를 엽니다.

  2. 파이프라인>환경>만들기 환경을 선택합니다.

    환경을 보여 주는 스크린샷

  3. 환경에 대한 정보를 입력한 다음 만들기를 선택합니다. 나중에 기존 환경에 리소스를 추가할 수 있습니다.

    새 환경을 만드는 스크린샷

빈 환경을 만들고 배포 작업에서 참조하여 환경에 대한 배포 기록을 기록할 수 있습니다.

Azure Pipelines를 사용하여 환경에 배포할 수 있습니다. 자세한 내용은 Azure Pipelines를 사용하여 Azure Kubernetes Service 빌드 및 배포를 참조 하세요.

배포 작업에서 환경 대상 지정

배포 작업은 순차적으로 실행되는 단계의 컬렉션입니다. 다음 예제 YAML 코드 조각과 같이 배포 작업을 사용하여 리소스의 전체 환경 그룹을 대상으로 지정할 수 있습니다. 해당 리소스 이름이 지정되었으므로 파이프라인이 컴퓨터에서 myVM 실행됩니다.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

배포 작업에서 특정 환경 리소스를 대상으로 지정

배포 대상의 범위를 환경 내의 특정 리소스로 지정할 수 있으므로 특정 리소스에 대한 배포 기록을 기록할 수 있습니다. 배포 작업의 단계는 배포 작업이 대상으로 하는 리소스에서 서비스 연결 세부 정보를 자동으로 상속합니다.

다음 예제에서는 해당 값이 kubernetesServiceConnection 입력에서 environment.resource 자동으로 작업으로 전달됩니다.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)

수동 승인 검사 사용

프로덕션 환경에 대한 배포를 제어하기 위해 Azure Pipelines는 환경에 대한 수동 승인 검사를 지원합니다. 승인 검사는 파이프라인의 단계가 리소스를 사용하는 시기를 제어하기 위해 리소스 소유자가 사용할 수 있습니다. 리소스 소유자는 해당 리소스를 사용하는 단계를 시작하기 전에 충족해야 하는 승인 및 검사를 정의할 수 있습니다.

읽기 권한자 역할이 아닌 환경 작성자, 관리자사용자 역할은 승인 및 검사를 관리할 수 있습니다. 환경 소유자는 승인 검사를 사용하여 스테이지를 실행하는 시기를 수동으로 제어할 수 있습니다. 자세한 내용은 승인 및 검사 정의를 참조하세요.

실행 세부 정보에서 환경 보기

파이프라인 실행 세부 정보의 환경 탭에서 파이프라인 실행의 배포 작업의 대상이 된 모든 환경을 볼 수 있습니다.

실행 세부 정보의 환경을 보여 주는 스크린샷.

참고 항목

AKS(Azure Kubernetes Service) 프라이빗 클러스터를 사용하는 경우 환경 탭을 사용할 수 없습니다.

배포 기록 보기

Azure Pipelines 환경 섹션에서 배포 탭을 선택하여 배포 기록을 볼 수 있습니다.

  • 특정 환경을 대상으로 하는 모든 파이프라인에서 작업을 봅니다. 예를 들어 각각 고유한 파이프라인이 있는 두 개의 마이크로 서비스는 동일한 환경에 배포할 수 있습니다. 배포 기록은 환경에 영향을 주는 모든 파이프라인을 식별하는 데 도움이 되며 각 파이프라인별 배포 시퀀스를 시각화하는 데도 도움이 됩니다.

    배포 기록 목록을 보여 주는 스크린샷.

  • 작업 세부 정보를 드릴다운하려면 배포 페이지에서 변경 내용 및 작업 항목 탭을 선택합니다. 탭에는 환경에 배포된 커밋 및 작업 항목 목록이 표시됩니다. 각 목록 항목은 해당 배포의 새 항목을 나타냅니다.

    변경 내용 탭에서 첫 번째 목록에는 해당 지점에 대한 모든 커밋이 포함되며, 다음 목록에는 해당 작업에 대한 변경 내용만 포함됩니다. 여러 커밋이 동일한 작업에 연결된 경우 변경 내용 탭에 여러 결과가 있습니다.

    배포 기록의 커밋 스크린샷.

  • 여러 작업 항목이 동일한 작업에 연결된 경우 작업 항목 탭에 여러 결과가 있습니다.

    배포 기록의 작업 항목 스크린샷.

보안

사용자 권한 및 파이프라인 권한을 설정하여 환경을 보호할 수 있습니다.

사용자 권한

사용자 권한으로 환경을 만들고, 보고, 사용하고, 관리할 수 있는 사용자를 제어할 수 있습니다. 네 가지 역할, 즉 모든 환경의 범위가 있는 작성 자, 읽기 권한자, 사용자관리자가 있습니다.

환경의 사용자 권한 패널을 사용하여 사용자를 추가하려면 권한을 부여하려는 특정 환경으로 이동하여 추가 작업 아이콘을 선택하고 보안을 선택합니다.

보안 페이지의 사용자 권한 패널에서 추가를 선택한 다음 사용자 또는 그룹 및 적절한 역할을 선택합니다.

사용자 권한 패널에서 상속된 권한을 설정하고 사용자 환경에 대한 역할을 재정의할 수도 있습니다.

역할 설명
작성자 환경 허브 보안 옵션에서 사용할 수 있는 전역 역할입니다. 이 역할의 멤버는 프로젝트에서 환경을 만들 수 있습니다. 참가자는 기본적으로 멤버로 추가됩니다. 환경이 아직 없는 경우 YAML 파이프라인을 트리거하는 데 필요합니다.
판독기 이 역할의 멤버는 환경을 볼 수 있습니다.
사용자 이 역할의 멤버는 YAML 파이프라인을 만들거나 편집할 때 환경을 사용할 수 있습니다.
관리자 이 역할의 멤버는 사용 권한을 관리하고, 환경을 만들고, 관리하고, 보고, 사용할 수 있습니다. 특정 환경의 경우 작성자는 기본적으로 Admininistrator로 추가됩니다. 관리자는 모든 파이프라인에 대한 환경에 대한 액세스를 열 수도 있습니다.

Important

환경을 만들 때 작성자만 관리자 역할을 맡습니다.

역할 설명
작성자 환경 허브 보안 옵션에서 사용할 수 있는 전역 역할입니다. 이 역할의 멤버는 프로젝트에서 환경을 만들 수 있습니다. 참가자는 기본적으로 멤버로 추가됩니다. 환경이 아직 없는 경우 YAML 파이프라인을 트리거하는 데 필요합니다.
판독기 이 역할의 멤버는 환경을 볼 수 있습니다.
사용자 이 역할의 멤버는 YAML 파이프라인을 만들거나 편집할 때 환경을 사용할 수 있습니다.
관리자 이 역할의 멤버는 환경을 사용하는 것 외에도 환경에 대한 다른 모든 역할의 멤버 자격을 관리할 수 있습니다. 작성자는 기본적으로 멤버로 추가됩니다.

파이프라인 권한

보안 페이지의 파이프라인 사용 권한 패널을 사용하여 환경에 배포할 수 있도록 모든 또는 선택한 파이프라인에 권한을 부여합니다.

  • 환경 또는 리소스에 대한 열린 액세스를 제거하려면 파이프라인 사용 권한에서 권한 제한을 선택합니다.

  • 사용 권한이 제한되면 특정 파이프라인이 환경 또는 특정 리소스에 배포되도록 허용할 수 있습니다. 허용할 파이프라인 목록에서 선택하고 + 선택합니다.

FAQ

환경을 만들려고 할 때 오류 메시지가 표시되는 이유는 무엇인가요?

액세스가 거부된 메시지가 표시되면 {User}에서 작업을 수행할 수 있는 권한 만들기가 필요합니다. 조직 설정>사용자로 이동하여 관련자 역할이 있는지 확인합니다. 관련자는 리포지토리에 액세스할 수 없으므로 관련자 역할은 환경을 만들 수 없습니다.

액세스 수준을 변경한 다음 환경을 만들 수 있는지 확인합니다. 자세한 내용은 사용자 및 권한 관리 FAQ를 참조하세요.

환경을 찾을 수 없다는 오류가 발생하는 이유는 무엇인가요?

작업 XXXX: 환경 XXXX를 찾을 수 없습니다. 환경이 없거나 사용 권한이 부여되지 않았습니다. 실패할 수 있는 몇 가지 이유가 있습니다.

  • 런타임 매개 변수 는 런타임에만 확장되므로 환경을 만들 때 작동하지 않습니다. 변수를 사용하여 환경을 만들거나 templateContext를 사용하여 템플릿에 속성을 전달할 수 있습니다.

  • Azure Pipelines에는 환경을 만드는 사용자에 대한 정보가 없을 수 있습니다.

    YAML 파이프라인 파일에 없는 환경을 참조하는 경우 Azure Pipelines는 다음과 같은 경우에 환경을 자동으로 만듭니다.

    • Azure Pipelines 웹 환경에서 YAML 파이프라인 만들기 마법사를 사용하고 아직 생성되지 않은 환경을 참조합니다.
    • Azure Pipelines 웹 편집기를 사용하여 YAML 파일을 업데이트하고 환경에 참조를 추가한 후 파이프라인을 저장합니다.

    다음 경우 Azure Pipelines에는 환경을 만드는 사용자에 대한 정보가 없으므로 파이프라인이 실패합니다.

    • 다른 외부 코드 편집기를 사용하여 YAML 파일을 업데이트합니다.
    • 존재하지 않는 환경에 대한 참조를 추가한 다음 수동 또는 연속 통합 파이프라인이 트리거됩니다.

    이전에 Azure Pipelines는 환경의 관리자 역할에 모든 프로젝트 기여자를 추가하여 이러한 사례를 처리했습니다. 그러면 프로젝트의 모든 구성원이 이러한 권한을 변경하고 다른 사용자가 환경에 액세스하지 못하도록 할 수 있습니다. 이 결과를 방지하기 위해 Azure Pipelines는 이제 이러한 작업에 실패합니다.