Skip to content
SaaS ERP SaaS ERP Docs

English {#english}

Intelligent Automation Implementation Plan

Purpose: Stepwise plan to implement end-to-end automation, monitoring, and AI server placement as defined in saas-unified-architecture-hetzner-cloudflare-zuplo-plan §9 and tenant-provisioning-flow §B.
No code generation — implementation order, deliverables, and dependencies only.

1. Reference plans

  • saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md §9: intelligent automation (full pipeline, monitoring, AI placement).
  • tenant-provisioning-flow.md §A, §B: provisioning flow; Control Plane monitoring and AI placement.
  • api-control-plane-implementation-plan.md §1–§21: unified Control Plane (phases, contract, queues, observability, security, runbook, backup, verification).

2. Implementation order and dependencies

Order: [1] Pulumi (skip if exists). [2] D1 schema (nodes, server_metrics, provision_jobs columns) → [3] Ansible playbook/roles + [4] zuplo_sync → [5] End-to-end workflow (Pulumi → Ansible → Zuplo → callback) → [6] Resource/usage monitoring collection → [7] AI placement engine (rules or model) → [8] Control Plane Webhook: call placement then trigger workflow/Worker with job_id, tenant_id, region, target_server_id/create_new_server.

Dependencies: [2] required for [5][6][7]. [3][4] required for [5]. [6] required for [7]. [8] after [5][7].

3–5. Deliverables, verification, references

  • §3.1 D1: Migration 0007 — nodes (fqdn, max_tenants), server_metrics, provision_jobs (target_server_id, create_new_server).
  • §3.2 Ansible + Zuplo Sync: prego-ansible playbook, roles (docker, frappe_site), artifacts/tenant_api_key.txt; zuplo_sync.ts; provision-tenant-pipeline runbook. Ansible scope: Vectorize/tenant DNS out of scope per pulumi-ansible-step1-step2 §3. For running tenant creation (bench new-site) in a separate Job (not Ansible runtime), see ansible-frappe-bench-rc127-resolution-plan §16 item 4.
  • §3.3 Workflow: provision-tenant-workflow-design (read first); .github/workflows/provision-tenant.yml or Provision Worker; runbook.
  • §3.4 Monitoring: Hetzner/agent/Cron → Control Plane → D1 server_metrics/servers; tenant usage for placement; resource-optimization-safe-adoption-plan.
  • §3.5 Placement: Rule engine (server_metrics, servers → target_server_id or create_new_server); optional ML; decidePlacement(); trace_events.
  • §3.6 Webhook: Stripe Webhook → provision_jobs → decidePlacement() → workflow_dispatch or Provision Worker with placement result.
  • §4 Verification: D1/Ansible/zuplo_sync/workflow/monitoring/placement/e2e checklist.
  • §5 References: Links to saas-unified §9, tenant-provisioning-flow, IMPLEMENTATION_INDEX.

Full tables (§1, §3.1–§3.6) and exact wording are in the Korean section below.

한국어 {#korean}

지능형 자동화 구현 계획

목적: 기획서 saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md §9, tenant-provisioning-flow.md §B 에 정의된 전 구간 자동화·모니터링·AI 서버 배치를 구현하기 위한 단계별 계획.
코드 생성 없음 — 구현 순서·산출물·의존 관계만 정리.

1. 참조 기획

문서섹션내용
saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md§9지능형 자동화(전 구간 자동화, 모니터링, AI 배치)
tenant-provisioning-flow.md§A, §B프로비저닝 플로우, Control Plane 모니터링·AI 배치
api-control-plane-implementation-plan.md§1–§21통합 Control Plane(5단계·Contract·Queues·보상·Observability·보안·Runbook·백업·구현 Phase·검증 조건)

2. 구현 순서 및 의존 관계

[2] D1 스키마 확장 (servers, server_metrics, provision_jobs 컬럼)
         ↓
[3] Ansible playbook·롤 (Docker + Frappe + new-site + API Key)
[4] zuplo_sync 스크립트
         ↓
[5] 전 구간 자동화 워크플로 (Pulumi → Ansible → Zuplo → 콜백)
         ↓
[6] 리소스·사용량 모니터링 수집·저장
         ↓
[7] AI 배치 결정 엔진 (규칙 또는 모델)
         ↓
[8] Control Plane Webhook에서 배치 호출 후 트리거 연동
  • [1] Pulumi: 이미 존재 시 스킵. 없으면 Hetzner·Cloudflare DNS/SSL·R2 연동 완료 후 진행.
  • [2] D1: servers, server_metrics, provision_jobs(target_server_id, create_new_server 등)가 있어야 [5][6][7] 연동 가능.
  • [3][4]: [5] 워크플로가 Ansible·zuplo_sync를 호출하므로 선행 필요.
  • [6] 모니터링: [7] AI 배치가 server_metrics·servers를 읽으므로 선행.
  • [8]: [5][7] 완료 후 Webhook에서 배치 결정 → workflow_dispatch(또는 Provision Worker) 호출 시 job_id, tenant_id, region, target_server_id/create_new_server 전달.

3. 단계별 산출물

3.1 D1 스키마 확장 (순서 2)

산출물내용
마이그레이션0007_intelligent_automation.sql 적용. 기존 nodes 테이블(0006)을 서버 레지스트리로 사용, fqdn, max_tenants 컬럼 추가.
마이그레이션server_metrics 테이블: node_id, cpu_pct, memory_pct, disk_pct, tenant_count, collected_at (node_id = nodes.node_id).
마이그레이션provision_jobs에 target_server_id (TEXT, node_id 참조), create_new_server (INTEGER 0/1) 컬럼 추가.
문서D1 테이블 정의서에 server_metrics·nodes 확장·provision_jobs 확장 명시. 적용 순서: migrations/APPLY.md 참조.

3.2 Ansible + Zuplo Sync (순서 3, 4)

산출물내용
Ansible구현됨. prego-ansible 레포: playbook.yml, inventory/, roles/docker, roles/frappe_site. 인벤토리(ansible_host), tenant_id → Docker + Frappe new-site + API Key. 결과를 artifacts/tenant_api_key.txt에 기록(워크플로 artifact → Zuplo Sync).
Ansibleroles: docker, frappe_site. Ref: config/README.md.
스크립트구현됨. infra/zuplo_sync.ts: tenant_id, api_key(또는 --api-key-file <path>) → Zuplo Developer API 등록. CLI 및 syncTenantApiKey() export.
Runbookdocs/runbook/provision-tenant-pipeline.md: 수동 실행 순서 및 워크플로 입력 스펙.
Ansible 범위pulumi-ansible-step1-step2-plan.md §3: Cloudflare Vectorize·테넌트 canonical DNS·테넌트 사용자 CNAME은 Ansible 비범위로 정리. Vectorize → Pulumi 또는 전용 스크립트, 테넌트 DNS → 현행 cloudflare-tenant-dns.ts + 워크플로 유지.
Ansible 단계별 구현ansible-implementation-plan.md: Frappe/bench 설치 role → 변수·시크릿 → 로컬 검증 → CI 연동 → 문서화 순서.
Provisioner Job테넌트 생성(bench new-site)을 Ansible 런타임이 아닌 별도 Job에서 실행하는 설계: ansible-frappe-bench-rc127-resolution-plan §16 항목 4.

3.3 전 구간 자동화 워크플로 (순서 5)

산출물내용
설계 기획서provision-tenant-workflow-design.md: 워크플로 vs Provision Worker 비교, 입출력·단계별 설계·콜백 스펙·보안·멱등. 구현 전 필독.
워크플로.github/workflows/provision-tenant.yml: inputs job_id, tenant_id, region, target_server_id(optional), create_new_server(optional). target_server_id 없고 create_new_server 시 Pulumi up → server_ip; 있으면 D1 nodes에서 host 조회. Ansible → api_key 수집 → zuplo_sync → Control Plane 콜백으로 provision_jobs=Completed, tenants_master=Active 갱신.
또는Provision Worker: D1 Pending job 폴링 또는 HTTP 트리거 → (Pulumi/Ansible은 외부 호출) → Zuplo → D1 직접 갱신.
문서runbook: 워크플로 입력·Secrets·실패 시 재시도·콜백 URL 안내.

3.4 리소스·사용량 모니터링 (순서 6)

산출물내용
수집 경로Hetzner API 또는 노드 에이전트/Cron → Control Plane API 또는 Worker → D1 server_metrics·servers 갱신. 주기 1~5분.
서비스 사용량기존 R2 Raw + D1 집계·Zuplo 메터링 활용. tenant_id별 부하 지표를 배치 시 참고할 수 있도록 스키마/쿼리 정리.
문서모니터링 수집 주기·필수 메트릭·D1 쓰기 정책.
Data Plane 리소스 절감resource-optimization-safe-adoption-plan.md — Redis·Gunicorn·CDN·Docker 제한 등 기존 시스템 영향 없이 적용 순서.

3.5 AI 배치 결정 (순서 7)

산출물내용
규칙 엔진D1 server_metrics·servers 조회 → region·plan_tier·임계치(CPU/메모리/테넌트 수)·정책(서버당 최대 N) 적용 → target_server_id 또는 create_new_server 반환.
(선택) 모델ML/LLM 호출로 “최적 서버” 또는 create_new 추천. 입력: tenant_id, plan_tier, region, 현재 server_metrics 요약.
API/함수Control Plane 내부 또는 Worker: `decidePlacement(tenant_id, plan_tier, region) → { target_server_id?
감사LogPath trace_events에 stage=PLACEMENT_DECIDED, payload에 target_server_id/create_new_server 기록.

3.6 Webhook·트리거 연동 (순서 8)

산출물내용
Control PlaneStripe Webhook 처리 후 provision_jobs 삽입 → decidePlacement() 호출 → 결과를 workflow_dispatch(또는 Provision Worker) 입력으로 전달(job_id, tenant_id, region, target_server_id, create_new_server).
문서Webhook → 배치 → 트리거 순서 및 입력 스펙.

4. 검증 체크리스트

  • D1 servers, server_metrics, provision_jobs 확장 적용 후 조회·갱신 정상.
  • Ansible만 수동 실행 시 해당 서버에 사이트·API Key 생성 성공.
  • zuplo_sync 수동 실행 시 Zuplo에 Consumer·Key 등록 확인.
  • 워크플로 수동 dispatch(job_id, tenant_id, region, create_new_server=true) 시 Pulumi→Ansible→Zuplo→콜백까지 완료되고 provision_jobs=Completed, tenants_master=Active 반영.
  • 워크플로 dispatch(target_server_id=기존 서버) 시 Pulumi 스킵, Ansible만 해당 서버로 실행 후 Zuplo·콜백 완료.
  • 모니터링 수집 주기적으로 server_metrics·servers 갱신 확인.
  • decidePlacement() 호출 시 조건에 따라 target_server_id 또는 create_new_server 반환 확인.
  • End-to-end: 결제 완료 → Webhook → 배치 결정 → 워크플로 → 테넌트 Ready 까지 자동 완료.

5. 참조

Help