Azure Function/REST API 검사 호출

아티클
11/09/2024

Azure 함수/REST API 검사를 호출하면 특정 파이프라인 단계가 보호된 리소스에 액세스할 수 있는지 여부를 결정하는 코드를 작성할 수 있습니다. 이러한 검사는 다음 두 가지 모드로 실행할 수 있습니다.

비동기(권장): Azure DevOps가 단계 액세스 결정으로 Azure DevOps로 다시 호출하기 위해 Azure Function/REST API 구현을 기다리는 푸시 모드
동기: Azure DevOps가 주기적으로 Azure Function/REST API를 호출하여 단계 액세스 결정을 내리는 폴링 모드

이 가이드의 나머지 섹션에서는 단순히 Azure Function/REST API 검사를 검사라고 합니다.

검사를 사용하는 권장 방법은 비동기 모드입니다. 이 모드는 검사 논리에 대한 가장 높은 수준의 제어를 제공하고, 시스템이 어떤 상태에 있는지 쉽게 추론하고, 검사 구현에서 Azure Pipelines를 분리하여 최상의 확장성을 제공합니다. 모든 동기 검사는 비동기 검사 모드를 사용하여 구현할 수 있습니다.

비동기 검사

비동기 모드에서 Azure DevOps는 Azure Function/REST API 검사를 호출하고 리소스 액세스 결정으로 콜백을 기다립니다. 대기 기간 동안 Azure DevOps와 검사 구현 간에 열린 HTTP 연결이 없습니다.

이 섹션의 나머지 부분에서는 Azure Function 검사에 대해 설명하지만, 달리 명시되지 않는 한 지침은 REST API 호출 검사에도 적용됩니다.

비동기 검사의 권장 구현

권장되는 비동기 모드에는 다음 두 가지 통신 단계가 있습니다.

수표 페이로드를 전달합니다. Azure Pipelines는 검사 페이로드를 전달하기 위해 Azure Function/REST API 에 대한 HTTP 호출을 수행하고 해당 지점에서 결정을 받지 않습니다 . 함수는 정보 수신을 승인하고 Azure DevOps와의 HTTP 연결을 종료해야 합니다. 확인 구현은 3초 이내에 HTTP 요청을 처리해야 합니다.
콜백을 통해 액세스 결정을 전달합니다. 검사는 비동기적으로 실행되고 파이프라인이 보호된 리소스에 액세스하는 데 필요한 조건을 평가해야 합니다(여러 지점에서 여러 평가를 수행할 수 있음). 최종 결정에 도달하면 Azure Function은 Azure DevOps에 HTTP REST를 호출하여 결정을 전달합니다. 언제든지 Azure DevOps와 검사 구현 간에 단일 열린 HTTP 연결이 있어야 합니다. 이렇게 하면 Azure Function 쪽과 Azure Pipelines 쪽 모두에 리소스가 저장됩니다.

검사가 통과하면 파이프라인에서 보호된 리소스에 대한 액세스를 허용하고 단계 배포를 진행할 수 있습니다. 확인이 실패하면 스테이지가 실패합니다. 단일 단계에서 여러 검사가 있는 경우 보호된 리소스에 대한 액세스가 허용되기 전에 모두 통과해야 하지만 단일 실패만으로 스테이지에 실패할 수 있습니다.

단일 Azure Function 검사에 대한 비동기 모드의 권장 구현은 다음 다이어그램에 설명되어 있습니다.

단일 Azure Function 검사에 대한 비동기 모드의 권장 구현을 보여 주는 다이어그램

다이어그램의 단계는 다음과 같습니다.

배달을 확인합니다. Azure Pipelines는 파이프라인 단계를 배포할 준비를 하고 보호된 리소스에 액세스해야 합니다. HTTP 200 상태 코드로 끝나는 호출에 의해 해당 Azure Function 검사를 호출하고 수신 확인을 예상합니다. 결정 보류 중인 단계 배포가 일시 중지됩니다.
평가를 확인합니다. 이 단계는 사용자 고유의 Azure 리소스에서 실행되고 코드가 완전히 제어되는 Azure Function 구현 내에서 수행됩니다. Azure Function은 다음 단계를 수행하는 것이 좋습니다.
- 2.1 비동기 작업 시작 및 HTTP 상태 코드 반환200
- 2.2 여러 조건 평가를 수행할 수 있는 내부 루프를 입력합니다.
- 2.3 액세스 조건 평가
- 2.4 최종 결정에 도달할 수 없는 경우 이후 시점의 조건 재평가를 다시 예약한 다음 2.3단계로 이동합니다.
의사 결정 통신. Azure 함수는 액세스 결정을 통해 Azure Pipelines로 다시 호출합니다. 단계 배포를 진행할 수 있습니다.

권장 구현을 사용하는 경우 파이프라인 실행 세부 정보 페이지에 최신 확인 로그가 표시됩니다.

확인 정보가 포함된 파이프라인 실행 세부 정보의 스크린샷.

비동기 검사에 권장되는 구성

Azure Function/REST API 검사 구성 패널에서 다음을 확인합니다.

완료 이벤트에 대해 선택한 콜백
평가 간격(분)을 0으로 설정

평가 사이의 시간을 0이 아닌 값으로 설정하면 확인 결정(통과/실패)이 최종 결정이 아님을 의미합니다. 다른 모든 승인 및 검사가 최종 상태에 도달할 때까지 검사가 다시 평가됩니다.

파이프라인 실행 정보를 검사에 전달

검사를 구성할 때 검사에 보내려는 파이프라인 실행 정보를 지정할 수 있습니다. 최소한 다음을 보내야 합니다.

"PlanUrl": "$(system.CollectionUri)"
"ProjectId": "$(system.TeamProjectId)"
"HubName": "$(system.HostType)"
"PlanId": "$(system.PlanId)"
"JobId": "$(system.JobId)"
"TaskInstanceId": "$(system.TaskInstanceId)"
"AuthToken": "$(system.AccessToken)"

이러한 키-값 쌍은 기본적으로 Azure Pipelines에서 Headers 수행한 REST 호출에서 설정됩니다.

확인이 결정으로 다시 호출되는 경우와 같이 Azure DevOps를 호출하는 데 사용해야 AuthToken 합니다.

Azure DevOps 호출

결정에 도달하려면 검사에 전달할 수 없는 현재 파이프라인 실행에 대한 정보가 필요할 수 있으므로 검사를 검색해야 합니다. 파이프라인 실행이 특정 작업(예: 정적 분석 작업)을 실행했는지 확인한다고 상상해 보세요. 검사는 Azure DevOps를 호출하고 이미 실행된 작업 목록을 가져와야 합니다.

Azure DevOps를 호출하려면 PAT(개인 액세스 토큰) 대신 검사 실행에 대해 발급된 작업 액세스 토큰을 사용하는 것이 좋습니다. 토큰은 기본적으로 헤더에서 검사에 AuthToken 이미 제공됩니다.

PAT에 비해 작업 액세스 토큰은 제한되는 경향이 적고, 수동 새로 고침이 필요하지 않으며, 개인 계정 연결되지 않습니다. 토큰은 48시간 동안 유효합니다.

작업 액세스 토큰을 사용하면 Azure DevOps REST API 제한 문제를 제외한 모든 항목이 제거됩니다. PAT를 사용하는 경우 파이프라인의 모든 실행에 동일한 PAT를 사용합니다. 많은 수의 파이프라인을 실행하면 PAT가 제한됩니다. 이는 각 검사 실행에 대해 새 토큰이 생성되기 때문에 작업 액세스 토큰과 관련된 문제가 적습니다.

파이프라인을 실행하는 데 사용되는 빌드 ID(예: FabrikamFiberChat 빌드 서비스)에 대해 토큰이 발급됩니다. 즉, 토큰을 사용하여 호스트 파이프라인이 수행할 수 있는 동일한 리포지토리 또는 파이프라인 실행에 액세스할 수 있습니다. YAML 파이프라인의 리포지토리에 대한 액세스 보호를 사용하도록 설정한 경우 해당 범위는 파이프라인 실행에서 참조되는 리포지토리로만 제한됩니다.

검사에서 비 파이프라인 관련 리소스(예: Boards 사용자 스토리)에 액세스해야 하는 경우 파이프라인의 빌드 ID에 이러한 권한을 부여해야 합니다. 여러 프로젝트에서 검사를 트리거할 수 있는 경우 모든 프로젝트의 모든 파이프라인이 필요한 리소스에 액세스할 수 있는지 확인합니다.

Azure DevOps에 의사 결정 보내기

검사 구현은 이벤트 후 REST API 호출을 사용하여 결정을 Azure Pipelines에 다시 전달해야 합니다. 다음 속성을 지정해야 합니다.

Headers: Bearer {AuthToken}
Body:

{
    "name": "TaskCompleted",
    "taskId": "{TaskInstanceId}",
    "jobId": "{JobId}",
    "result": "succeeded|failed"
}

검사에서 Azure DevOps에 상태 업데이트 보내기

Azure Pipelines REST API를 사용하여 검사 내에서 Azure Pipelines 사용자에게 상태 업데이트를 제공할 수 있습니다. 이 기능은 예를 들어 다른 사용자가 ServiceNow 티켓을 승인해야 하는 등의 외부 작업에서 확인이 대기 중임을 사용자에게 알리려는 경우에 유용합니다.

상태 업데이트를 보내는 단계는 다음과 같습니다.

모든 REST API 호출을 인증해야 합니다.

예제

기본 Azure 함수 검사

이 기본 예제에서 Azure Function은 호출 파이프라인 실행이 보호된 리소스에 대한 액세스 권한을 부여하기 전에 작업을 실행했는지 CmdLine 확인합니다.

Azure Function은 다음 단계를 수행합니다.

수표 페이로드 수신 확인
검사가 시작된 Azure Pipelines에 상태 업데이트를 보냅니다.
Azure Pipelines로 콜백하여 파이프라인 실행의 타임라인 항목을 검색하는 데 사용됩니다{AuthToken}.
타임라인에 작업 ID CmdLine 가 포함된 작업이 "id": "D9BAFED4-0B18-4F58-968D-86655B4D2CE9" 포함되어 있는지 확인합니다.
검색 결과와 함께 상태 업데이트를 보냅니다.
Azure Pipelines에 확인 결정 보내기

GitHub에서 이 예제를 다운로드할 수 있습니다.

이 Azure Function 검사를 사용하려면 검사를 구성할 때 다음 Headers 을 지정해야 합니다.

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

고급 Azure 함수 검사

이 고급 예제에서 Azure Function은 파이프라인 실행을 트리거한 커밋 메시지 참조된 Azure Boards 작업 항목이 올바른 상태인지 확인합니다.

Azure Function은 다음 단계를 수행합니다.

수표 페이로드 수신 확인
검사가 시작된 Azure Pipelines에 상태 업데이트를 보냅니다.
{AuthToken} Azure Pipelines에 대한 콜백을 사용하여 파이프라인 실행을 트리거한 커밋 메시지 참조되는 Azure Boards 작업 항목의 상태를 검색합니다.
작업 항목이 상태에 있는지 확인합니다.Completed
확인 결과와 함께 상태 업데이트를 보냅니다.
작업 항목이 상태가 아닌 Completed 경우 1분 안에 다른 평가 일정을 다시 예약합니다.
작업 항목이 올바른 상태이면 Azure Pipelines에 긍정적인 결정을 보냅니다.

GitHub에서 이 예제를 다운로드할 수 있습니다.

이 Azure Function 검사를 사용하려면 검사를 구성할 때 다음 Headers 을 지정해야 합니다.

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

오류 처리

현재 Azure Pipelines는 단일 검사 인스턴스를 최대 2,000회 평가합니다.

구성된 시간 제한 내에 Azure Pipelines를 다시 호출하지 않으면 연결된 단계를 건너뜁니다. 스테이지에 따라 단계도 건너뜁습니다.

동기 검사

동기 모드에서 Azure DevOps는 Azure Function/REST API 검사를 호출하여 보호된 리소스에 대한 액세스가 허용되는지 여부를 즉시 결정합니다.

단일 Azure Function 검사에 대한 동기화 모드 구현은 다음 다이어그램에 설명되어 있습니다.

단일 Azure Function 검사에 대한 동기화 모드 구현을 보여 주는 다이어그램

수행하는 단계는 다음과 같습니다.

Azure Pipelines는 파이프라인 단계 배포를 준비하고 보호된 리소스에 대한 액세스가 필요합니다.
다음과 같은 내부 루프를 입력합니다.

2.1. Azure Pipelines는 해당 Azure Function 검사를 호출하고 결정을 기다립니다.
2.2. Azure Function은 액세스를 허용하는 데 필요한 조건을 평가하고 결정을 반환합니다.
2.3. Azure Function 응답 본문이 정의한 성공 조건을 충족하지 못하고 평가 사이의 시간이 0이 아닌 경우 Azure Pipelines는 평가 사이의 시간 후에 다른 검사 평가 일정을 다시 예약합니다.

동기 검사 구성

Azure Function/REST API에 대한 동기 모드를 사용하려면 확인 구성 패널에서 다음을 확인합니다.

고급에서 완료 이벤트에 대해 선택한 ApiResponse
확인의 응답 본문에 따라 검사를 전달할 시기를 정의하는 성공 조건을 지정했습니다.
제어 옵션에서 평가 사이의 시간을 0으로 설정
수표가 성공할 때까지 기다리는 시간으로 제한 시간을 설정합니다. 긍정적인 결정이 없고 시간 제한 에 도달하면 해당 파이프라인 단계를 건너뜁

평가 간격 설정은 검사의 결정이 유효한 기간을 정의합니다. 값이 0이면 최종 결정이 내려집니다. 0이 아닌 값은 의사 결정이 음수일 때 구성된 간격 후에 검사가 다시 시도됨을 의미합니다. 여러 승인 및 검사가 실행 중인 경우 확인은 결정에 관계없이 다시 시도됩니다.

최대 평가 수는 평가 값 사이의 시간 제한과 시간 사이의 비율로 정의됩니다. 이 비율이 최대 10인지 확인하는 것이 좋습니다.

파이프라인 실행 정보를 검사에 전달

검사를 구성할 때 Azure Function/REST API 검사로 보내려는 파이프라인 실행 정보를 지정할 수 있습니다. 기본적으로 Azure Pipeline은 다음 정보를 Headers HTTP 호출에 추가합니다.

"PlanUrl": "$(system.CollectionUri)"
"ProjectId": "$(system.TeamProjectId)"
"HubName": "$(system.HostType)"
"PlanId": "$(system.PlanId)"
"JobId": "$(system.JobId)"
"TaskInstanceId": "$(system.TaskInstanceId)"
"AuthToken": "$(system.AccessToken)"

수표가 회신하는 데 3초 이상 걸릴 가능성이 높기 때문에 동기 모드에서 Azure DevOps를 호출하지 않는 것이 좋습니다. 따라서 확인이 실패합니다.

오류 처리

현재 Azure Pipelines는 단일 검사 인스턴스를 최대 2,000회 평가합니다.

비동기 및 동기 검사를 사용하는 경우

몇 가지 예제 사용 사례 및 사용할 권장 검사 유형을 살펴보겠습니다.

외부 정보는 정확해야 합니다.

프로덕션 리소스에 대한 서비스 연결이 있고 ServiceNow 티켓의 정보가 올바른 경우에만 액세스가 허용되도록 하려는 경우를 가정합니다. 이 경우 흐름은 다음과 같습니다.

ServiceNow 티켓의 정확성을 확인하는 비동 기 Azure Function 검사를 추가합니다.
서비스 연결을 사용하려는 파이프라인이 실행되는 경우:
- Azure Pipelines에서 check 함수를 호출합니다.
- 정보가 올바르지 않으면 검사에서 부정적인 결정을 반환합니다. 이 결과를 가정합니다.
- 파이프라인 단계가 실패함
- ServiceNow 티켓의 정보를 업데이트합니다.
- 실패한 단계를 다시 시작합니다.
- 검사가 다시 실행되고 이번에는 성공합니다.
- 파이프라인 실행이 계속됩니다.

외부 승인을 받아야 합니다.

프로덕션 리소스에 대한 서비스 연결이 있고 관리자가 ServiceNow 티켓을 승인한 후에만 액세스가 허용되도록 하려는 경우를 가정합니다. 이 경우 흐름은 다음과 같습니다.

ServiceNow 티켓이 승인되었는지 확인하는 비동 기 Azure Function 검사를 추가합니다.
서비스 연결을 사용하려는 파이프라인이 실행되는 경우:
- Azure Pipelines는 check 함수를 호출합니다.
- ServiceNow 티켓이 승인되지 않은 경우 Azure Function은 Azure Pipelines에 업데이트를 보내고 15분 안에 티켓 상태를 확인하도록 자체 일정을 조정합니다.
- 티켓이 승인되면 확인은 긍정적인 결정으로 Azure Pipelines로 다시 호출됩니다.
- 파이프라인 실행이 계속됩니다.

개발 프로세스가 수행되었습니다.

프로덕션 리소스에 대한 서비스 연결이 있고 코드 범위가 80%를 초과하는 경우에만 해당 리소스에 대한 액세스가 허용되도록 하려는 경우를 가정해 보겠습니다. 이 경우 흐름은 다음과 같습니다.

스테이징 실패로 인해 빌드가 실패하는 방식으로 파이프라인을 작성합니다.
연결된 파이프라인 실행에 대한 코드 검사를 확인하는 비동기 Azure Function 검사를 추가합니다.
서비스 연결을 사용하려는 파이프라인이 실행되는 경우:
- Azure Pipelines에서 check 함수를 호출합니다.
- 코드 검사 조건이 충족되지 않으면 검사는 부정적인 결정을 반환합니다. 이 결과를 가정합니다.
- 확인 실패로 인해 스테이지가 실패하여 파이프라인 실행이 실패합니다.
엔지니어링 팀은 80% 코드 검사에 도달하는 데 필요한 단위 테스트를 추가합니다.
새 파이프라인 실행이 트리거되고 이번에는 검사가 통과합니다.
- 파이프라인 실행이 계속됩니다.

성능 조건을 충족해야 합니다.

카나리아 배포부터 시작하여 여러 단계로 새 버전의 시스템을 배포한다고 가정해 보겠습니다. 카나리아 배포의 성능이 적절한지 확인하려고 합니다. 이 경우 흐름은 다음과 같습니다.

비동기 Azure Function 검사를 추가합니다.
서비스 연결을 사용하려는 파이프라인이 실행되는 경우:
- Azure Pipelines에서 check 함수를 호출합니다.
- 이 검사는 카나리아 배포의 성능 모니터를 시작합니다.
- 검사는 성능이 어떻게 발전했는지 확인하기 위해 여러 평가 검사점을 예약합니다.
- 카나리아 배포의 성능에 대한 충분한 신뢰도가 확보되면 Azure Function은 긍정적인 결정으로 Azure Pipelines를 다시 호출합니다.
- 파이프라인 실행이 계속됩니다.

배포 이유가 유효해야 합니다.

프로덕션 환경 리소스에 대한 서비스 연결이 있고 수동으로 큐에 대기 중인 빌드에 대해서만 액세스가 수행되도록 하려는 경우를 가정합니다. 이 경우 흐름은 다음과 같습니다.

파이프라인 실행에 대해 다음과 같은지 확인하는 동기 Azure Function 검사를 추가합니다 Build.Reason . Manual
Azure Function 검사를 전달 Build.Reason 하도록 구성합니다. Headers
평가 사이의 확인 시간을 0으로 설정하면 실패 또는 통과가 최종이며 다시 평가가 필요하지 않습니다.
서비스 연결을 사용하려는 파이프라인이 실행되는 경우:
- Azure Pipelines에서 check 함수를 호출합니다.
- 이유가 아닌 Manual경우 검사가 실패하고 파이프라인 실행이 실패합니다.

준수 확인

이제 Azure Function 및 REST API 검사를 호출하는 데 권장 사용량과 일치하는 규칙이 포함됩니다. 검사는 모드 및 재시도 횟수에 따라 다음 규칙을 따라야 합니다.

비동기 검사(콜백 모드): Azure Pipelines는 비동기 검사를 다시 시도하지 않습니다. 평가가 최종적인 경우 결과를 비동기적으로 제공해야 합니다. 비동기 검사를 규격으로 간주하려면 평가 사이의 시간 간격이 0이어야 합니다.
동기 검사(ApiResponse 모드): 검사에 대한 최대 재시도 횟수는 10입니다. 여러 가지 방법으로 설정할 수 있습니다. 예를 들어 시간 제한을 20으로, 평가 간격을 2로 구성할 수 있습니다. 또는 평가 사이의 시간 간격을 100으로, 시간 간격을 10으로 구성할 수 있습니다. 그러나 시간 제한을 100으로 구성하고 평가 사이의 시간 간격을 2로 설정하면 50번의 재시도 요청으로 인해 수표가 준수되지 않습니다. 평가 간의 시간 제한 간격 비율은 10보다 작거나 같아야 합니다.

검사 규정 준수의 출시에 대해 자세히 알아봅니다.

여러 검사

Azure Pipelines가 파이프라인 실행의 단계를 배포하기 전에 여러 검사를 통과해야 할 수 있습니다. 보호된 리소스에는 하나 이상의 검사가 연결되어 있을 수 있습니다. 단계에서는 여러 개의 보호된 리소스를 사용할 수 있습니다. Azure Pipelines는 단계에서 사용되는 각 보호된 리소스에 연결된 모든 검사를 수집하고 동시에 평가합니다.

파이프라인 실행은 모든 검사가 동시에 통과하는 경우에만 스테이지에 배포할 수 있습니다. 단일 최종 부정 결정으로 인해 파이프라인에 대한 액세스가 거부되고 스테이지가 실패합니다.

권장되는 방식(비동기, 최종 상태)으로 검사를 사용하면 액세스 결정을 최종 결정하게 되며 시스템 상태를 쉽게 이해할 수 있습니다.

예제는 여러 승인 및 검사 섹션을 확인하세요.

다음을 통해 공유

Azure Function/REST API 검사 호출

비동기 검사

비동기 검사의 권장 구현

비동기 검사에 권장되는 구성

파이프라인 실행 정보를 검사에 전달

Azure DevOps 호출

Azure DevOps에 의사 결정 보내기

검사에서 Azure DevOps에 상태 업데이트 보내기

예제

기본 Azure 함수 검사

고급 Azure 함수 검사

오류 처리

동기 검사

동기 검사 구성

파이프라인 실행 정보를 검사에 전달

오류 처리

비동기 및 동기 검사를 사용하는 경우

외부 정보는 정확해야 합니다.

외부 승인을 받아야 합니다.

개발 프로세스가 수행되었습니다.

성능 조건을 충족해야 합니다.

배포 이유가 유효해야 합니다.

준수 확인

여러 검사

자세한 정보

피드백

추가 리소스