자습서: Azure SRE 에이전트에서 HTTP 트리거 만들기

이 자습서에서는 컨테이너 앱에서 준수 검사를 실행하는 HTTP 트리거를 만듭니다. 포털 및 명령줄에서 테스트한 다음 CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인에 통합합니다.

예상 시간: 10분

이 자습서에서는 다음을 수행합니다.

준수 확인 프롬프트를 사용하여 HTTP 트리거를 만듭니다.
지금 실행을 사용하여 포털에서 트리거를 테스트합니다.
JSON 페이로드를 사용하여 명령줄에서 트리거를 호출합니다.
트리거를 CI/CD 파이프라인에 통합합니다.

사전 요구 사항

하나 이상의 Azure 구독이 구성된 실행 중인 상태의 Azure SRE 에이전트입니다.
웹후크 호출을 테스트하기 위해 Azure CLI 설치(az 명령)

시나리오

팀은 하루에 여러 번 컨테이너 앱 수정 버전을 배포합니다. 각 배포는 적절한 리소스 제한, 설정된 상태 확인 프로브, 구성된 인그레스 규칙과 함께 규정 준수 표준을 충족해야 합니다. 모든 배포 후에 수동으로 확인하는 대신 각 배포 후에 CI/CD 파이프라인이 호출하는 HTTP 트리거를 만듭니다. 에이전트는 규정 준수 검사를 자동으로 실행합니다.

HTTP 트리거 열기

HTTP 트리거를 열려면 서비스 메뉴에서 Builder>HTTP 트리거 로 이동합니다.

검사점: 페이지가 요약 카드(활성 트리거: 0, 총 트리거: 0, 총 실행: 0) 및 빈 트리거 목록과 함께 로드됩니다.

1단계: 트리거 만들기

도구 모음에서 트리거 생성을 선택합니다. HTTP 만들기 트리거 대화 상자가 열립니다.

양식에서 다음 필드를 입력합니다.

분야	가치
트리거 이름	컨테이너 앱 준수 확인.
트리거 세부 정보	새 컨테이너 앱 수정 버전이 배포되었습니다. 앱에서 규정 준수 검사를 실행합니다. 리소스 제한(CPU/메모리), 상태 프로브, 수신 구성 및 크기 조정 규칙이 올바르게 구성되었는지 확인합니다. 발견된 문제를 보고합니다. 앱 세부 정보: 리소스 그룹 `{payload.app_name}`의 `{payload.resource_group}`. 개정 버전: `{payload.revision_name}`.
에이전트 자율성 수준	자율(기본값).
업데이트에 대한 메시지 그룹화	각 실행에 대한 새 채팅 스레드입니다.

검사를 특정 서브에이전트가 처리하도록 하고 싶지 않다면, Response subagent 는 기본값으로 두세요.
트리거 만들기를 선택합니다.

검사점: 트리거가 상태 켜 기(녹색 배지)와 함께 목록에 나타납니다. 요약 카드는 하나의 활성 트리거를 표시하도록 업데이트됩니다.

2단계: 트리거 URL 복사

트리거 이름 컨테이너 앱 준수 검사를 선택하여 세부 정보 보기를 엽니다.
다음 필드가 표시됩니다.
- 트리거 URL: 복사 단추가 있는 웹후크 엔드포인트
- 상태: 켜기
- 마지막 호출: 안 함
- 메시지 그룹화: 각 실행에 대한 새 스레드
트리거 URL 옆에 있는 복사 단추를 선택합니다. 4단계에서 사용하므로 URL을 저장합니다.

검사점: 트리거 URL이 복사되었습니다. https://<your-agent>.sre.azure.com/api/v1/httptriggers/trigger/<trigger-id> 형식입니다.

3단계: 지금 실행으로 테스트

도구 모음에서 지금 실행 트리거 를 선택합니다. 이 작업은 외부 호출 없이 트리거를 즉시 실행합니다.
몇 초 정도 기다린 다음 업데이트 목록을 선택하여 실행 기록을 새로 고칩니다.

검사점: 실행 기록에는 타임스탬프, 연결된 스레드 및 성공 상태가 있는 새 행이 표시됩니다. 스레드 링크를 선택하여 에이전트의 응답을 확인합니다.

에이전트는 HTTP 트리거: 컨테이너 앱 준수 검사라는 스레드를 만듭니다. 내부에는 규정 준수 확인 계획이 있는 실행 카드가 표시되고 에이전트의 전체 조사와 규정 준수 결과가 포함된 평결 테이블이 표시됩니다.

4단계: 명령줄에서 트리거 호출

이제 실제 페이로드를 사용하여 CI/CD 파이프라인의 방식을 테스트합니다. 터미널을 열고 다음을 실행합니다.

# Get an ARM token (use the SRE Agent app ID as the resource)
TOKEN=$(az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv)

# Call the trigger with container app deployment details
curl -X POST \
  "<YOUR_TRIGGER_URL>" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "app_name": "checkout-api",
    "resource_group": "rg-production",
    "revision_name": "checkout-api--v3",
    "deployed_by": "github-actions",
    "image": "myregistry.azurecr.io/checkout-api:v3.2.1"
  }'

2단계에서 복사한 URL로 <YOUR_TRIGGER_URL>을 바꿉니다.

무슨 일이 일어나나요? 에이전트는 {payload.app_name} 프롬프트를 수신하고, {payload.resource_group} 및 {payload.revision_name}를 실제 값으로 교체합니다. 자리 표시자와 일치하지 않는 필드(예 deployed_by : 및 image)는 원시 JSON 컨텍스트로 추가됩니다.

응답은 HTTP 202를 사용하여 즉시 반환됩니다.

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

검사점: 포털로 돌아가서 세부 정보 보기에서 업데이트 목록을 선택합니다. 기록에서 두 번째 실행을 확인할 수 있어야 합니다. 이 항목은 외부 호출에서 가져온 것입니다. 스레드 링크를 선택하여 실제 앱 세부 정보가 채워진 에이전트의 규정 준수 검사를 확인합니다.

5단계: 파이프라인과 통합

CI/CD 파이프라인의 배포 후 단계에 트리거 호출을 추가합니다. GitHub Actions의 예는 다음과 같습니다.

- name: Trigger SRE Agent compliance check
  if: success()
  run: |
    TOKEN=$(az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv)
    curl -s -X POST "${{ secrets.SRE_TRIGGER_URL }}" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "app_name": "${{ env.APP_NAME }}",
        "resource_group": "${{ env.RESOURCE_GROUP }}",
        "revision_name": "${{ env.REVISION_NAME }}",
        "deployed_by": "${{ github.actor }}",
        "commit": "${{ github.sha }}"
      }'

트리거 URL을 GitHub 비밀(SRE_TRIGGER_URL)로 저장합니다. 워크플로 파일에서 하드 코딩하지 마세요.

6단계: 리소스 정리

트리거가 더 이상 필요하지 않은 경우 다음을 삭제합니다.

Builder>HTTP 트리거로 이동합니다.
트리거 확인란을 선택합니다.
을 선택하고을 삭제합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-04-22