前端项目容器化部署和纯静态资源部署的实战心得(稀土掘金技术社区2024年08月02日文章)

分享到：

作者：稀土掘金技术社区 | 更新时间：2024-08-06 11:35:52

点击公众关注号，“技术干货”及时达！「本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！」关于前端项目部署方式，我也是实战经历了「纯静态资源上传服务器」和「容器化部署」这两种方式，算是有一点自己的心得...

A股板块轮动加剧，跨年大妖来袭，这几只票主力已明显介入！微信搜索关注【研讯小组】公众号（可长按复制），回复666，领取代码！

点击公众关注号，“技术干货”及时达！

「本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！」

关于前端项目部署方式，我也是实战经历了「纯静态资源上传服务器」和「容器化部署」这两种方式，算是有一点自己的心得和体会。本文会通过他们之间的异同、各自的特点，和实战中的一些个人心得来进行分享。

前文回顾

一年前写了一个关于前端发布平台的专栏，里面有介绍一个通过 Jenkins + Node + React 实现的一个前端发布平台，其包括了前端项目自动化 CI/CD 的全实现过程，感兴趣的老铁可以回过头去看看。这里，我重新贴回之前的前端项目发布的概览流程图如下：

回看之前的流程中可以发现，之前的 CD 流程其实并不涉及“容器化”的内容，其只是通过 rsync 的方式将打包好的产物上传到一个“文件服务器”的地方，从而就是整个 CD 的实现了。关于整个文件服务器，大家可以不必纠结是什么，它可以是一个 nginx、apache 或者其他，反正就是一个 web 的静态资源服务器就是了。

讲到这里，你也许会有疑问，前端项目无非就是静态资源，上述流程中的 CD 已经能满足生产的需求了，为什么还需要容器化部署呢？或者说容器化部署有什么优势呢？

再者，前端项目并不像服务端等项目，有各种依赖的环境，而这种环境依赖情况下容器化部署对于机器迁移、换云商部署等操作都比较方便...但前端项目就是静态资源，就是文件，涉及迁移之类的东西，粗暴的复制粘贴也不是不行...那容器化的一大优势对于前端项目来说也变得不是那么重要了...

作为我个人而言，我会这么告诉你，两种部署方式「本质上可以说没有任何区别」，都是“一台web服务器”，“一堆静态资源文件”而已。如果硬是要说区别，那就是“放权”与否的区别了。说白了，静态资源上传到文件服务器，这个文件服务器大概率是掌握在运维同学手里的。里面的配置怎么样的，对于前端同学可能就是黑盒了。而容器化部署，前端同学就有机会在自己的容器中配置自己的 nginx，可以更自由地决定一些 nginx 的行为，在更自由的前提下，也多了一部分的 nginx 配置、管理、维护工作~

❝
因为我所经历的团队是全部前端项目都是通过 rsync 方式上传到一个服务器上的，所以我这里就当上传静态资源的CD方式是上传到一个服务器上的。大家不必细抠这一个点～
❞

另外讲点题外话，在目前「单页应用」和「前端首屏加载」优化的背景下，相信绝大部分项目都采用了资源按需加载的打包策略，也就是很多文件是异步加载的。如react lazy、webpack 的 import()等，都是针对这种场景而生的。而前端项目容器化部署时，在「发布新版本」就不可避免的会遇到：“用户在已打开的网页，在未刷新的情况下出现资源404的情况”。当然这个问题是可以解决的，我会另外写一篇文章来分享，不过我相信，那时候你能更加体会到我为什么说这两种CD方式本质上没有区别了。

扯得有点远了，接下来，我接着来带大家看看我实战中二者发布之间的一些区别，以及我对这两种 CD 方式的一些实战心得体会，let's go。

部署方式的区别

这里，我就只针对 CD 的过程来展开，前端项目构建阶段，我们就暂且当他是透明的先。又因为现在流行的CI/CD工具 gitlab ci、jenkins 等各式各样的都有，所以我也不局限在工具层面，对于整个 CI 阶段，我统一用“「打包机」”来作为代表概括，也就是说本文的打包机直接输出产物 dist。

首先我们先看下概览图：

上图中，打包机跑完 CI 流程得到产物后，通过两种方式进行了前端项目的部署。

「直传服务器」。直接将产物文件上传到文件服务器，也就是源站
「打包镜像」。基于 Dockerfile 打包镜像，COPY 产物到镜像路径中（Nginx配置好的），再到 K8s 中重启对应容器

这么一看，容器化部署的流程看似比较繁琐，涉及了 Dockerfile 编写、镜像打包、容器重启等步骤。但其实，最终效果跟上传服务器步骤是一样的，也是把静态资源放到对应的服务器中。不过因为不同团队的基建设施不一样，所以接下来的具体区别，我「仅以个人经历展开」，因此并不能涵盖所有场景。

直传服务器

这种场景下，「所有前端项目」的发布都是将打包好的资源上传到对应服务器的对应地方，而至于服务器那一层等对于前端团队来说是比较黑盒的，因为这一层主要是运维同学在维护的。

对于这种场景而言，前端团队的工作量其实就比较单一了，只要把资源上传到对应的地方，剩下的就交给运维同学了。以至于外部流量访问进来，怎么加载对应的资源，这一层的配置就是运维同学在捣鼓的了，前端同学完全不用关注。

不过这种情况，在前端团队所需承担的工作量变小的时候，往往也带来了些许的不便。比如说前端同学就「无法介入到一些服务器」的配置了，如 CORS、gzip，还有具体到业务应用内的一些接口转发的配置。可能有些同学会觉得这种服务器配置跟前端没啥关系，但往往我们在一些优化场景如「前端资源缓存策略」上，作为前端开发来说对此确实是有一点职责的。

当然，从个人经历来说，这种模式还有一个问题就是查日志不太方便。企业内一般都有“单点登录”的体系，这种登录中，往往会因为各种业务需求、各团队的要求等情况下而增加很多层上下游服务（登录一次就跳来跳去的）。因此，有时候遇到一些登录类问题，往往需要通过日志查看来定位问题。但前端同学如果要查日志，就要想办法登录到机器中，或者直接找到运维大佬们（日志基建很完善，有各种可视化平台捞日志来展示的话当我没说～

如同上图所示，前端小佬需要对任何关于前端项目的一些服务器配置、操作，中间都隔了一层运维大佬。如果权限管得松一点，可以通过堡垒机等登录机器的话，也还好说，如果没有，那就只能很多时候找对应的运维大佬来协助了。

简单总结一下，如果前端项目发布时是直传服务器的，那么大概率服务器层面对于前端团队来说就是黑盒，前端团队的权限范围也相应更小，服务器层都是其他团队的在负责。在一些场景需要对服务器做一些配置的时候，如配置 CORS 相关的 header、配置静态资源的一些缓存策略等等，都需要将其以需求的形式给到对应的团队，由其来配合我们进行服务器配置。

容器化部署

对于我个人经历，将所有前端项目都上传到一个文件服务器的CD方式，对应到容器化部署时，就可以细化到一个一个项目各自放到各自的服务器上了。

相应的，相比于静态资源直传服务器，容器化部署的话对于前端团队的工作量和要求就更多了，同时前端团队所拥有的「权限」也就更大了。换句话说，比起上述部署方式，这种方式更像是有点“放权”给到前端团队的感觉。

既然要到容器化部署，那相应的容器化部署一些基本知识我们还是得大概知晓一些的。就拿我们要在 aws 的 k8s 集群中部署项目为例，大概讲一下一个基本的项目部署到最终的一个流量访问进入流程吧。

首先来看看项目部署流程（比较熟悉 k8s 那一套的同学可以跳过这一节了

假设现在已经通过 kubectlconfig 连到对应的 k8s 集群了，整个部署准备环节如下图所示：

当我们配置好 ns、quota、deploy、service、ingress，基本上整个流量进入的事情就跑通了。最终只需要将域名解析到对应的 ingress/alb 上，就能正常的访问到对应的 pod 中，也就是我们通过镜像启动的容器了。

不是很了解 k8s 的同学也不要觉得困惑，只需要知道流量进入到对应的 ingress 层后，最终会到自己启动的web服务器的 pod 上就行了。

往简单的说，如果前文中的直传服务器的 CD 方式的机器也是部在这套 aws 下的话，那其实就是我们通过 rsync 上传资源到对应 pod 中的服务器上而已。我简单画了个图给大家参考：

直传服务器。图中绿色的途径，过程很简单，直接把静态资源传到对应的服务器上就完事了。
容器部署。图中蓝色的途径。相比之下这一步需要构建镜像（依赖 Nginx），将 Image 上传到对应的仓库，并且重启容器。重启 deploy 时，便会到镜像仓库中拉新镜像，然后用新镜像重启容器，如启动对应的 Nginx 服务器。

其实两种前端项目的部署方式，最终的归宿就是文章开头所说的：一个web服务器、一堆静态资源。只是说容器化部署前端项目时，我们可以自己定制容器，自己决定使用什么服务器、怎么配置服务器、怎么启动服务器。也就是我们对静态资源的管控权利更大了，也可以自行决定接口的反向代理行为了（狗头。接下来我放一个 Dockerfile 伪代码，大家可能更清晰了：

FROMxxx.xxx.com/nginx:release COPY./dist//xxx/xxx/nginx/html/ CMD["/bin/bash","-c","nginx-g'daemonoff;'"]

这个 Dockerfile 很简单，就三行。其中依赖一个 nginx 的基础镜像，将打包机的产物 dist 复制到对应 nginx/html 路径中，然后设置了一个 nginx 的启动命令。最终 deploy 重启时，便会运行这个 nginx 的启动命令，然后启动一个 nginx 的服务。

关于 Nginx 的配置怎么加载，我相信不同团队、个人都会有不同的方式，只要能实现就行，所以我也不会涉及太多。按照我目前的经历，主要是将 nginx 的配置通过 ConfigMap 挂载到对应的容器中，不过也有一些比较基础的配置会写到对应的配置文件中，在 Dockerfile 中通过 COPY 的形式放到对应路径下的也有...

简单总结一下，虽然容器化部署需要稍微多了解一点容器、k8s的知识、nginx等服务器的知识，但其实整套流程下来也并不是复杂，镜像打包、上传镜像仓库、重启容器等操作，其实只要跑通一次这个流程就能拿下了。不过容器化部署更多的是给对应的开发人员提供了更大的权限，很多服务器的配置都下放到前端团队中了。前端同学可以更自由的配置、管理自己的静态资源，设置CORS头、配置gzip、配置接口的反向代理等等...

总结

单从字眼上看，两种部署方式看似差异很大，其实本质趋同。在我还没有实战过容器化部署的时候，我也一直有个疑问关于为什么前端项目要容器化部署，包括在一些面试中也有被问过怎么看待前端项目容器化部署这件事。现在自己实战过两种部署方式后，感觉可以更全面的来谈谈容器化部署了。

对我个人经历而言，前端项目容器化部署时，往往都需要关注更多技术、工具，如 k8s、nginx这类web服务器的配置等。也就是说运维团队只给你提供最基本的容器基建、dns解析，至于你Dockerfile、nginx、ingress配置这些，你想怎么搞就怎么搞。甚至如果基建还不是很完善的时，还需要自己通过 kubectl 命令行的刀耕火种的方式去部署项目。

而如果是静态资源上传的部署时，往往服务器已经给你准备好了，你不需要关注是虚拟机、还是容器，是aws还是阿里云，甚至你都不需要知道对应的 web服务器中的配置是怎么样的，有怎么样的http缓存策略。在这种情况下，你每次部署项目，都只需要上传文件到服务器的对应路径就搞定了。

但最终，两种方式的背后，你会发现其实前端部署就是两件事：web服务器和静态资源。容器化部署的时候，你大概率可以自己掌控对应的 web服务器，而上传静态资源的部署方式，服务器层面对你来说大概率是一个黑盒。

本文开头有提到容器化部署的一个问题，那便是容器重启后会丢掉已有的静态资源，导致已经打开页面的用户（单页应用），在没有刷新的情况下继续操作界面，会出现一些资源 404 的问题。这一点相信是每一个用过容器化部署的同学都会遇到的，当然解决方案一定就是将资源持久化存储，那这一步要怎么实现呢，等我下一篇分享吧～