egg-scripts 部署脚本

[popomore]

功能

• [ ] 构建
  
  
  
  • [ ] 支持 nodeinstall
  
  
  • [ ] 支持语言层编译，如 typescript, babel
  
  
  • [ ] 自定义构建，如静态文件编译
  
  
• [x] 启动

构建

环境依赖 cnpm，cnpm 会根据配置自动安装 node 到应用包中（需要实现）。

应用添加 install-node 配置 node 版本，并添加 egg-scripts 依赖

{
  "dependencies": {
    "egg-scripts": "*"
  },
  "engines": {
    "install-node": "6.9.1"
  }
}

构建顺序

1. 下载应用代码
2. 在应用代码执行 cnpm install --production
3. 执行 egg-scripts build
   
   
   
   1. 预编译处理（ts，babel 等）
   
   
   2. 调用应用的 scripts.build（一般常用于处理静态文件构建）
   
   
   3. 修改 scripts.start/scripts.stop 指向 egg-scripts
   
   

启动

egg 构建出的应用包没有任何依赖，可直接部署

1. 设置环境变量 PATH={app_root}/node_modules/.bin:$PATH
2. 启动 npm start 或 egg-scripts start

扩展

如果框架想提供部署功能，那么可以在框架层依赖 egg-scripts，这样应用就不需要添加了。但是层级比较深，可以在 postinstall 修改 ./node_modules/.bin/egg-scripts.

egg-scritps 主要提供 build 扩展，可以继承 egg-scritps 处理自定义逻辑。

[atian25]

增加下对环境变量转换的支持? 这样就不用自己封装框架和写 loader 了.

[duncup]

部署脚本的能否对pm2启动进行兼容支持？像我所在公司有考虑用pm2进行服务器管理，而且已经在计划上了，用以便针对进程进行监控日志追踪等。

[jtyjty99999]

pm2 是能支持的，只需要用pm2启动入口文件就好了

[popomore]

pm2 配上 npm start?

[fengmk2]

pm2 没有限制，就是有点多余。而且 pm2 自身的稳定性比 egg 内置的 egg-cluster 弱很多。

[duncup]

@fengmk2 不是为了那个东西的稳定性，而是pm2延伸出来的http://pm2.keymetrics.io所能使用的监控。或者egg有直接实现一套的计划的话肯定是更好。

[fengmk2]

@duncup 那你直接使用 pm2 就可以了。

[duncup]

倒也可以，反正两个项目并没什么冲突，服务器直接配倒也可以。就是提一提。

[fengmk2]

不提，pm2 的用法就是 pm2 index.js 就可以了，所有 node 应用都一样。我们认为 pm2 并不能真正用于生产环境，提了反而误导。

[duncup]

似乎对pm2的稳定性意见很大的样子？看来我需要重新考虑下pm2了。

谢谢说明 @fengmk2

[fengmk2]

如果你能说你完全能掌握 pm2 的代码，那我是没有意见的。但是如果没法掌握，那么代表它是未知的。
如果一个 pm 工具的代码比你的应用代码加起来还要复杂，那就应该重新考虑一下了。

[popomore]

和镜像一起做 https://github.com/eggjs/egg/issues/142

[atian25]

增加下对环境变量转换的支持? 这样就不用自己封装框架和写 loader 了.

补充说明：

我们的应用有可能会部署在不同的地方，如 UAE, leadcloud 等等，往往这些云引擎会有自己的 ENV 来表示服务器类型。

目前的作法，要不在自己的框架里（如 nut 在自己的 startCluster），要不需要在启动脚本里面做判断。

前者不太好，后者其实就是 egg-scripts 的定位吧，可以考虑下这里如何支持该需求，我还没想明白：

• 提供类似 egg-init-config 的方式来收集常用的映射？
• 应用在 package.json 里面指定？ egg.envMapping: 'some-npm-package' ?
• egg-scripts 可以被继承?
• 其他更好的方式？

[popomore]

@atian25 就写自己的 scripts，然后生成 config/env 文件。egg-scripts 是可以被继承的。

[atian25]

config/env 文件的话, 就要多次构建了吧? 不能一个包跑多个环境

[popomore]

是的，一次构建多次部署就是通过环境变量设置的，覆盖 getServerEnv 也是一个方法。

[atian25]

在 loader 覆盖 getServerEnv 不行吧, 之前 nut 踩坑过一次, app 和 worker 是 prod, 但 master 是 local...

后面我改为覆盖 startCluster 了.

但这 2 种方法, 都是需要在框架层做, 有点太重了.

譬如我开发一个应用, 想同时部署到 2 个云引擎去

[popomore]

现在 master 没问题了，使用 NODE_ENV 就可以了

不是啊，因为你想自己定义环境变量，新开发者使用 EGG_SERVER_ENV 是没有成本的。

[atian25]

现在 master 没问题了，使用 NODE_ENV 就可以了

说到这个, 部署文档回头要写清楚线上环境需要加上的 ENV

loader 覆盖 getServerEnv

这个呢? loader 只能在框架层覆盖吧? 我期望是通过启动脚本(egg-script) 或插件解决(如 egg-leadcloud)

但目前的机制, 插件太晚了.

[popomore]

确定不支持自己定义环境变量么

[popomore]

之后写引导器的时候再看看好了，云我还没玩过

[atian25]

确定不支持自己定义环境变量么

自定义环境变量的场景, 应该是针对 pre 这些吧?

prod, dev, test 这些是通用的, 只是不同的云引擎的判断方式不一样.

嗯嗯, 后面写的时候看看

[popomore]

我在使用云引擎的时候应该可以去设置环境变量，连我等金融云都支持

[atian25]

这个就是框架来做, 还是用户来做的选择了

举个例子, 某云引擎内置的环境变量是 SERVER_MODE=production/test/development

交给框架来做, 就是只要用户安装 egg-XXX 插件, 就无需理会, 自动适配了.

交给用户来做, 就是他需要在每一个应用对应的云引擎的环境变量配置那里去配置 EGG_SERVER_ENV, 并且这些云引擎要支持不同的运行环境, 可以配置不同的 ENV.

[popomore]

我觉得告诉使用者怎么使用 EGG_SERVER_ENV 就好了，不然你还要去解释，这么多云也不会都跑过，出什么问题我们也不知道。

[atian25]

如果能在插件里面做这个事情, 就会自然很多了.

譬如写个 egg-leadcloud 插件, 在它里面做环境变量的适配, 挺自然的. 不过插件加载阶段就太晚了.

[atian25]

那就先不理了, 等 egg-scripts 出来后再看看有什么更好的方法, 不然就只能框架层实现了.

[popomore]

主要的问题就是这么多云不是我们能做的，把核心做好，让社区去寻找解决方案，我们就以 docker 最直白的方式来写就好了。

[ngot]

话说这个问题，还牵涉到插件开发时的配置。对于不同环境需要不同的配置的问题，config.default.js config.prod.js 这种，往往不太适用。比如，一份代码，部署不同云服务器的化，相同的prod可能配置就不相同了。 EGG_SERVER_ENV 就不太好配了

[atian25]

@ngot 一般业务应该不存在不同云的同时部署场景吧?

脑洞下, 通过自定义环境变量方式呢? 如 config.uae-prod.js ? config.leancloud-prod.js ?

有点晕.

[popomore]

@atian25 @ngot 这个现在就支持的

[atian25]

嗯, 就是觉得有点晕

[ngot]

『config.uae-prod.js ， config.leancloud-prod.js』这种我已经在用了。问题是，这个搞的话，那么如果插件中定义了 config.prod.js 就直接跪了

[popomore]

那个基本都是应用配置，插件如果没有足够把握是不需要过多的配置的。内部服务因为本身就只有一个，所以公用插件写死比较好。

[ngot]

主要问题在于，插件其实是不知道真是的引用部署的环境值的，就无法做到根据不同环境来做不同逻辑了。感觉是需要一个映射机制，让插件能够知道当前是 prod

[ngot]

嗯，是的。我认为插件应该写死，不同环境，应该由应用来配置插件。虽然有些繁琐。

[popomore]

方案更新了，各位看看。

[atian25]

在应用代码执行 cnpm install --production

在构建阶段，很多依赖如 ts, babel 应该是 devdeps 的

[popomore]

这里只能放 dep 里，如果不是，那么首先应用包会很大，而且又很多测试过开发辅助的代码会跟着上线。

还有一个方案就是分开构建，那就会安装两遍。

[atian25]

但 ts 这些放在 dep 一样会导致应用包变大，我们这边目前的方案是分开构建。

[atian25]

这里的矛盾点是，ts, babel, webpack, 甚至还有一些原生模块，是需要在 egg-scripts build 阶段用的，但上线包里面不应该有的。不分开的话，很纠结。

另外 egg-scripts 的两个职责，build 和 start 需要的依赖和能力也不一定一致。

[dead-horse]

感觉有点偏了，开源版本是否需要提供这么强定制的东西？

[popomore]

不会直接依赖模块的，配套文档会介绍下理念和可扩展的工具
Yiyu He [e-mail]于2017年1月23日 周一23:54写道：

感觉有点偏了，开源版本是否需要提供这么强定制的东西？

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/eggjs/egg/issues/241#issuecomment-274526229, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAWA1UgPL8LKj-8hrxTJdPLzFmqYIlNNks5rVM05gaJpZM4Lgqrw
.

[fengmk2]

可以介绍理念，但是不强制使用。大多数环境不复杂的情况下，自己写一个index.js 引导启动文件就搞定了。

[jtyjty99999]

@popomore 我又想了一点是不是可以加个启动上报的，上报到公网，这样可以统计框架被多少人使用

[dead-horse]

不要加上报，不然别人会觉得我们偷他们的信息的

[popomore]

恩，这样不好，而且没必要吧，如果真受欢迎，他们会自己来添加的。

[cycgit]

请教下 入口文件要怎么写?

[popomore]

工具还没有写好，可以看看这个例子

https://github.com/eggjs/examples/blob/master/cnode-api/index.js

[atian25]

@leonardodream 另开 issue，跟这个 topic 无关，顺便注意下 markdown 排版。

[leonardodream]

哦哦哦 @atian25

[zhengxs2018]

egg-scripts 的 bug 也应该提在哪里？window 下 stop 我这里无法关闭 应用

[atian25]

readme 有写了，不支持 win，自己 kill 。服务端部署一般在 linux。

发自我的 iPhone

在 2017年8月8日，18:13，zhengxiansen [e-mail] 写道：

egg-scripts 的 bug 也应该提在哪里？window 下 stop 我这里无法关闭 应用

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[zhengxs2018]

我的错，没仔细看

[atian25]

主要是 win 下的 PS 有点兼容性问题，也很少有部署到 win 的需求，就暂时不支持了，有兴趣的可以提 PR 来支持。

[atian25]

顺便同步下，egg-scripts 工具已经发布第一个版本了，https://eggjs.org/zh-cn/core/deployment.html#部署

[zhengxs2018]

已经在用了，主要是部署在linux，window只是做个预览而已，谢谢

[gitrl]

请问一下egg入口文件怎么写呢？

[gitrl]

基于egg.js用react发开h5页面，有大佬知道怎么弄的吗 ？弄了一周多了，环境还没打起，求助大神帮帮忙。。。

[atian25]

用 egg-scripts 的话不需要入口文件。

自己写入口的话，可以看 https://eggjs.org/zh-cn/faq.html 的 PM2 那里，但这只是一个简单的调用， egg-scripts 里面做的一些启动日志的处理不会在里面，需自行处理

[atian25]

@popomore should we close this ?

[popomore]

可以，构建后面再做

[leotian]

使用egg-scripts 启动，默认NODE_ENV就是production，并且不可修改？

[atian25]

正式环境应该只用 production

[leotian]

可是我们有一个qa环节，部署的代码和正式环境一样，这时候想用egg-scripts 启动，NODE_ENV默认置为production会让我们内部的一些包出问题，我们需要自己设置NODE_ENV

[atian25]

包的设计最好不要依赖于环境变量，而是通过构造函数入参来决定。

[leotian]

恩，你说的有道理

[leotian]

不过为什么一定要强制帮我设NODE_ENV呢，我自己设不行吗

[atian25]

不为什么， 就是 default to good。

你有需求就 PR 支持传递 ENV 咯。虽然我还是建议你不要用 ENV 来做判断。

[lxd90]

比pm2更好用