企业官网建设流程全解析

本指南以 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 正是整套自动路由机制的数据源。其运行链路可以从仓库源码中完整还原：

1. 安装期：installer.ts 的installSkillFiles()会把templates/skills/整树递归复制到~/.claude/skills/ccg/，因此该文档最终落在~/.claude/skills/ccg/domains/architecture/cloud-native.md；
2. 发现期：skill-registry.ts 解析所有SKILL.md与秘典文件的 frontmatter，依据目录首段推断类别（domains→domain），依据是否存在scripts/*.js区分scripted与knowledge运行时类型——cloud-native 属于纯知识型（knowledge），user-invocable默认为false，不生成斜杠命令；
3. 路由期：ccg-skill-routing.md 定义了关键词映射表，其中一行明确写着cloud native, Kubernetes, Docker, microservice, service mesh → domains/architecture/cloud-native.md；
4. 注入期：skill-router.js 作为UserPromptSubmit钩子在每次用户输入时运行，命中关键词后读取秘典文件的前 120 行作为「领域知识」注入上下文，并遵循该文档自带的权威性原则——当技能文件与训练数据冲突时，以技能文件为准，禁止凭训练记忆捏造领域知识。

也就是说，当开发者（或 CCG 编排的任意模型）在会话中提到"容器""Docker""K8s""Serverless"等词汇时，系统会自动取出下面这份云原生实战手册作为推理依据。以下各节即该文档正文的完整展开与源码级解读。

二、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 --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules EXPOSE 3000 USER node CMD ["node", "dist/main.js"]

逐指令拆解其设计意图：

• 阶段一（builder）：基于node:18-alpine，npm ci依据package-lock.json做确定性安装（比npm install更严格、可复现），随后执行npm run build产出编译产物。这一阶段携带完整的构建工具链与源码；
• 阶段二（runtime）：重新从node:18-alpine起步，只把构建产物dist/与已安装的node_modules/通过COPY --from=builder拷入，源码与构建工具链全部丢弃。最终镜像只含运行所需内容，体积大幅缩小；
• 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_URL=postgres://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 重试；
• healthcheck：interval为两次检查间隔（30s）、timeout为单次检查超时（10s）、retries为连续失败多少次判定不健康（3 次）。curl -f表示 HTTP 返回非 2xx/3xx 即判失败，目标端点/health需要应用自身实现；
• volumes：postgres_data是命名卷，数据持久化在宿主机由 Docker 托管的位置，容器重建不丢数据；
• ${DB_PASSWORD}：从宿主机环境变量读取敏感值，避免把密码硬编码进docker-compose.yml，可配合.env文件使用。

2.3 容器安全最佳实践

原文档用两段清单给出了镜像侧与运行时侧的安全基线：

镜像安全: - 使用官方基础镜像 - 最小化镜像 (alpine/distroless) - 扫描漏洞 (Trivy) - 固定版本标签 运行时安全: - 非 root 用户运行 - 只读文件系统 - 限制资源 - 禁用特权模式

实践要点补充：

• 官方基础镜像 + 固定版本标签：node:18-alpine、postgres:15-alpine这类写法把基础镜像锁定到具体大版本，避免latest漂移导致的不可复现构建；更进一步可固定到完整 digest；
• Trivy 漏洞扫描：建议纳入 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

逐层解读：

• Deployment（apps/v1）：replicas: 3声明期望副本数；selector.matchLabels必须与template中的 labels 匹配，二者是控制器管理 Pod 集合的契约。资源部分requests（128Mi / 100m）是调度与预留依据，limits（256Mi / 200m）是硬性上限，配置 ratio（limit ≈ 2× request）是常见经验值。livenessProbe判定"进程是否还活着"，失败则重启容器；readinessProbe判定"能否接收流量"，失败则从 Service 端点摘除——/health与/ready建议由应用区分实现；
• Service（v1）：type: ClusterIP提供集群内稳定 DNS 与虚拟 IP；port: 80是服务端口，targetPort: 3000转发到容器端口；
• Ingress（networking.k8s.io/v1）：pathType: Prefix按路径前缀路由（v1 API 中必须显式声明）；tls.secretName指向保存证书的 Secret；nginx.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:pass@db: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选中受控 Pod（app: myapp），policyTypes: [Ingress, Egress]同时约束出入向。示例的语义是"只允许app: frontend的 Pod 访问 3000 端口；app: myapp只能出向访问app: database的 5432 端口"。注意 NetworkPolicy 需由 CNI 插件（Calico/Cilium 等）强制执行，默认 deny 一切未显式允许的流量是推荐基线；
• PodSecurityPolicy（PSP）已在 Kubernetes v1.21 弃用、v1.25 移除，接替者是内置于 API 服务器的Pod Security Admission（PSA）。示例通过对 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 约定的响应结构：statusCode+headers+body（序列化后的 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

参数与语法说明：

• provider：runtime: python3.9指定函数运行环境，region指定部署区域，environment定义注入所有函数的全局环境变量；
• 变量插值：${self:service}引用本服务名、${sls:stage}引用部署阶段，TABLE_NAME据此生成"服务名-阶段名"形式的动态表名，天然支持多环境隔离；
• functions：每个函数由handler（文件.函数名）与events（触发器）定义。http事件创建 API Gateway 路由GET /hello；sqs事件把函数绑定到消息队列，!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 防止请求无限挂起拖垮线程池。三者常组合使用（重试需配合超时上限与熔断阈值）；
• 可观测性三支柱：ELK（Elasticsearch + 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.ts（installSkillFiles()于第 391 行起）
• 模板总览：templates/CLAUDE.md（"10 大领域秘典"章节）

结语

这份云原生架构秘典的独特价值在于：它不是一份孤立的技术文档，而是被 CCG 的钩子、路由规则与技能注册表串联起来的"运行时知识库"——模型在涉及容器、Kubernetes、Serverless 与微服务治理的对话中会自动取用它，且一切以文件内容为权威。对开发者而言，文中每段配置都可以直接作为生产模板的起点：多阶段构建控制镜像体积、健康检查与资源限制保障运行时韧性、NetworkPolicy 与 Pod Security Admission 构成纵深防线、Serverless 配置实现基础设施即代码，而熔断、重试、超时与可观测性四件套则是任何微服务系统的必备骨架。