참조
배포 모드
AisOpsFlow Enterprise가 지원하는 배포 패턴과 운영상 의미를 설명합니다.
주요 배포 패턴
온프렘 스택
적합한 경우:
- 로컬 평가
- 내부 배포
- 더 단순한 운영 경계
특징:
- Docker Compose 친화적
- SQLite 중심
- 단순한 부트스트랩 흐름
하이브리드 모델
적합한 경우:
- 중앙 관리형 제어 평면
- 고객 현장 실행 요구
- 엄격한 네트워크 경계
특징:
- 클라우드 또는 중앙 환경의 Core
- 고객 현장의 Runner
- Core를 향한 Runner의 아웃바운드 연결
- mTLS 가능한 gRPC 전송
실제 결정 포인트
모델 선택 시 다음을 보세요.
- 실행 환경 접근 권한을 누가 가지는지
- 고객 사이트 인바운드 연결이 허용되는지
- 중앙 멀티테넌트 제어가 필요한지
- 실행과 플러그인 정책에 어떤 컴플라이언스가 적용되는지
적용 전 핵심 질문
- Core는 어디서 실행할지
- Runner는 어디서 실행할지
- 어떤 플러그인을 허용할지
- 인증서, 토큰, 콜백 비밀값을 어떻게 관리할지
- 백업과 복구 기대 수준은 무엇인지
로컬 평가 경로
대부분 팀의 가장 빠른 시작은 다음입니다.
deploy/.env.onprem.example복사- 온프렘 compose 스택 실행
- 로그인, 워크플로 업로드, 알림 경로 확인
하이브리드 경로
하이브리드 배포 전에는 다음을 검증해야 합니다.
- Runner 등록과 식별
- Core ↔︎ Runner TLS 정책
- 아웃바운드 전용 연결 가정
- 플러그인 런타임 정책과 로컬 가용성
- OCI registry 접근, digest pinning, plugin bundle trust policy
- OCI 기반 managed plugin을 켜려면 Runner 호스트에 로컬
dockerCLI 가 있어야 함
현재 managed plugin 상태
현재 Runner는 이미 다음을 할 수 있습니다.
- plugin runtime config 읽기
- startup 시 OCI plugin ref preinstall
- plugin image를 install root로 pull/unpack
runner-plugin.yamlvalidation- 유효한
stdio-jsonmanaged plugin을 on-demand 실행
동시에 기존 HTTP plugin URL fallback도 계속 유지합니다. 그래서 하이브리드 배포는 점진적으로 전환할 수 있습니다.
- 기존
PLUGIN_*_URLplugin을 그대로 유지 - 선택한 capability부터
resolution.capability_map추가 runner-plugin.yaml과 올바른 working directory를 포함한 OCI plugin image publish- notify 응답의
transport,runtime_error필드로 managed execution 여부 확인
Runner-managed on-demand plugin을 OCI로 배포할 계획이면 다음 문서도 함께 보세요.