// tier: serverfactory-tertiary · order 33

Server Factory — Additional Components mixedlicense: UNVERIFIED

Kotlin (service factories, on Core Framework)Shell (Utils, Definitions packs)GradleDocker (target runtime)SSH / OpenSSH (Utils bootstrap)SonarQube

Source

Server Factory — Additional Components Family tree Data vs engine · bootstrap Maturity: solid = flagship (Mail) · dashed = early-stage service factories (UNVERIFIED) Core Framework Kotlin engine Mail Factory flagship Web Service Factory early-stage SonarQube Factory early-stage Caching-Proxy Factory early-stage Definitions packs Docker · Stack · Software Utils init_ssh_access.sh bootstrap
// architecture

Server Factory 配置工具链的辅助组件

除了 Mail Server Factory 与核心框架，Server-Factory 组织还包含多个较小的组件：针对各服务的"工厂"（Web 服务、SonarQube、缓存代理）、声明式配置包（Docker/Stack/软件定义）以及共享工具集（Utils）。本页面将它们整合呈现——其中不少仍处于早期阶段或仅有框架性文档——而非作为完整定义的成熟产品。

Server Factory 的一系列辅助代码库，包括：Web-Service-Factory、SonarQube-Factory 与 Caching-Proxy-Factory（针对各服务的配置工具，大多处于早期阶段）；Docker/Stack/Software-Definitions（由框架调用的声明式配置包）；以及 Utils（SSH 访问辅助工具与通用工具集）。所有组件均基于核心框架构建。

本页面将 Server-Factory 其余代码库整合展示，原因在于：单独来看，多数代码库规模较小或有意保持文档简略，若将其逐一介绍为成熟产品，则有夸大其成熟度之嫌。这些组件可分为三类。

服务工厂 遵循 Mail Server Factory 模式，适用于其他服务器角色：

  • Caching-Proxy-Factory（"运行你自己的缓存代理服务器"）列出了缓存代理、自签名证书及获取安全证书的 HTTP 端点等核心功能；
  • SonarQube-Factory（"运行你自己的 SonarQube 服务器"）面向软件开发场景；
  • Web-Service-Factory 则用于实例化并配置 Web 服务器，以部署网站或微服务等目标。

三者均为基于核心框架构建的 Kotlin 项目，但其公开 README 文档多为占位内容（如"兼容性""规格""设置""使用说明"等部分标注"待定"），因此其超出既定意图的具体能力尚未经验证。

定义包 包括 Docker-Definitions、Stack-Definitions 与 Software-Definitions，均为框架调用的声明式配置代码库，用于指导构建/部署 Docker 镜像、栈及软件。它们是版本固定的数据包，而非独立应用程序。

Utils 提供工具链家族的通用辅助工具，如 init_ssh_access.sh 脚本，该脚本可生成 SSH 密钥并安装至远程主机，以实现后续配置所需的无密码 root 访问。这些组件共同完善了围绕旗舰产品 Mail Server Factory 的配置工具链。

Server Factory 模型旨在实现通用化：既然能通过声明式描述配置邮件服务器，同一引擎理应能配置 Web 服务器、缓存代理乃至代码质量服务器——前提是由可复用的定义包和共享工具驱动，而非针对每种角色单独编写逻辑。这些代码库正是通用化进程的体现，将已验证的模式扩展至新服务器类型。其价值在于证明该模型的适用范围；成熟度各异，而本页面有意明确区分哪些尚处于方向性阶段，哪些已趋于完善。

内容

作为一个整体，这套方案展示了核心框架在不同服务器类型中的可复用性，并将声明式数据（定义）与执行逻辑（工厂）彻底解耦。单独来看，各服务工厂仍处于早期阶段，应视为方向性指引，而非成熟产品。

  • 单一配置框架横跨邮件/网页/缓存代理/SonarQube等多种角色。
  • 声明式定义包（Docker/Stack/Software）与执行引擎解耦。
  • 共享工具集（如一键式无密码SSH引导）在各工厂间复用。

  • 跨服务器角色复用同一引擎：通过基于核心框架构建各工厂解决。
  • 配置与代码分离：通过定义仓库作为版本固定的数据包实现。
  • （未验证）：服务工厂的README文档仅为占位内容，其完整性无法通过公开文档验证——应明确标注为早期阶段。

  • Kotlin —— Web服务工厂、SonarQube工厂、缓存代理工厂（基于核心框架构建）。
  • Shell —— 工具集及定义包（脚本/配置）。
  • Gradle —— ./gradlew test 跨工厂构建与测试流程。
  • Docker —— 由Docker-Definitions描述的目标运行时。
  • SSH / OpenSSH —— 工具集的无密码访问引导。
  • SonarQube —— SonarQube工厂配置的服务器（Mail Server Factory已针对其完成清洁门禁验证）。

诚实说明：多数仓库为组织内的分支；服务工厂文档为占位内容，依据章程§11.4.6标注为「未验证」。其重要性明显低于Mail Server Factory及核心框架。