前端之被包养就不要谈独立人格
简介: 如何建立自己的核心竞争力?
注意
写完了才发现,还有另一番问题,后续再更新一下(后面估计就不能白嫖免费看了)。
起因
将博客的前台由原本的服务器 node+pm2 部署替换成 docker+pm2 部署,然后遇到的一系列问题,先说说目前的大致部署流程:
- 执行 build.sh
- 判断是否已安装 pnpm,如果没有,则:npm i pnpm -g
- 安装依赖:pnpm i
- 构建:pnpm run build
- 执行 pm2.sh
- 判断是否已安装 pm2,如果没有,则:pnpm i pm2 -g
- 删除旧的 pm2 进程:
pm2 del nuxt-blog-client-null-3000
- 启动新的 pm2 进程:
pm2 start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
替换成 docker 部署后,希望的流程:
- 执行 build.sh
- docker build .
- Dockerfile
- FROM node:16.19.0
- RUN npm i pnpm -g
- RUN pnpm i
- RUN pnpm i pm2 -g
- RUN pnpm run build
- CMD sh “./pm2.sh”
- pm2.sh
- 启动 pm2 进程:
pm2 start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
- 启动 pm2 进程:
- 执行 docker.sh
- docker run -d -p 3000:3000 nuxt-blog-client-null-3000
first
docker 部署的流程,实践操作下来,整体没什么问题,遇到的第一个问题是docker build .
的时候,最后一步CMD sh "./pm2.sh"
出问题,并不是说他没有执行 pm2.sh,而是执行了 pm2.sh,但是执行完 pm2.sh 里的pm2 start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
后,直接退出容器了,然后网上查阅了一番后,找到了 pm2 官方文档的说法:https://pm2.keymetrics.io/docs/usage/docker-pm2-nodejs/#docker-integration,就是说用 pm2-runtime 替换 pm2。然后继续
second
修改 pm2.sh,改成:pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
然后重新执行 sh build.sh
和 sh docker.sh
,发现问题,报错:
╭─────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ ✖ Nuxt Fatal Error │
│ │
│ Error: No build files found in /nuxtporject/nuxt-blog-client/node_modules/ │
│ nuxt/bin/nuxt.js/.nuxt/dist/server. │
│ Use either `nuxt build` or `builder.build()` or start nuxt in development mode. │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────╯
third
既然 Dockerfile 的 CMD 只是执行 pm2.sh,而 pm2.sh 又只是执行了pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
,那么我能不能把 pm2.sh 里的pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
给放到 Dockerfile 的 CMD 里?直接修改:
CMD sh “./pm2.sh”
修改成:
CMD pm2-runtime start ‘./node_modules/nuxt/bin/nuxt.js’ --name nuxt-blog-client-null-3000 -i max – start
然后重新执行 sh build.sh
和 sh docker.sh
,结果仍然报错:
╭─────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ ✖ Nuxt Fatal Error │
│ │
│ Error: No build files found in /nuxtporject/nuxt-blog-client/node_modules/ │
│ nuxt/bin/nuxt.js/.nuxt/dist/server. │
│ Use either `nuxt build` or `builder.build()` or start nuxt in development mode. │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────╯
debug-1
根据报错信息:
╭─────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ ✖ Nuxt Fatal Error │
│ │
│ Error: No build files found in /nuxtporject/nuxt-blog-client/node_modules/ │
│ nuxt/bin/nuxt.js/.nuxt/dist/server. │
│ Use either `nuxt build` or `builder.build()` or start nuxt in development mode. │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────╯
一般这些报错信息都是字符串模板拼接的,因此直接全局搜关键词Nuxt Fatal Error
、No build files found in
、Use either
搜Nuxt Fatal Error
就搜到了:
给它加上 debugger:
debug-2
直接 vscode 开启 debug 模式:
因为是执行pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
报错的,因此我们在 debug 模式的终端执行pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i max -- start
启动后:
因为我们使用了 cluster 模式,并且使用了 max,因此可以看到调用堆栈里面开了 8 个线程(我的笔记本是 m1 处理器,8 核),其实只要看其中一个线程就可以了,其他的线程的堆栈信息其实是一样的,或者这里修改下命令,使用 1 个线程:pm2-runtime start './node_modules/nuxt/bin/nuxt.js' --name nuxt-blog-client-null-3000 -i 1 -- start
debug-3
启动后就可以看到只有一个线程了:
然后可以一个个的点开调用堆栈看看里面信息有没有用,没有用处的话,直接跳过:
可以看到这时候就有很多堆栈信息了,一个个点开看
图 a:
可以看到这里处理了 argv,但是看不了变量,直接在这里打上 debugger,重新 debug
图 b:
可以看到目前的 argv 是这样的(其实问题就是出在了这里),我们先取消这个 debugger,因为在图 a 里面可以看到 nuxt 和 getnuxt 调用栈,在看看那边是怎样的
图 c:
图 d:
在图 d 打一个 debugger,重新 debug:
图 e:
可以看到,到这一步的时候,核心的 rootDir 目录有问题,它应该是我们项目的跟目录,但是他现在确实根目录拼接上了/node_modules/nuxt/bin/nuxt.js
,其实问题就出在这一步附近,我们可以换成npm run start
启动看看,这样启动的话,他的 rootDir 就是项目根目录
图 f(为了减少干扰,我把打印去掉了,debugger 放到了 config 后面):
可以看到现在 rootDir 就是项目根目录,毫无疑问,就是 pm2-runtime 的时候,出了问题,其实可以继续 debugger 下去,但是根因是起点获取参数的时候出了问题,后面的步骤其实是不影响的(当然了,后面的步骤能确切的让你知道 rootDir 是根目录才是正确的),核心是找到起点位置
那么我们该如何解决?,答案是是使用配置文件:
可以看到,使用配置文件启动的话,没有问题。原因未知,但可以肯定是 pm2 处理的问题。
总结
现在可以解决了 docker+pm2 部署的问题了,但其实实际上并没有完全解决问题,使用命令行的方式运行 pm2-runtime 还是存在问题,我们只是换了一种方式来实现。我们其实还可以继续从 pm2 方面开始 debug,但这需要耗费非常多时间,并且即使我们找到了问题,也只是找到问题了,并不意味着自己有能力修复它(anyway,如果你肯耗费时间的话还是可行的),在这个找问题的过程中,如果你知道他内部的原理实现了,或许可以用一些巧妙的方法来做到不修改源码的情况下来达到你的需求。
如果你对一样东西不了解,最好去找最官方最权威的东西看。推荐有文档看文档,没文档?如果你有能力,直接上手源码。否则还是放弃这个东西吧。
ps: 虽然文章遇到的问题文档并没有说解决,但还是依旧推荐看文档!
为什么起这个标题?
文章描述的问题是一个前端的问题,而我是做前端工作的,我遇到了这个问题,按理说我应该要解决掉它,然后实际上我并没有(我只是解决了我业务上的问题),问题依旧存在。换句话说就是:因为前端,我得到了一份工作,拿到了工资,而我却没有给前端带来什么回报。
如果你看完文章了,你大概可以知道涉及东西很多, docker(docker 的问题其实也有,但是不是非常突出,文章里面我就略过了)、pm2、pm2-runtime、nuxt,而且我找问题过程中,基本从官方文档找不到解决方案,找到的基本都是 issue,并且都是用配置文件的,如果用命令行方式跑 pm2-runtime,会出问题,具体看:https://github.com/Unitech/pm2/issues/4576。
如果你是 pm2、nuxt 中的作者或者团队成员,那么可能不会遇到这个问题,或者遇到了也知道如何解决,遗憾的是我只是在用它们。换句话说,在接触过的前端方面,基本都是在用开源的东西(三大框架和各种新兴的框架、各种组件库、各种构建工具),根据自己的业务或者现有的基础继续堆代码而已。自己本身其实没有什么核心的竞争力,当然了少部分人会在某些细分领域深耕了许久,会取得一些成就,但是大多数前端都是平平无奇的吧。
为了不做底层的前端人,我做了很多自己的开源玩具:https://www.npmjs.com/~huangshuisheng,虽然没什么人用,但好在自己用,并且当作者的感觉除了为所欲为以外,还有的就是责任感(虽然没人用也要把用户和项目的后续兼容扩展考虑进去),以及在用别人东西遇到问题或者 bug 的时候,懂的换位思考(有能力你可以自己写,不用别人的。别人的免费开源的东西,人家有个 readme 或者文档已经是仁尽义尽。)
怎么才能不被前端包养?
这点说实在的非常难,前端涉及面很广,一个人不太可能在各个方面都能做到熟悉,但至少,得在一个领域有自己在行或者相对在行的东西,能不被他牵着鼻子走,当然了这也是相当的不容易,好好加油!或者你本身就是不在意技术的话,但又干了前端这行,那么其他的东西可以不管,至少得熟悉自己工作相关的方面的东西,毕竟还是要恰饭。
题外话
拥有自己的思想,能独立思考
这个很重要,虽然古语有云不耻下问。
相关 issue 和链接
最后更新于:2023-03-08 10:23:55
黄哥 学习了