【免费下载链接】ccg-workflow多模型协作工作流引擎 — /ccg:go 一个命令AI 自动分析意图、选择策略、编排 Codex Gemini Claude 协作执行项目地址https://gitcode.com/gh_mirrors/cc/ccg-workflow点击查看免费下载本指南以 ccg-workflow 项目「域知识秘典」中的 云原生架构 为骨架系统讲解容器化构建、容器编排、无服务器计算与微服务治理四类云原生核心技术并还原这些知识在 CCG 多模型协作工作流中如何被自动路由与注入。读完本文你将掌握可直接复用的 Dockerfile / Docker Compose / Kubernetes 资源清单 / Serverless Framework 配置模板以及从镜像安全到 Pod 安全准入的完整加固清单。一、这是怎样的一份文档CCG 域知识秘典与自动路由机制在 ccg-workflow 的技能体系中templates/skills/domains/下按领域组织了一批「域知识秘典」domain knowledge云原生架构 是其中 architecture 领域architecture/SKILL.md的五篇秘典之一与api-design.md、security-arch.md、message-queue.md、caching.md并列。该文档通过 YAML frontmatter 声明自己的身份与触发条件--- name: cloud-native description: 云原生架构。容器、Kubernetes、Serverless、微服务。当用户提到云原生、容器、Docker、Kubernetes、K8s、Serverless时使用。 ---这份 frontmatter 正是整套自动路由机制的数据源。其运行链路可以从仓库源码中完整还原安装期installer.ts 的installSkillFiles()会把templates/skills/整树递归复制到~/.claude/skills/ccg/因此该文档最终落在~/.claude/skills/ccg/domains/architecture/cloud-native.md发现期skill-registry.ts 解析所有SKILL.md与秘典文件的 frontmatter依据目录首段推断类别domains→domain依据是否存在scripts/*.js区分scripted与knowledge运行时类型——cloud-native 属于纯知识型knowledgeuser-invocable默认为false不生成斜杠命令路由期ccg-skill-routing.md 定义了关键词映射表其中一行明确写着cloud native, Kubernetes, Docker, microservice, service mesh → domains/architecture/cloud-native.md注入期skill-router.js 作为UserPromptSubmit钩子在每次用户输入时运行命中关键词后读取秘典文件的前 120 行作为「领域知识」注入上下文并遵循该文档自带的权威性原则——当技能文件与训练数据冲突时以技能文件为准禁止凭训练记忆捏造领域知识。也就是说当开发者或 CCG 编排的任意模型在会话中提到容器DockerK8sServerless等词汇时系统会自动取出下面这份云原生实战手册作为推理依据。以下各节即该文档正文的完整展开与源码级解读。二、Docker从多阶段构建到运行时加固2.1 多阶段构建 Dockerfile原文档给出的 Node.js 多阶段构建示例是全流程的黄金范本# 多阶段构建 FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM node:18-alpine WORKDIR /app COPY --frombuilder /app/dist ./dist COPY --frombuilder /app/node_modules ./node_modules EXPOSE 3000 USER node CMD [node, dist/main.js]逐指令拆解其设计意图阶段一builder基于node:18-alpinenpm ci依据package-lock.json做确定性安装比npm install更严格、可复现随后执行npm run build产出编译产物。这一阶段携带完整的构建工具链与源码阶段二runtime重新从node:18-alpine起步只把构建产物dist/与已安装的node_modules/通过COPY --frombuilder拷入源码与构建工具链全部丢弃。最终镜像只含运行所需内容体积大幅缩小USER node切换为非 root 用户运行避免容器内进程以特权身份操作文件系统CMD [node, dist/main.js]以 exec 形式JSON 数组声明默认启动命令可被docker run追加参数覆盖。alpine 基础镜像的选择与运行时非 root 化正好呼应了该文档安全最佳实践一节中最小化镜像 非 root 运行的要求两者互为印证。2.2 Docker Compose服务编排与健康检查原文档的 Compose 清单覆盖了本地多服务编排的核心要素version: 3.8 services: app: build: . ports: - 3000:3000 environment: - DATABASE_URLpostgres://db:5432/mydb depends_on: - db healthcheck: test: [CMD, curl, -f, http://localhost:3000/health] interval: 30s timeout: 10s retries: 3 db: image: postgres:15-alpine volumes: - postgres_data:/var/lib/postgresql/data environment: POSTGRES_DB: mydb POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: postgres_data:参数含义与取值说明depends_on声明app依赖db先启动注意它只控制启动顺序不保证数据库已就绪生产级等待仍需配合 healthcheck 或 entrypoint 重试healthcheckinterval为两次检查间隔30s、timeout为单次检查超时10s、retries为连续失败多少次判定不健康3 次。curl -f表示 HTTP 返回非 2xx/3xx 即判失败目标端点/health需要应用自身实现volumespostgres_data是命名卷数据持久化在宿主机由 Docker 托管的位置容器重建不丢数据${DB_PASSWORD}从宿主机环境变量读取敏感值避免把密码硬编码进docker-compose.yml可配合.env文件使用。2.3 容器安全最佳实践原文档用两段清单给出了镜像侧与运行时侧的安全基线镜像安全: - 使用官方基础镜像 - 最小化镜像 (alpine/distroless) - 扫描漏洞 (Trivy) - 固定版本标签 运行时安全: - 非 root 用户运行 - 只读文件系统 - 限制资源 - 禁用特权模式实践要点补充官方基础镜像 固定版本标签node:18-alpine、postgres:15-alpine这类写法把基础镜像锁定到具体大版本避免latest漂移导致的不可复现构建更进一步可固定到完整 digestTrivy 漏洞扫描建议纳入 CI 门禁trivy image --severity HIGH,CRITICAL image即可扫描镜像层中的已知漏洞只读文件系统运行时挂载为只读如 KubernetesreadOnlyRootFilesystem: true把写路径收敛到显式挂载的卷可显著压缩被攻破后的破坏半径禁用特权模式privileged: true会赋予容器宿主级能力默认应关闭确有需要时改用最小化的 capabilities 白名单。三、Kubernetes从部署编排到安全准入3.1 基础资源三件套Deployment Service Ingress原文档用一个三段式 YAML 完整演示了应用暴露到公网的标准链路# Deployment apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: myapp:1.0.0 ports: - containerPort: 3000 resources: requests: memory: 128Mi cpu: 100m limits: memory: 256Mi cpu: 200m livenessProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 3000 initialDelaySeconds: 5 periodSeconds: 5 --- # Service apiVersion: v1 kind: Service metadata: name: myapp spec: selector: app: myapp ports: - port: 80 targetPort: 3000 type: ClusterIP --- # Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myapp annotations: nginx.ingress.kubernetes.io/ssl-redirect: true spec: tls: - hosts: - myapp.example.com secretName: myapp-tls rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp port: number: 80逐层解读Deploymentapps/v1replicas: 3声明期望副本数selector.matchLabels必须与template中的 labels 匹配二者是控制器管理 Pod 集合的契约。资源部分requests128Mi / 100m是调度与预留依据limits256Mi / 200m是硬性上限配置 ratiolimit ≈ 2× request是常见经验值。livenessProbe判定进程是否还活着失败则重启容器readinessProbe判定能否接收流量失败则从 Service 端点摘除——/health与/ready建议由应用区分实现Servicev1type: ClusterIP提供集群内稳定 DNS 与虚拟 IPport: 80是服务端口targetPort: 3000转发到容器端口Ingressnetworking.k8s.io/v1pathType: Prefix按路径前缀路由v1 API 中必须显式声明tls.secretName指向保存证书的 Secretnginx.ingress.kubernetes.io/ssl-redirect: true由 NGINX Ingress Controller 强制 HTTP→HTTPS 跳转。3.2 配置管理ConfigMap 与 Secret# ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: myapp-config data: APP_ENV: production LOG_LEVEL: info --- # Secret apiVersion: v1 kind: Secret metadata: name: myapp-secret type: Opaque stringData: DATABASE_URL: postgres://user:passdb:5432/mydb使用要点ConfigMap存放非敏感配置环境标识、日志级别data是明文键值对可整卷挂载或映射为环境变量Secret的type: Opaque表示任意键值数据示例使用stringData明文书写以便阅读实际写入 etcd 时会被 base64 编码——注意这不是加密生产环境应开启 etcd 加密、优先使用云厂商 KMS 或外部密钥管理如 Vault对 Secret 做加密托管两者结合可让同一份 Deployment 清单在不同环境dev/staging/prod复用只需替换 ConfigMap 与 Secret 内容。3.3 安全策略NetworkPolicy 与 Pod Security Admission原文档的示例精准区分了已废弃与现行两种安全机制# NetworkPolicy apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: myapp-network-policy spec: podSelector: matchLabels: app: myapp policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: frontend ports: - port: 3000 egress: - to: - podSelector: matchLabels: app: database ports: - port: 5432 --- # PodSecurityPolicy (已废弃使用 Pod Security Standards) # Pod Security Admission apiVersion: v1 kind: Namespace metadata: name: myapp labels: pod-security.kubernetes.io/enforce: restricted解读与落地建议NetworkPolicy是 K8s 的微防火墙podSelector选中受控 Podapp: myapppolicyTypes: [Ingress, Egress]同时约束出入向。示例的语义是只允许app: frontend的 Pod 访问 3000 端口app: myapp只能出向访问app: database的 5432 端口。注意 NetworkPolicy 需由 CNI 插件Calico/Cilium 等强制执行默认 deny 一切未显式允许的流量是推荐基线PodSecurityPolicyPSP已在 Kubernetes v1.21 弃用、v1.25 移除接替者是内置于 API 服务器的Pod Security AdmissionPSA。示例通过对 Namespace 打标签pod-security.kubernetes.io/enforce: restricted启用最严格的 Pod 安全标准restricted 级别要求禁用特权容器、以非 root 运行、只读根文件系统、capabilities 受限等任何不满足该标准的 Pod 将被准入控制器拒绝。四、Serverless函数即服务4.1 AWS Lambda 函数处理器import json def handler(event, context): body json.loads(event.get(body, {})) return { statusCode: 200, headers: {Content-Type: application/json}, body: json.dumps({message: Hello!}) }要点说明handler(event, context)是 Lambda 的入口签名event携带触发事件负载HTTP API 场景下body为 JSON 字符串context提供运行时信息函数名、剩余执行时间等event.get(body, {})对缺失 body 做了默认兜底避免空负载导致json.loads抛错返回值是 API Gateway 约定的响应结构statusCodeheadersbody序列化后的 JSON 字符串。4.2 Serverless Framework 部署配置service: myapp provider: name: aws runtime: python3.9 region: us-east-1 environment: TABLE_NAME: ${self:service}-${sls:stage} functions: hello: handler: handler.hello events: - http: path: /hello method: get process: handler: handler.process events: - sqs: arn: !GetAtt MyQueue.Arn resources: Resources: MyQueue: Type: AWS::SQS::Queue参数与语法说明providerruntime: python3.9指定函数运行环境region指定部署区域environment定义注入所有函数的全局环境变量变量插值${self:service}引用本服务名、${sls:stage}引用部署阶段TABLE_NAME据此生成服务名-阶段名形式的动态表名天然支持多环境隔离functions每个函数由handler文件.函数名与events触发器定义。http事件创建 API Gateway 路由GET /hellosqs事件把函数绑定到消息队列!GetAtt MyQueue.Arn是 CloudFormation 内建函数自动引用下方 resources 中 SQS 队列的 ARN——这正是函数代码 基础设施即代码一体化的典型写法。五、微服务模式分布式系统的四大支柱原文档以清单形式给出了微服务治理的完整知识点这里逐一展开服务发现: - DNS (Kubernetes Service) - Service Mesh (Istio) 负载均衡: - 客户端负载均衡 - 服务端负载均衡 熔断器: - Circuit Breaker - Retry with backoff - Timeout 可观测性: - 日志聚合 (ELK) - 指标监控 (Prometheus) - 分布式追踪 (Jaeger)服务发现Kubernetes 内置 DNS 方案service.namespace.svc.cluster.local是零额外成本的集群内发现方式Istio 等 Service Mesh 则在数据面之上提供更丰富的流量治理与 mTLS 能力负载均衡客户端负载均衡如 gRPC 的 resolver、Spring Cloud LoadBalancer由调用方自行选择实例服务端负载均衡由集群代理Kube-proxy、Ingress Controller或网格边车统一分发熔断与容错Circuit Breaker如 Sentinel、Resilience4j、Istio Outlier Detection在依赖连续失败时快速失败以保护自身Retry with backoff 用指数退避避免重试风暴Timeout 防止请求无限挂起拖垮线程池。三者常组合使用重试需配合超时上限与熔断阈值可观测性三支柱ELKElasticsearch Logstash Kibana聚合检索日志Prometheus 采集指标并提供告警Jaeger 做跨服务分布式追踪——三者分别回答发生了什么、系统状态如何、一次请求经历了什么。六、在 CCG Workflow 中的实际使用方式6.1 如何触发这份秘典当你或 CCG 编排的模型的输入命中以下任一关键词时skill-router.js 会自动注入本秘典内容kubernetes、docker、k8s、微服务、service mesh、cloud native路由表同时覆盖中英文注入机制为读取秘典文件前 120 行放入UserPromptSubmit上下文超出部分截断并提示完整路径且遵循 ccg-skill-routing.md 的规则先读技能文件再作答技能文件存在时不得凭训练数据捏造领域知识。这意味着文中的 YAML 与代码模板会被模型直接作为可复制、可运行的权威依据来使用。6.2 安装与更新该秘典随 CCG 技能树默认安装security 领域因杀软误报被排除architecture 领域不受影响npx ccg-workflow # 初始化将 templates/skills/ 复制到 ~/.claude/skills/ccg/ npx ccg-workflow update # 更新技能文件安装后路径为~/.claude/skills/ccg/domains/architecture/cloud-native.md。从 skill-registry.ts 的实现看它没有scripts/目录、user-invocable为 false因此被归类为 knowledge 型技能不生成独立斜杠命令只作为被动注入的知识源——这也解释了为什么命令列表始终清爽、而领域知识却能按需涌现。6.3 仓库内可继续深入的内容云原生秘典原文cloud-native.md架构领域索引architecture/SKILL.md能力矩阵含 api-design / security-arch / message-queue / caching关键词自动路由规则ccg-skill-routing.md钩子注入实现skill-router.js技能发现与命令生成skill-registry.ts技能安装管线installer.tsinstallSkillFiles()于第 391 行起模板总览templates/CLAUDE.md10 大领域秘典章节结语这份云原生架构秘典的独特价值在于它不是一份孤立的技术文档而是被 CCG 的钩子、路由规则与技能注册表串联起来的运行时知识库——模型在涉及容器、Kubernetes、Serverless 与微服务治理的对话中会自动取用它且一切以文件内容为权威。对开发者而言文中每段配置都可以直接作为生产模板的起点多阶段构建控制镜像体积、健康检查与资源限制保障运行时韧性、NetworkPolicy 与 Pod Security Admission 构成纵深防线、Serverless 配置实现基础设施即代码而熔断、重试、超时与可观测性四件套则是任何微服务系统的必备骨架。赞分享【免费下载链接】ccg-workflow多模型协作工作流引擎 — /ccg:go 一个命令AI 自动分析意图、选择策略、编排 Codex Gemini Claude 协作执行项目地址https://gitcode.com/gh_mirrors/cc/ccg-workflow点击查看免费下载相关推荐ccg-workflow 云原生架构实战指南从容器化、Kubernetes 到 Serverless 与微服务模式ccg workflow 云原生架构实战指南从容器化、Kubernetes 到 Serverless 与微服务模式 本篇技术指南以 ccg workflow人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCesiumJS云计算云原生架构、Serverless与微服务CesiumJS云计算云原生架构、Serverless与微服务 引言地理空间计算的云原生革命 在数字化转型浪潮中地理空间数据可视化正面临前所未有的挑战。传前端3D渲染图形学数据可视化GitButler云原生架构微服务和Serverless部署GitButler云原生架构微服务和Serverless部署 引言从桌面应用到云原生演进 你是否曾想过一个专注于Git分支管理的桌面应用如何拥抱云原生时代开发工具版本控制CLI上一篇终极Steam挂卡工具Idle Master完整指南轻松获取交易卡提升Steam等级下一篇BepInEx 6.0架构深度解析Unity插件框架的多运行时支持与IL2CPP兼容性破解方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考