N
Nivora

DevOps 交付控制平面

Nivora 用于接入 Jenkins、Argo CD、Kubernetes 等现有工具, 统一记录交付状态、制品身份、策略门控和审计轨迹。

Beta candidate · 用于评估和开发验证

现代交付链路通常横跨代码仓库、CI 运行器、制品仓库、策略检查、部署引擎、云资源、日志系统和审计系统。 各系统分别维护状态和身份语义,部署状态、制品身份、审批记录和回滚上下文容易分散。

Nivora 将 PipelineRun、Release、DeploymentRun、Artifact、Environment、Policy、AuditLog 作为核心模型。 它集成底层工具,不替代现有工具;目标是让交付状态可查询、可审计、可追溯。

现状

  • 部署状态分散在各子系统
  • 制品依赖可变标签,身份不可追溯
  • 审批和策略门控缺乏统一标准
  • 回滚时上下文丢失

Nivora

  • 统一交付时间线查询接口
  • 制品绑定不可变 digest / 签名
  • 策略和审批作为一等模型实体
  • 每次部署生成审计记录

控制平面 / 执行平面分离

控制平面负责 API、状态、编排、策略和审计。执行平面负责作业执行、日志采集、心跳和运行结果上报。 API Server 不直接执行部署作业。

Runner ≠ Executor

Runner 定义作业执行的上下文和环境(who),Executor 定义具体的执行机制(how)。该分离使编排层无需为每种执行环境重写调度逻辑。

Runner

  • Local Runner
  • Host Runner
  • Kubernetes Runner
  • GitOps Runner
  • Cloud Runner

Executor

  • Shell Executor
  • SSH Executor
  • K8s Job Executor
  • Helm / YAML Executor
  • Argo CD Executor
  • Webhook Executor

Ports & Adapters

外部系统通过 Port 接口接入核心。用例层依赖能力接口,不直接依赖具体厂商 SDK。

端到端交付流

从触发到交付时间线的完整生命周期。当前实现覆盖基于 Shell 的 PipelineRun 子集。

核心概念

领域模型覆盖交付全生命周期。

Application

Nivora 管理的产品或服务实体

Environment

交付上下文(dev / staging / prod)

Pipeline

可复用的 stage / job / step 定义

PipelineRun

Pipeline 的一次执行实例

Release

版本化交付意图,关联不可变制品

DeploymentRun

发布或部署计划的一次执行

Runner

接收并执行作业的组件

Executor

Runner 使用的具体执行机制

Policy

允许、拒绝或要求审批的门控

AuditLog

关键操作的持久化记录

Event

交付生命周期中的运行时事件

LogChunk

有序的 stdout / stderr 日志段

技术栈

Go 1.22,最小化外部依赖。

核心

  • Go 1.22
  • go-chi/chi (HTTP router)
  • spf13/cobra (CLI)
  • log/slog (structured logging)

存储

  • jackc/pgx (PostgreSQL)
  • goose / golang-migrate (migrations)
  • S3 / MinIO / local (object store)
  • Memory / NATS (event bus)

协议

  • REST + OpenAPI
  • AsyncAPI (events)
  • Protobuf (gRPC)
  • CloudEvents (envelopes)

依赖原则

优先使用标准库
复用现有依赖
新增依赖须说明必要性
不为简单辅助函数引入额外依赖

模块化单体

以模块化单体架构起步,内部边界稳定后支持服务拆分。四个二进制对应四个独立运行时角色。

N

nivora-server

API Server

控制平面入口。REST / gRPC API、状态管理、策略决策和审计记录。

N

nivora-worker

Worker

消费队列中的 PipelineRun,构建运行计划并分发给 Runner。

N

nivora-runner

Runner

接收作业,委托 Executor 执行,上报日志、心跳和状态。

N

nivora

CLI

本地操作入口,用于流水线运行、部署计划和发布部署。

目录结构

cmd/ — 二进制入口
internal/domain/ — 领域模型
internal/usecase/ — 业务编排
internal/ports/ — 外部能力接口
internal/adapters/ — 外部系统适配
internal/infra/ — 技术基础设施
internal/api/ — HTTP / gRPC 传输层

分层规则

Domain 定义领域含义,用例层负责业务编排,Ports 定义接口契约, Adapters 实现外部集成,Infra 提供技术基础设施,API 处理传输协议。

当前能力状态

当前处于 beta candidate 阶段。以下列表按代码和文档现状列出,不扩大已完成功能范围。

后端骨架
已完成已完成
架构边界
已完成模块边界与校验脚本
PipelineRun 运行时
已完成Shell 执行、日志、状态流转和审计记录
K8s YAML 计划与预检
进行中非破坏式计划生成,本地空执行验证
制品绑定与 OCI Digest
进行中制品摘要解析基础能力
Argo CD GitOps
进行中适配器基础能力
DevSecOps 策略门控
规划中规划中
AuthN / AuthZ / RBAC
规划中规划中
审批、变更窗口与通知
规划中规划中
可视化 API 与 Web UI
规划中读模型 API 与基础前端
生产级多云适配器
规划中后续阶段
完整 DevSecOps 集成
规划中后续阶段

部署

支持 Docker Compose、Helm Chart 和 Kubernetes 原生清单。当前阶段适用于本地开发和评估。

Docker Compose

Server + worker + runner + PostgreSQL 本地组合。

Helm Chart

生产配置、滚动更新和健康探针。

Kubernetes

Kubernetes 原生 YAML 清单。

terminal
$ make build
go build ./cmd/...
✓ nivora-server
✓ nivora-worker
✓ nivora-runner
✓ nivora CLI

$ make run-server
Server ready at :8080

$ go run ./cmd/nivora pipeline run --local
examples/pipelines/simple-shell.yaml

API

REST + OpenAPI。未实现端点返回 not_implemented 结构化响应,不返回占位数据。

/api/v1/orgs · /projects · /pipelines · /pipeline-runs · /deployments · /releases
N

统一的交付控制平面

接入现有工具链,统一交付状态、制品身份、策略门控和审计轨迹。

N
© 2026 Nivora