연속 통합 및 배포

8분

지속적인 통합은 코드 베이스에 자동으로 이루어진 변경 내용을 각각 가능한 빨리 테스트하는 방법입니다. 지속적인 업데이트는 지속적인 통합 중에 발생하는 테스트를 수행하고, 변경 내용을 준비 또는 프로덕션 시스템에 푸시합니다.

Azure Data Factory에서 CI/CD(지속적인 통합 및 지속적인 업데이트)는 환경(개발, 테스트, 프로덕션) 간에 Data Factory 파이프라인을 이동하는 것입니다. Azure Data Factory는 Azure Resource Manager 템플릿을 활용하여 다양한 Azure Data Factory 엔터티(파이프라인, 데이터 세트, 데이터 흐름 등)의 구성을 저장합니다. Data Factory를 다른 환경으로 승격시키는 두 가지 제안된 방법이 있습니다.

Data Factory와 Azure Pipelines의 통합을 사용하여 배포를 자동화합니다.
Azure Resource Manager와 Data Factory UX의 통합을 사용하여 Resource Manager 템플릿을 수동으로 업로드합니다.

연속 통합/지속적인 업데이트 수명 주기

다음은 Azure Repos Git로 구성된 Azure Data Factory의 CI/CD 수명 주기에 대한 샘플 개요입니다.

Azure Repos Git를 사용하여 개발 Data Factory를 만들어 구성합니다. 모든 개발자는 파이프라인 및 데이터 세트와 같은 Data Factory 리소스를 작성할 수 있는 권한이 있어야 합니다.
개발자는 기능 분기를 만들어 변경합니다. 가장 최근 변경 내용으로 파이프라인 실행을 디버그합니다.
개발자가 해당 변경 내용을 충족하면 해당 기능 분기에서 마스터 또는 협업 분기로 끌어오기 요청을 만들어서 피어에서 해당 변경 내용을 검토할 수 있습니다.
끌어오기 요청을 승인하고 변경 내용을 마스터 분기에서 병합한 후에 변경 내용이 개발 팩터리에 게시됩니다.
팀이 테스트 또는 UAT(사용자 승인 테스트) 팩터리에 대한 변경 내용을 배포할 준비가 되면 팀은 Azure Pipelines 릴리스로 이동하여 원하는 버전의 개발 팩터리를 UAT에 배포합니다. 이 배포는 Azure Pipelines 작업의 일부로 발생하고 Resource Manager 템플릿 매개 변수를 사용하여 적절한 구성을 적용합니다.
테스트 팩터리에서 변경 내용을 확인한 후 파이프라인 릴리스의 다음 작업을 사용하여 프로덕션 팩터리에 배포합니다.

참고

개발 팩터리만이 Git 리포지토리에 연결됩니다. 테스트 및 프로덕션 팩터리는 Git 리포지토리가 연결되어 있지 않아야 하며 Azure DevOps 파이프라인 또는 리소스 관리 템플릿을 통해서 업데이트해야 합니다.

아래 이미지에는 이 수명 주기의 여러 단계가 강조 표시되어 있습니다.

Diagram of continuous integration with Azure Pipelines

Azure Pipelines 릴리스를 사용하여 지속적인 통합 자동화

다음은 여러 환경에 Data Factory를 자동 배포하는 Azure Pipelines 릴리스를 설정하기 위한 가이드입니다.

요구 사항

Azure Resource Manager 서비스 엔드포인트를 사용하는 Azure Repos 또는 Visual Studio Team Foundation Server에 연결된 Azure 구독
Azure Repos Git 통합으로 구성된 Data Factory
각 환경에 대한 비밀이 포함된 Azure Key Vault

Azure Pipelines 릴리스 설정

Azure DevOps에서 Data Factory로 구성된 프로젝트를 엽니다.
페이지의 왼쪽에서 파이프라인을 선택한 다음 릴리스를 선택합니다.
새 파이프라인을 선택하거나, 기존 파이프라인이 있는 경우에는 새로 만들기를 선택한 다음 새 릴리스 파이프라인을 선택합니다.
빈 작업 템플릿을 선택합니다.
단계 이름 상자에 사용자 환경의 이름을 입력합니다.
아티팩트 추가를 선택한 다음 개발 Data Factory로 구성된 Git 리포지토리를 선택합니다. 기본 분기에 대한 리포지토리의 게시 분기를 선택합니다. 기본적으로 이 게시 분기는 adf_publish입니다. 기본 버전의 경우 기본 분기에서 최신 버전을 선택합니다.
Azure Resource Manager 배포 작업을 추가합니다.

a. 단계 보기에서 단계 작업 보기를 선택합니다.

b. 새 작업을 만듭니다. ARM 템플릿 배포를 검색한 후 추가를 선택합니다.

다. 배포 작업에서 대상 Data Factory에 대한 구독, 리소스 그룹 및 위치를 선택합니다. 필요한 경우 자격 증명을 제공합니다.

d. 작업 목록에서 리소스 그룹 만들기 또는 업데이트를 선택합니다.

e. 템플릿 상자 옆에 있는 줄임표 단추( ... )를 선택합니다. 구성된 Git 리포지토리의 게시 분기에 생성된 Azure Resource Manager 템플릿을 찾습니다. adf_publish 분기의 <FactoryName> 폴더에서 ARMTemplateForFactory.json 파일을 찾습니다.

f. 템플릿 매개 변수 상자 옆에 있는 ...를 선택하여 매개 변수 파일을 선택합니다. adf_publish 분기의 <FactoryName> 폴더에서 ARMTemplateParametersForFactory.json 파일을 찾습니다.

g. 템플릿 매개 변수 재정의 상자 옆에 있는 ...를 선택하고 대상 데이터 팩터리에 대해 원하는 매개 변수 값을 입력합니다. Azure Key Vault에서 제공하는 자격 증명의 경우 큰따옴표 사이에 비밀 이름을 입력합니다. 예를 들어 비밀 이름이 cred1인 경우 이 값에 대한 "$(cred1)" 을 입력합니다.

h. 배포 모드에 대해 증분을 선택합니다.

경고

전체 배포 모드에서는 리소스 그룹에 있지만 새 Resource Manager 템플릿에 지정되지 않은 리소스가 삭제됩니다.
릴리스 파이프라인을 저장합니다.
릴리스를 트리거하려면 릴리스 만들기를 선택합니다. Azure DevOps에서는 이 작업을 자동화할 수 있습니다.

Important

CI/CD 시나리오에서는 서로 다른 환경에서의 IR(통합 런타임) 형식이 동일해야 합니다. 예를 들어 개발 환경에 자체 호스팅 IR이 있는 경우 테스트 및 프로덕션과 같은 다른 환경에서 동일한 IR이 자체 호스팅 유형이어야 합니다. 마찬가지로 여러 단계에서 통합 런타임을 공유하는 경우 개발, 테스트 및 프로덕션과 같은 모든 환경에서 통합 런타임을 연결된 자체 호스팅으로 구성해야 합니다.

Azure Key Vault에서 비밀을 가져옵니다.

Azure Resource Manager 템플릿에 전달할 비밀이 있는 경우 Azure Pipelines 릴리스에서 Azure Key Vault를 사용하는 것이 좋습니다.

비밀을 처리하는 두 가지 방법이 있습니다.

매개 변수 파일에 비밀을 추가합니다.

게시 분기에 업로드되는 매개 변수 파일의 복사본을 만듭니다. 다음 형식을 사용하여 Key Vault에서 가져오려는 매개 변수의 값을 설정합니다.
```
{
    "parameters": {
        "azureSqlReportingDbPassword": {
            "reference": {
                "keyVault": {
                    "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                },
                "secretName": " < secret - name > "
            }
        }
    }
}
```
이 메서드를 사용하는 경우 키 자격 증명 모음에서 자동으로 암호를 끌어옵니다.

매개 변수 파일은 게시 분기에 포함되어야 합니다.
이전 섹션에 설명된 Azure Resource Manager 배포 작업 전에 Azure Key Vault 작업을 추가합니다.
1. 작업 탭에서 새 작업을 만듭니다. Azure Key Vault를 검색하여 추가합니다.
2. Key Vault 작업에서 키 자격 증명 모음을 생성된 구독을 선택합니다. 필요한 경우 자격 증명을 제공하고 키 자격 증명 모음을 선택합니다.

Azure Pipelines 에이전트에 권한 부여

올바른 권한이 설정되어 있지 않으면 액세스 거부 오류가 발생하여 Azure Key Vault 작업이 실패할 수 있습니다. 릴리스에 대한 로그를 다운로드하고, Azure Pipelines 에이전트에 권한을 부여하는 명령을 포함하는 .ps1 파일을 찾습니다. 명령을 직접 실행할 수 있습니다. 또는 파일에서 보안 주체 ID를 복사하고 Azure Portal에 액세스 정책을 수동으로 추가할 수 있습니다. Get 및 List는 필요한 최소 권한입니다.

활성 트리거 업데이트

활성 트리거를 업데이트하려고 하면 배포에 실패할 수 있습니다. 활성 트리거를 업데이트하려면 수동으로 중단하고 배포 후에 시작해야 합니다. Azure PowerShell 작업을 사용하여 이 작업을 수행할 수 있습니다.

릴리스의 작업 탭에서 Azure PowerShell 작업을 추가합니다. 작업 버전 4.*를 선택합니다.
팩터리가 있는 구독을 선택합니다.

스크립트 형식으로 스크립트 파일 경로를 선택합니다. 이를 위해서는 PowerShell 스크립트를 리포지토리에 저장해야 합니다. 다음 PowerShell 스크립트를 사용하여 트리거를 중지할 수 있습니다.

$triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName

$triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }

Start-AzDataFactoryV2Trigger 함수로 유사한 단계를 완료하여 배포한 후에 트리거를 다시 시작할 수 있습니다.

참고

관련 단계는 Azure Data Factory 팀에서 제공하는 배포 전 및 배포 후 스크립트에 이미 포함되어 있습니다.

각 환경에 Resource Manager 템플릿을 수동으로 승격합니다.

Azure DevOps 또는 다른 릴리스 관리 도구를 사용할 수 없는 경우 ARM 템플릿을 사용하여 데이터 팩터리를 수동으로 승격할 수 있습니다.

ARM 템플릿 목록에서 ARM 템플릿 내보내기를 선택하여 개발 환경에서 Data Factory에 Resource Manager 템플릿을 내보냅니다.
테스트 및 프로덕션 Data Factory에서 ARM 템플릿 가져오기를 선택합니다. 이 작업을 통해 Azure Portal로 이동합니다. 여기서 내보낸 템플릿을 가져올 수 있습니다. 편집기에서 사용자 고유의 템플릿 빌드를 선택하여 Resource Manager 템플릿 편집기를 엽니다.
파일 로드를 선택하고 생성된 Resource Manager 템플릿을 선택합니다. 이는 1단계에서 내보낸 .zip 파일에 있는 arm_template.json 파일입니다.
설정 섹션에서 연결된 서비스 자격 증명과 같은 구성 값을 입력합니다. 완료되면 구매를 선택하여 Resource Manager 템플릿을 배포합니다.

Azure Resource Manager 템플릿 매개 변수 사용자 지정

개발 팩터리에 연결된 Git 리포지토리가 있는 경우 템플릿을 게시하거나 내보내 생성된 Resource Manager 템플릿의 기본 Resource Manager 템플릿 매개 변수를 재정의할 수 있습니다. 다음과 같은 시나리오에서 기본 매개 변수화 템플릿을 재정의할 수 있습니다.

자동화 CI/CD를 사용하고 Resource Manager 배포 중에 일부 속성을 변경하려고 하지만 속성은 기본적으로 매개 변수화되지 않습니다.
팩터리가 너무 커서 허용되는 최대 매개 변수(256)를 초과했기 때문에 기본 Resource Manager 템플릿이 유효하지 않습니다.

기본 매개 변수화 템플릿을 재정의하려면 관리 허브로 이동하여 소스 제어 섹션에서 매개 변수화 템플릿을 선택합니다. 템플릿 편집을 선택하여 매개 변수화 템플릿 코드 편집기를 엽니다.

Manage custom parameters

사용자 지정 매개 변수화 템플릿을 생성하면 Git 분기의 루트 폴더에 arm-template-parameters-definition.json이라는 파일이 생성됩니다. 정확한 파일 이름을 사용해야 합니다.

Custom parameters file

협업 분기에서 게시하는 경우 Data Factory가 이 파일을 읽고 해당 구성을 사용하여 매개 변수화된 속성을 생성합니다. 파일이 없는 경우 기본 템플릿이 사용됩니다.

Resource Manager 템플릿을 내보낼 때 Data Factory는 협업 분기가 아니라 현재 작업 중인 모든 분기에서 이 파일을 읽습니다. 프라이빗 분기에서 파일을 만들거나 편집할 수 있습니다. 여기서 UI의 ARM 템플릿 내보내기를 선택하여 변경 내용을 테스트할 수 있습니다. 그런 다음 협업 분기에 파일을 병합할 수 있습니다.

참고

사용자 지정 매개 변수화 템플릿에서 ARM 템플릿 매개 변수 제한(256)을 변경하지 않습니다. 이를 통해 매개 변수화된 속성의 개수를 선택하고 줄일 수 있습니다.

사용자 지정 매개 변수 구문

다음은 사용자 지정 매개 변수 파일 arm-template-parameters-definition.json을 만들 때 따라야 할 지침입니다. 이 파일은 각 엔터티 형식에 대한 섹션(트리거, 파이프라인, 연결된 서비스, 데이터 세트, 통합 런타임 및 데이터 흐름)으로 구성되어 있습니다.

관련 엔터티 형식 아래에 속성 경로를 입력합니다.
속성 이름을 *로 설정하면 해당 속성 아래(재귀적이 아닌 첫 번째 수준까지만)의 모든 속성을 매개 변수화하려고 함을 나타냅니다. 이 구성에 대한 예외를 제공할 수도 있습니다.
문자열로 속성의 값을 설정하면 속성을 매개 변수화하려고 함을 나타냅니다. <action>:<name>:<stype> 형식을 사용합니다.
- <action>은 다음 문자 중 하나일 수 있습니다.
  - =는 현재 값을 매개 변수의 기본값으로 유지함을 의미합니다.
  - -는 매개 변수의 기본값을 유지하지 않음을 의미합니다.
  - |는 연결 문자열 또는 키와 관련한 Azure Key Vault의 비밀에 대한 특수 사례입니다.
- <name>은 매개 변수의 이름입니다. 비어 있는 경우 속성의 이름을 사용합니다. 값이 - 문자로 시작하는 경우에는 이름이 짧아집니다. 예를 들어 AzureStorage1_properties_typeProperties_connectionString에서 AzureStorage1_connectionString으로 줄어듭니다.
- <stype>은 매개 변수의 형식입니다. <stype>이 비어 있는 경우 기본 형식은 string입니다. 지원되는 값은 string, bool, number, object, securestring입니다.
정의 파일에서 배열을 지정하면 템플릿의 일치하는 속성이 배열임을 나타냅니다. Data Factory는 배열의 Integration Runtime 개체에 지정된 정의를 사용하여 배열에 있는 모든 개체를 반복합니다. 두 번째 개체, 문자열은 각 반복에 대한 매개 변수의 이름으로 사용되는 속성의 이름이 됩니다.
정의는 리소스 인스턴스와 관련될 수 없습니다. 모든 정의는 해당 형식의 모든 리소스에 적용됩니다.
기본적으로 Key Vault 비밀과 같은 모든 보안 문자열과 연결 문자열, 키, 토큰 등의 보안 문자열은 매개 변수화됩니다.

연결된 템플릿

Data Factory에 CI/CD를 설정한 경우 팩터리가 증가함에 따라 Azure Resource Manager 템플릿 한도를 초과할 수 있습니다. 예를 들어 한 한도는 Resource Manager 템플릿의 최대 리소스 수입니다. 팩터리에 대한 전체 Resource Manager 템플릿을 생성하면서 대형 팩터리를 수용하기 위해 Data Factory가 이제 연결된 Resource Manager 템플릿을 생성합니다. 이 기능을 사용하면 전체 팩터리 페이로드가 여러 파일로 분할되므로 한도에 제한되지 않습니다.

Git을 구성한 경우 연결된 템플릿이 생성되어 linkedTemplates라는 새 폴더의 adf_publish 분기에 전체 Resource Manager 템플릿과 함께 저장됩니다. 연결된 Resource Manager 템플릿은 일반적으로 마스터 템플릿과 마스터에 연결된 자식 템플릿 세트로 구성됩니다. 부모 템플릿은 ArmTemplate_master.json, 자식 템플릿은 ArmTemplate_0.json, ArmTemplate_1.json 등의 패턴으로 이름이 지정됩니다.

전체 Resource Manager 템플릿 대신 연결된 템플릿을 사용하려면 ArmTemplateForFactory.json(전체 Resource Manager 템플릿)이 아닌 ArmTemplate_master.json을 가리키도록 CI/CD 작업을 업데이트합니다. 또한 Resource Manager에서는 Azure가 배포하는 동안 액세스할 수 있도록 연결된 템플릿을 스토리지 계정에 업로드해야 합니다.

핫픽스 프로덕션 환경

팩터리를 프로덕션에 배포하고 즉시 해결해야 하는 버그가 있지만 현재의 협업 분기를 배포할 수 없는 경우 핫픽스를 배포해야 할 수 있습니다. 이 접근 방식을 QFE(Quick-Fix Engineering)라고 합니다.

Azure DevOps에서 프로덕션에 배포된 릴리스로 이동합니다. 배포된 마지막 커밋을 찾습니다.
커밋 메시지에서 협업 분기의 커밋 ID를 가져옵니다.
해당 커밋에서 새 핫픽스 분기를 생성합니다.
Azure Data Factory UX로 이동하고 핫픽스 분기로 전환합니다.
Azure Data Factory UX를 사용하여 버그를 수정합니다. 변경 내용을 테스트합니다.
수정 사항을 확인한 후 ARM 템플릿 내보내기를 선택하여 핫픽스 Resource Manager 템플릿을 가져옵니다.
게시 분기에서 이 빌드를 수동으로 확인합니다.
adf_publish 체크 인에 따라 자동으로 트리거되도록 릴리스 파이프라인을 구성한 경우 새 릴리스가 자동으로 시작됩니다. 그렇지 않은 경우 수동으로 릴리스를 큐에 넣습니다.
핫픽스 릴리스를 테스트 및 프로덕션 팩터리에 배포합니다. 이 릴리스에는 이전 프로덕션 페이로드와 5단계에서 생성된 수정 사항이 포함되어 있습니다.
이후 릴리스에 동일한 버그가 포함되지 않도록 핫픽스의 변경 내용을 개발 분기에 추가합니다.

연속 통합/지속적인 업데이트를 위한 모범 사례

Data Factory를 통해 Git 통합을 사용할 때 개발에서 테스트, 프로덕션 순서로 변경 내용을 이동하는 CI/CD 파이프라인이 있는 경우 다음 모범 사례를 적용하는 것이 좋습니다.

Git 통합. Git 통합으로 개발 Data Factory를 구성합니다. 테스트 및 프로덕션에 대한 변경 내용은 CI/CD를 통해 배포되므로 Git 통합이 필요 없습니다.
배포 전 및 배포 후 스크립트. CI/CD의 Resource Manager 배포 단계 전에 트리거를 중지, 다시 시작, 정리를 수행하는 등의 특정 작업을 완료해야 합니다. 배포 작업 전후에 PowerShell 스크립트를 사용하는 것이 좋습니다. 데이터 팩터리 팀은 Azure Data Factory CI/CD 설명서 페이지에서 사용할 수 있는 스크립트를 제공했습니다.
통합 런타임 및 공유. 통합 런타임은 자주 변경되지 않으며 CI/CD의 모든 단계에서 유사합니다. 따라서 Data Factory에서는 CI/CD의 모든 단계에서 동일한 이름 및 유형의 통합 런타임을 사용해야 합니다. 모든 단계에서 통합 런타임을 공유하려면 공유 통합 런타임을 포함하기 위해 3개로 구성된 팩터리를 사용하는 것이 좋습니다. 모든 환경에서 이 공유 팩터리를 연결된 통합 런타임 형식으로 사용할 수 있습니다.
관리형 프라이빗 엔드포인트 배포. 프라이빗 엔드포인트가 팩터리에 이미 있는데 이름은 동일하지만 속성이 수정된 프라이빗 엔드포인트가 포함된 ARM 템플릿을 배포하려고 하는 경우 배포가 실패합니다. 달리 말하면 프라이빗 엔드포인트가 팩터리에 이미 있는 것과 동일한 속성을 보유하는 한 프라이빗 엔드포인트를 성공적으로 배포할 수 있습니다. 속성이 환경 간에 서로 다른 경우 해당 속성을 매개 변수화하고 배포 중에 각각의 값을 제공하여 속성을 재정의할 수 있습니다.
Key Vault. 연결 정보가 Azure Key Vault에 저장되어 있는 연결된 서비스를 사용하는 경우 다른 환경에 대해 별도의 키 자격 증명 모음을 유지하는 것이 좋습니다. 또한 각각의 키 자격 증명 모음에 대해 개별 권한 수준을 구성할 수도 있습니다. 예를 들어 팀 멤버에게 프로덕션 비밀에 대한 사용 권한을 부여하지 않을 수 있습니다. 이 접근 방식을 따를 경우 모든 단계에서 동일한 비밀 이름을 유지하는 것이 좋습니다. 동일한 비밀 이름을 유지하는 경우, 별도의 매개 변수인 키 자격 증명 모음 이름이 유일하게 변경되므로 CI/CD 환경에서 각 연결 문자열을 매개 변수화할 필요가 없습니다.
리소스 이름 지정: ARM 템플릿 제약 조건으로 인해 리소스의 이름에 공백이 포함된 경우 배포 관련 문제가 발생할 수 있습니다. Azure Data Factory 팀은 리소스 이름에 공백 대신 ‘_’ 또는 ‘-’ 문자 사용을 권장합니다. 예를 들어 ‘Pipeline_1’은 ‘Pipeline 1’보다 더 적합한 이름입니다.

계속