问题描述
在许多开发团队中，我们经常会遇到一个问题，即如何在部署和托管现代JavaScript网站时处理“构建时”的需求。我们使用许多基于React的Web应用程序，它们会“编译”成包含一些HTML、JavaScript和CSS文件的静态网站。然而，构建这些应用程序需要许多变量，用于启用/禁用功能标志、配置后端URL等。这意味着我们无法在传统意义上“构建”出一个二进制文件，然后在部署时应用配置文件，因为“构建”过程本身需要设置这些环境特定的变量。因此，我们只能在部署时进行“构建”。
目前，我们通过将所需的环境变量注入Docker容器，并运行类似以下的启动命令来解决这个问题：
npm build && nginx run
然而，这种方法存在一些缺点：
1. 构建过程的CPU和内存资源占用很大，相对于容器的运行时需求而言。这意味着我们需要为构建过程而不是运行时需求来调整容器的规模，这似乎不合理。
2. 构建失败难以“跟踪”。虽然我们可以在Kubernetes中使用健康检查，但如果构建过程需要2分钟，我们仍然需要等待3分钟（额外的1分钟用于安全性）才能开始测试容器的健康检查端点，以查看是否存活。
3. 部署可能需要很长时间：如果我们将Kubernetes配置为进行“串行”部署，它将启动每个Pod，并在“initialDelay”期间等待2-3分钟，然后再启动下一个Pod。这意味着如果将部署扩展到3-4个Pod，可能需要10分钟左右的部署时间。
这些情况都让我感觉很不理想。我非常希望听听社区是如何解决现代JavaScript Web应用程序的“部署时构建”的难题的。
我意识到对于Kubernetes，我们可以使用“init-container”来执行构建，在持久存储中放置构建产物，然后在启动期间，应用容器只需从持久存储中获取。然而，这仍然更像是“绕过”问题，而不是解决根本问题。
解决方案
在处理现代JavaScript Web应用程序的“构建时”需求时，有几种可能的解决方案。以下是其中两种较为常见的方法：
方案1：使用Jenkins进行构建和部署
- 使用Jenkins等持续集成工具，将Node.js项目构建为分发版本，并打包成Docker镜像。
- 设置一个Docker注册表，用于存储Jenkins生成的Docker镜像（该注册表需要从Kubernetes集群中访问）。
- 将环境变量移到Jenkins的机密存储或使用其他工具从外部Git仓库中收集和组合配置信息。
- 配置Jenkins Pipeline，实现持续交付流程：
- 开发人员按照GitFlow工作流完成代码，并合并到Release分支。
- Webhook触发Jenkins Pipeline：
- 阶段1：收集环境定义
- 阶段2：使用npm构建Node.js应用
- 阶段3：使用分发版本构建Nginx Docker镜像
- 阶段4：将Docker镜像推送到Docker注册表
- 阶段5：使用标准定义在Kubernetes中部署/更新服务
- 根据结果发送通知。
这种方法将构建和部署过程分离，充分利用了Jenkins的持续集成和持续交付功能。同时，Docker镜像的构建和推送可以与Kubernetes集群解耦，从而更好地控制部署的过程。
方案2：使用动态配置API
- 将前端配置和后端配置分离。前端配置可以在构建过程中进行，也可以在浏览器启动时通过请求特殊的配置REST API进行。
- 后端配置应保持固定，使用技术方式进行配置，但可以根据不同环境设置不同的URL、凭证等。
- 可以使用金丝雀发布（Canary Releases）来解决部分问题，将配置问题隔离开来。
- 这种方法将前端和后端的配置分开处理，通过动态配置API来解决构建和部署时的问题。同时，可以使用金丝雀发布来逐步引入新的配置，减少影响范围。
这两种方案各有优劣，具体选择取决于团队的技术栈和偏好。无论选择哪种方式，都需要将构建和部署过程分开，使整个流程更加灵活和可控。
请注意，以上解决方案可能会涉及不同的工具和流程，具体实施时需根据团队的实际情况进行调整。
结论
在处理现代JavaScript Web应用程序的“构建时”需求时，可以采取不同的策略来解决问题。根据团队的技术栈和需求，可以选择使用持续集成工具（如Jenkins）来实现构建和部署流程的自动化，或者使用动态配置API来分