배포 빠른 시작

FDAI는 infra/ 아래의 코드형 인프라(IaC)로 프로비저닝하며, Terraform이 실행 엔진이자 단일 기준입니다. 턴키 azd 래퍼를 쓰거나 Terraform을 직접 실행하는 두 경로로 동일한 최소 Azure 인벤토리를 구성할 수 있습니다. 두 경로 모두 먼저 미리보기를 제공하므로, 별도의 적용 단계를 실행하기 전에 계획을 검토할 수 있습니다.

시작하기 전에

• 리소스를 만들 수 있는 Azure 구독과 Azure CLI(az)가 필요합니다. 턴키 경로에는 Azure Developer CLI(azd)도 필요합니다.
• 배포 사전 점검을 완료해야 합니다. 이 점검은 컨트롤 루프가 시작되기 전에 쿼터, 권한, 연결, 롤백 차단 요소를 수집합니다.
• 환경별 값을 *.tfvars 파일에 입력합니다. 이 파일은 커밋하지 마세요.
• 승인된 대상을 AZURE_SUBSCRIPTION_ID와 AZURE_TENANT_ID로 내보내기합니다. 현재 자격 증명이나 선택된 azd 환경이 이 조합과 다르면, 부트스트랩과 턴키 헬퍼가 아무것도 바꾸기 전에 중단합니다.
• container-supply-chain.yml이 증명한 FDAI 런타임 이미지가 필요합니다. 실행기 계획은 ghcr.io/<owner>/<repo>/fdai-core-control-plane에서 runtime_image_revision의 증명을 검증하고 ACR fdai 저장소의 동일 다이제스트를 연결합니다. 검증된 다이제스트를 계획 전에 가져오기할 때만 promote_runtime_image=true를 사용하세요. Exact 적용은 이미지를 promote하거나 재구축하지 않습니다.
• 배포 호스트에서 모든 비공개 엔드포인트로 연결할 수 있어야 합니다. 프라이빗 전용 환경에서는 운영자 워크스테이션 대신 VNet에 연결된 배포 러너에서 Terraform을 실행하세요. 그 환경의 Premium 레지스트리도 프라이빗이므로 이미지 빌드와 푸시도 같은 러너에서 하세요.
• 보호된 원격 계획을 쓰려면 비밀이 아닌 DEPLOY_PREFLIGHT_INPUT_JSON 저장소 변수에 필요한 라이브 카테고리를 모두 설정하세요. 프로필이 없으면 Azure 로그인 전에 중단하고, 프로브가 차단되면 정제된 점검 결과와 발견된 문제만 로그에 남습니다. Terraform 계획 이후 runner-owned run_live_preflight.py가 Azure Policy, Compute quota, executor RBAC 및 value-blind Key Vault secret metadata를 검사합니다. 점검이 불완전하면 계획 산출물을 저장하기 전에 중단합니다.
• 내부 Isolated 실행기를 미리보려면 private-runner 작업 흐름에서 deploy_isolated_executor를 선택하세요. 별도로 적용을 승인하기 전까지 plan-only 상태이며, 관찰 모드 자격 증명에는 작업별 효과 역할이 없습니다.
• 범위가 제한된 OHL scale-out 근거 대상을 프로비저닝하려면 private networking과 개발 운영 게이트웨이를 사용하는 dev 환경에서만 enable_ohl_scale_out_evidence_target을 사용하도록 설정하세요. Exact 이미지 버전, 보호된 작업 흐름의 SSH 공개 키 입력, 재시도해도 유지되는 캠페인 ID 및 사람 개시자의 주체 ID를 제공해야 합니다. 대상은 용량 1로 시작합니다. 수동 proposal Job은 정상 수신 경로를 통해 관찰 모드 제안 하나를 게시하며 provider-effect 권한은 갖지 않습니다. 보호된 provider staging은 검증된 롤백 전에 용량을 2까지만 늘릴 수 있습니다.

최소 인벤토리 프로비저닝

먼저 미리보기하고, 계획이 예상과 일치할 때만 적용하세요. 두 경로 모두 동일한 infra/ Terraform 구성을 사용하므로 워크플로에 맞는 쪽을 고르면 됩니다.

프라이빗 네트워킹으로 전환하는 보호된 작업에서 허용되는 삭제는 광범위한 PostgreSQL Azure-services 방화벽 규칙을 없애는 것 하나뿐입니다. 계획에 같은 주소의 교체나 다른 삭제가 보이면 적용을 중단하세요.

개발 운영 게이트웨이가 보호된 targeted 계획을 사용한다면 AI 계정과 역할 수집이 모두 포함됐는지 확인하세요. 그래야 네트워크 및 권한 확인 변경이 같은 적용에서 수렴하고 post-apply 계획이 남지 않습니다. deploy_isolated_executor도 선택했다면 isolated 실행기 모듈과 해당 의존성 그래프가 targeted 계획에 나타나는지 확인하세요.

azd (턴키)terraform (직접)

azd auth login
azd env new fdai-dev
export AZURE_SUBSCRIPTION_ID="<expected-subscription-id>"
export AZURE_TENANT_ID="<expected-tenant-id>"
# 안전한 미리보기 - `azd provision --preview` 실행, 아무것도 적용하지 않음
scripts/deployment/azure/azd-up.sh
# 실제 프로비저닝 - 두 번째 게이트가 실수로 적용하는 일을 막음
FDAI_AZD_CONFIRM=1 scripts/deployment/azure/azd-up.sh

az login
export AZURE_SUBSCRIPTION_ID="<expected-subscription-id>"
export AZURE_TENANT_ID="<expected-tenant-id>"
scripts/deployment/azure/verify-azure-context.sh \
   "$AZURE_SUBSCRIPTION_ID" "$AZURE_TENANT_ID"
terraform -chdir=infra init
# 템플릿을 복사해 값을 채웁니다 (tfvars는 커밋하지 않음)
cp infra/envs/dev.tfvars.example infra/envs/dev.tfvars
terraform -chdir=infra plan  -var-file=envs/dev.tfvars
terraform -chdir=infra apply -var-file=envs/dev.tfvars

프로비저닝 후

1. 인벤토리 검증. 리소스가 만들어졌는지, 실행기 자격 증명이 지정된 범위에서 최소 권한만 갖는지 확인합니다. 그런 다음 아래 항목을 확인합니다.
   • 구독 Event Grid 전달이 인벤토리 관리 자격 증명으로 운영 Event Hubs 샤드의 aw.inventory.raw에 도달합니다.
   • 기본 샤드가 Standard 엔터티 10개 제한 안에 있고, Huginn이 테스트 리소스 변경을 투영합니다.
   • 인벤토리 작업이 10분마다 깨어나고, PostgreSQL이 정상 전체 스캔을 6시간으로 유지하며, 실패하거나 중단된 시도가 다음 틱에 재시도됩니다. 이때 코어에는 job-start 역할을 주지 않습니다.
   • 프라이빗 네트워킹을 켰다면 PostgreSQL과 두 Event Hubs 샤드가 런타임 서브넷이나 피어링된 러너에서 프라이빗 주소로 확인되고, TLS 점검을 통과하며, Event Hubs 공개 접근이 꺼져 있습니다.
2. 런타임 상태와 자격 증명 검증. 내부 코어 프로브가 정상인지, 15개 에이전트가 모두 상태 스냅샷에 보고되는지, 첫 canary 발행기 작업이 완료됐는지 확인합니다. 이어서 켜 둔 기능만 확인합니다.
   • Operator API: 브라우저 Entra 앱 역할이 동작하고, 읽기와 명령 자격 증명이 Thor의 실행기 관리 자격 증명과 분리돼 있습니다.
   • Isolated 실행기: 활성화한 경우 내부 /live와 /ready 프로브가 통과하고 최신 개정 번호가 활성 상태이며, 전용 자격 증명에는 이미지 pull, 명령 수신, 증적 또는 DLQ 전송, state-secret 읽기만 있습니다. 권한 전환 전에는 작업별 효과 역할이 없습니다.
   • 이메일 알림: incident-open 메시지가 multipart HTML과 plain 텍스트로 도착합니다. Console을 활성화한 경우 상세 링크는 Static Web App 출처를 사용하고 Settings > Integrations는 합성 자리 표시자로 동일한 렌더러를 표시합니다.
   • 문서 OCR: 수집 자격 증명이 지정된 문서 Intelligence 리소스에만 Cognitive Services User 역할을 갖습니다.
   • 케이스 히스토리: 전용 관리 자격 증명만 Blob 데이터에 접근하고, 실행기에는 케이스 히스토리 Blob 역할이 없으며, 비공개 네트워크 룰은 Defender scanner private-link 접근을 유지하고, FDAI_CASE_HISTORY_RETENTION_TICK_SECONDS가 승인된 삭제 주기와 일치합니다.
   • 예측 학습: 옵트인 작업이 원시 틱만 발행하고, 코어에 검토된 FDAI_FORECAST_TARGETS_JSON 문서가 있습니다.
   • Analyzer tick: FDAI_INVENTORY_DSN이 설정되면 Job이 명시적 대상과 영속 인벤토리 projection에서 지원되는 리소스만 병합하고 구성된 발견 상한을 보고합니다. 지원하지 않는 리소스 타입은 제외하며, 완전히 해석된 대상 집합이 비어 있으면 정상 no-op으로 종료합니다. 보호된 배포에서는 TRACE_TOPOLOGIES_JSON repository variable을 설정합니다. Workflow가 이를 Job의 FDAI_TRACE_TOPOLOGIES_JSON으로 전달합니다. 같은 Job과 읽기 신원이 범위가 제한된 작업 영역 기반 Application Insights 근거를 조회합니다. 완전한 추적은 발견된 문제를 보고하지 않고, 누락되거나 분리된 hop은 관찰 모드로 하나를 보고합니다. 빈 값은 연속성 검사만 비활성화합니다.
   • OHL scale-out 근거: 활성화한 경우 수동 proposal Job을 시작하고, 설정된 캠페인과 개시자가 포함된 관찰 모드 제안 하나만 정상 수신 경로에 도달하는지 확인합니다. 이 자격 증명에는 이미지 pull과 기본 Event Hubs send 권한만 있고 provider-effect 권한은 없습니다.
3. 개발 운영 게이트웨이 검증. 이것은 개발 도구입니다. Easy Auth 뒤에서 공개 인바운드 엔드포인트를 종단하며, Terraform은 env=dev가 아니면 계획 자체를 거부합니다. 폐쇄망에서는 꺼둔 채로 두십시오. 이 게이트웨이를 켰다면 아래를 확인합니다.
   • 보호된 소스 아카이브가 Terraform 적용 뒤에 배포됐고, 현재 원격 빌드 배포가 성공했습니다.
   • 두 함수 트리거가 등록됐고, 호스트와 멱등성 저장소가 읽기 담당 관리 자격 증명을 사용하며, 등록된 네트워크 읽기가 성공합니다.
   • 실행기 주체로 제한된 변경 하나를 계획하고, 반환된 일회용 증적으로 제출한 뒤, 재실행이 두 번째 ARM 호출을 만들지 않는지 확인하고, ARM이 submitted를 반환하는 동안 멱등성 키로 상태를 조회합니다.
4. 제한된 범위 하나 온보딩. 리소스 그룹 크기의 범위 하나로 시작하고 소유자를 지정합니다.
5. 관찰 모드로 지켜보기. FDAI가 아무것도 바꾸지 않고 판단과 감사만 하도록 두고, 실행했을 법한 작업을 검토합니다.
6. 하나의 작업 승격. 승격 기준을 통과한 작업만 적용 모드로 바꾸고, 나머지는 관찰 모드로 둡니다.

시작하기 가이드에서는 이 첫 번째 안전한 롤아웃을 자세히 다룹니다. 배포와 온보딩은 전체 배포 참고 자료입니다.

관련 문서

사전 점검프로비저닝 전에 차단 요소를 해소합니다.배포와 온보딩전체 배포 참고 자료와 Azure 인벤토리.시작하기오리엔테이션과 첫 번째 안전한 롤아웃.운영자 콘솔FDAI가 실행된 후 상태를 조회하는 방법.