在上一期，我们介绍了星云私有化部署整体方案。今天，我们将继续深入探讨星云私有化部署落地方案，重点讲解前端部分的部署方案，包括前端代码和 Nginx 的配置与实现。

方案架构

本方案的核心是将 Nginx 和前端资源打包到一个名为 custom_nginx_all 的镜像中，然后将该镜像推送至客户服务器（可以直接从镜像仓库拉取，也可以通过线下方式复制）。接着，客户使用 docker-nginx-compose.yml 文件创建并启动 Nginx 容器。具体部署流程如下图所示：

步骤一：生成包含 Nginx 和前端资源的 custom_nginx_all 镜像

（1）前端服务部署 Job：该 Job 负责将前端源码进行编译打包，并将打包后的文件存放到 Jenkins 服务器的指定目录。

（2）生成 custom_nginx_all 镜像的 Job：该 Job 会从 GitLab 拉取最新的 Nginx 配置文件到 Jenkins 服务器，并将已打包的前端文件与 Nginx 配置文件一同打包，生成 custom_nginx_all 镜像。

步骤二：将 custom_nginx_all 镜像放到客户服务器

在部署时，客户可以直接从镜像仓库拉取 custom_nginx_all 镜像到本地服务器，或通过线下方式将镜像传输到客户服务器。

步骤三：基于 custom_nginx_all 镜像创建 Nginx 服务并启动

通过执行 nginx-compose.yml，结合已经配置好的全局变量文件（.env），生成 custom_nginx_all 容器并启动 Nginx 服务。

备注：.env 文件将在后续的 Nginx 方案中详细介绍。

Nginx部署方案

在私有化部署中，通常会涉及到一些特定于客户环境的变量，例如域名、IP 地址、端口和 SSL 证书路径等。为了确保镜像的通用性和灵活性，我们采用配置文件模板化的方法，将这些变量化，并在创建 Docker 实例时动态注入具体的值，从而使得 Nginx 配置能够适应不同的环境。

（1）配置文件模板化

在打包镜像时，我们将 Nginx 配置文件进行模板化处理。具体来说，配置文件中的域名、端口、证书路径等信息使用占位符变量表示，如 ${domain}、${port}、${ssl_path} 等。这样做的目的是确保生成的 Docker 镜像具备通用性，可以在任何私有化环境中使用，而无需修改镜像本身。下图是一个模板示例。

（2）变量实例化。

为了确保配置文件中的变量能够根据实际部署环境灵活调整，我们在自己的仓库中以 key-value 的形式维护这些变量。私有化部署时，客户只需将保存所有变量的文件复制到目标服务器上，并根据实际情况填写具体的变量值。

（2.1）变量管理：所有的变量（如域名、端口、证书路径等）都以 key-value 对的形式保存在一个配置文件中，这样可以集中管理、统一修改。如下图所示，包含所有需要填充的变量及其默认值或占位符：

（2.2）配置文件具体化：在私有化部署时，客户只需将该变量文件复制到服务器上，并根据实际部署环境填入相应的值。例如，客户可以为 ${domain} 变量填入自己的域名，或者为 ${ssl_path} 填写 SSL 证书路径。如下图所示，客户根据实际环境填写了具体的变量值，确保配置文件与私有化部署的环境匹配：

（3）创建Nginx容器的时候，注入变量，完成nginx启动。

在部署过程中，通过 docker-compose 配置中的 env_file 选项，将变量文件与镜像关联。在创建容器时，docker-compose 会自动将变量文件中的具体值注入到 Nginx 配置中，从而生成一个可执行的、已经具体化的 Nginx 配置。完成配置注入后，容器会启动并运行 Nginx 服务。

（3.1）通过 env_file 注入变量：在 docker-compose.yml 中，我们使用 env_file 选项将保存变量的文件与镜像关联。这样，docker-compose 在启动容器时，会根据 .env 文件中的变量值替换配置文件中的占位符，确保 Nginx 配置的动态适应性。如下图所示，包含了 env_file 和其他容器配置。：

（3.2）具体化的 Nginx 配置:在变量文件中的占位符（如 ${domain}、${port} 等）会在容器启动时被实际的值所替换。此时，Nginx 配置文件已经变成了一个具体的、可执行的配置，能够在实际的生产环境中正确运行。如下图所示，经过变量注入后的实际配置文件，已经准备好用于私有化环境：

（4）Nginx配置版本维护。

为了确保每次私有化部署包的版本与相应的 Nginx 配置一致，我们在每次制作私有化包时，同时为 Nginx 配置仓库也打上该私有化版本标签（tag），例如M3.2.15。这样做可以确保该版本中的所有内容（包括镜像和配置文件）同整个私有化版本中的前端、后端、数据库等等都是配套的，避免因版本不匹配而导致的潜在问题。

前端部署方案

（1）前端打包。

由于所有前端服务与 Nginx 服务是打包成同一个 Docker 镜像，因此前端服务并不独立发布。整个前端服务会进行统一的编译打包，所有打包后的文件最终存放在 Jenkins 服务器的指定目录中。然后，将这些打包文件与 Nginx 服务镜像和配置文件一起打包成一个名为 custom_nginx_all 的 Docker 镜像。这样，Nginx 和前端资源在同一镜像中，确保了部署过程的简洁性与一致性。

（2）版本维护。

为了确保所有前端服务版本的一致性，我们对所有前端服务的代码仓库进行版本管理。在每次制作 Milestone 时，我们为各个前端服务打上统一的版本标签（tag），例如M3.2.15。然后，Jenkins 根据该标签进行前端服务的部署。这样可以确保在每个版本中，前端服务与 Nginx 配置和镜像始终配套，避免出现版本不匹配的情况，保证整个私有化部署包的稳定性与一致性。

总结

本文从方案架构、Nginx 部署方案和前端部署方案三个方面，详细介绍了 Web 服务（包括前端和 Nginx）的私有化部署实现方案。通过这套标准化的打包、部署和版本维护规范，我们能够更加高效、便捷地实现前端服务的私有化部署。

随着2025年的临近，送给一直为理想和生活奋斗的朋友们一句话：“星光不问赶路人，时光不负有心人。2024，您辛苦了！”

我是维搭小刘，感谢您的阅读与支持。下篇文章，我们再见！