前端全栈之路 - 前端运维的血泪史 本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！ 前言这是本系列的第五篇文章，在之前专栏中，我们一路更新的全部都是跟技术相关的内容，那么本章我们轻松一点，跟大家聊一聊前端运维的一些有趣的事情，也是前端走向全栈的过程中可能会遇到的一些问题。 背景前端运维跟传统运维不太一样的地方在于，前端的更新迭代太快了，除了SSR、CSR、SSG之外还有各种不断推出的前端框架以及它们自己本身破坏性的版本迭代。 与后端需要长期保持稳定的运行环境（例如有些Java服务可能还是JDK8）不同的是，前端的构建脚本需要针对各个需求以及框架做不同的更改，比如前端自动化测试的需求需要使用无头浏览器来截图，此时就需要在对应的Docker镜像中安装Chrome以及中文字体库，这是传统后端运维没有接触过的东西。 如果需要运维来协助解决的话，除了他自己也要不断的学习之外，也需要前端同学预研给出确定的技术方案与需求才能完成目标。而且在大前端的概念的普及之后，APP端以及各种跨端框架出现，以及各个大厂推出的小程序或三方服务对接又是一个非常新奇的内容。 对于运维同学来说，搭建这样的Devops体系要学习的内容非常多，更新的频率也非常快，而且很多内容都是碎片化的，说实话虽然做程序员就是要不断地学习新的技术，但过程真的挺痛苦的。 前端运维是我随便取的，一般都是前端架构组或者基础组做这样的事情，只是我管服务器的工作也挺多的，顺便就叫这个调侃一下，不用在意也并非是新的概念。 场景复现我们做运维的，特别是做前端的运维维护最大的痛苦就是：每一次同学在服务器构建不成功的时候都会来找你，把日志都给你然后理直气壮的说，这个项目在我本地环境运行没问题，构建也没有问题，为什么在服务器构建不出来，你快给我解决一下，要上线了。 image.png做了这么久的运维，前端项目在服务器构建中出现的问题，我稍微总结可能有如下这些： 项目依赖或者幽灵依赖有升级，本地开发有*.lock文件存在，所以导致即使删除了node_modules，重新安装还是之前旧的版本，但是在服务器构建的时候一般不会上传或者读取*.lock导致安装的依赖版本不一致，出现引用方法异常导致构建失败的情况；与第一个问题类似，本地全局安装了一个依赖，但是没有放在package.json中，导致在服务器构建异常；本地的Node版本与服务器不一致，比如某些API只在18版本可用，但服务器一般只选择稳定版本14或者16，所以导致构建失败，这个时候可以选择新的镜像版本构建或者兼容低级的Node版本；有些项目会依赖一些特殊的服务比如Python等，这些三方软件在本地安装过了，但是服务器没有，所以构建也会异常，需要在构建脚本中判断是否安装此类三方软件。希望如果碰到类似问题的前端同学，可以先按照上面的自行解决一下，减轻点运维的负担，前端发版本速度又快又频繁，而且一般公司的运维资源都不会非常充分，所以肯定存在照顾不过来的时候，自己能解救自己是最好的也是最方便的。如果还有漏的或者其他奇怪的问题可以评论区留言讨论。 可能还有些其他奇奇怪怪的问题，但是大部分服务器构建项目失败确实与服务器本身关系不大，所以一般来说，只要注意避免出现上述的问题，不会在CI过程中出现异常。 因为我也属于前端出身，所以出现这些问题我可以帮忙看着解决掉，但是传统的运维他不可能懂前端开发的这些问题啊，这就可能造成了前端与运维之前的一些误会与小矛盾。 运维更关注构建过程的什么异常出现构建异常绝对跟服务器没关系那是不可能的，但大部分的异常都会出现在CD的过程中，所以运维更关心也能解决的是非项目本身代码编译的问题而是编译过程中的环境、服务器等问题： 权限相关：可能有些项目的构建脚本需要额外安装一些需要系统权限的工具，这个时候联系运维帮忙给予更高权限或者构建内置后的基础镜像；安全相关：使用了外部有漏洞的镜像，但是自己很难处理的话，或者某些接口（内部RPC、外部服务回调接口等）需要开启IP白名单，这些可以联系运维帮忙解决；服务器相关：如果有项目比如RN、APP构建需要高性能的服务器或者iOS需要Mac来构建的话，赶紧找运维解决，硬件才是第一生产力；数据库相关：对于某些服务需要数据库服务的项目，数据库的用户权限、内外网权限、数据库数据同步、备份等问题；集群部署相关：比如镜像同步失败、pod 资源不足等；image.png在All in Docker的方案中，我们可以借助Docker来保证服务器也就是生产环境的统一性，保证在部署在各个生产环境（dev、test、pre、prod）中的依赖以及相关的环境变量、三方软件等外界因素一致。 但是在开发环境中我们面临的问题会更多，比如每位同学的系统环境就可能不一致，有Windows、Mac以及不少神人使用的是Linux系统，更别说还有Node版本、三方依赖服务不一致以及各个开发环境所存在的各种缓存问题等等，所以很多时候遗留项目或者跨团队多人协作中解决环境依赖也是一个非常大的问题。 那么有没有好的方案将开发环境的依赖解决？ 这肯定也是有的，这是下一篇Docker系列的 【 Docker Remote Development】文章，大家可以关注下。 image.png总结从我的经验来看，如果公司并没有符合Node的业务，但是前端又想走向全栈的路线，最好的切入点就是Devops。 上文也提到了，前端的框架种类非常多，需要针对各种不同的框架构建做兼容，即使能够统一技术栈，还会存在跨端、小程序这种需要三方对接属于前端技术领域但是又偏开发体验后端的模块。 所以如果大家对Node感兴趣又想走全栈路线，不妨尝试一下搭建一个小型的Devops体系先，毕竟最熟悉需求、有能力开发以及需要的人都是同一个人（产品+研发+用户），怎么可能会做不好呢？ 写在最后最后祝各位在全栈的路上越走越远、越走越好，持续不多的学习才是程序员的立生之本也是兴趣所在。 后续大家可以持续关注【前端全栈之路】专栏，会持续更新前端视角能够接触到的全链路非前端的知识体系。当然在全栈体系中，肯定会有些技术深度不够的情况，如果有遇到讲解不够清楚或者个人理解有偏差的情况，大家可以留言指正，及时修改避免误导有需要的读者。 阅读原文