这是一个创建于 1686 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在机器 a 上装了 jenkins 其中配置了节点 机器 b 的信息，想要在机器 b 上发布项目
1.git 上拉取代码 2.打包
最后在 b 上启动
1 和 2 这两部是在 a 还是 b 上完成的额
第 1 条附言 · 2020-05-12 16:40:42 +08:00
配置了节点 机器 b 的信息
是 指 b 是一台普通的一般用来访问服务的机器...
是 指 b 是一台普通的一般用来访问服务的机器...
 |
1
755rQlBW742S6Fcc 2020-05-12 10:04:50 +08:00
应该是 B
|
 |
2
chenuu 2020-05-12 10:04:52 +08:00
在 A 上完成的
|
 |
3
yjxjn 2020-05-12 10:06:28 +08:00
A 啊。。。肯定不是 B，B 负责拉 war 包就行。或者手动给 copy 过去。
|
 |
4
also24 2020-05-12 10:07:19 +08:00 via Android  1
1，2 在 A 上完成，此谓 CI
打包后的东西： 从 A 上传输到 B 上； 或者从 A 上传输到制品库，再使用 B 从制品库拉取。 最后在 B 上启动。 此谓 CD |
 |
5
e1o 2020-05-12 10:07:56 +08:00
公司目前都是在 A 上面做这些操作
|
 |
6
hiwangzheng 2020-05-12 10:08:55 +08:00
B 上完成的，A 的工作就是任务发布，然后把执行脚本同步给 B，然后 B 去执行脚本，拉代码和打包。
|
 |
7
LUAgam 2020-05-12 10:09:14 +08:00
a 啊，jenkins 有 git 、maven 插件支持 pull 、打包、编译等
|
 |
8
monsterxx03 2020-05-12 10:11:22 +08:00
A 啊, B 上还有线上程序跑着, 编译打包很容易跑满 CPU 的.
|
 |
9
xylophone21 2020-05-12 10:22:16 +08:00
看起来关键分歧在如何理解“配置了节点 机器 b 的信息”，如果这里指的是 jenkins 的 slave 节点，那么在 B 上运行 1 和 2.
但后面提到只是在 B 上运行，那边 B 就仅仅是部署机，1 和 2 在 A 上运行。 所有关键是，“配置了节点 机器 b 的信息”具体指什么 |
 |
10
x66 2020-05-12 10:23:20 +08:00
用 B 的怕不是来搞笑的吧，如果有很多 B，那不是每台服务器都要编译打包一次，浪费资源不说，怎么保证打包出来的程序不受系统环境的影响
|
 |
11
defunct9 2020-05-12 10:52:56 +08:00
A.
|
 |
12
nicevar 2020-05-12 10:57:06 +08:00
需要打包的肯定在 A 上处理, A 上拉取代码 /编译打包, 然后部署到 B
|
 |
13
CRUD 2020-05-12 11:00:48 +08:00
9 楼+1，如果 B 是 jenkins 从属节点则在 B 上执行整个部署流程。
如果 B 只是普通服务器节点，则整个代码拉取打包的过程均在 jenkins 节点也就是 A 节点上完成，打包完成后在将包 push 到 B 节点运行。 |
 |
14
d0m2o08 2020-05-12 11:01:31 +08:00
A 只是作为一个 master 用于发布任务,具体的任务需要 B 也就是 slaver 去执行
这样不会对 master 造成压力 |
 |
15
egglin 2020-05-12 11:41:14 +08:00
涨知识了
|
 |
16
xuanbg 2020-05-12 11:45:42 +08:00
正常的操作逻辑：在 A 上面打包成 jar 或者 war，然后上传到 B 发布。
你非要通过 A 控制 B 去 pull 源代码打包发布也不是做不到，但会比较麻烦就是了。 |
 |
17
wucao219101 2020-05-12 11:46:57 +08:00
在 A 上完成 git 代码更新和编译打包，再把包部署到 B 。
B 是生产环境机器，一般不会去做编译打包，也不用安装 git 命令和 Maven 。 |
 |
18
calmzhu 2020-05-12 11:50:57 +08:00 via Android
jenkins 调度可以指定节点的。默认应该是 master 或者随机
|
 |
19
basefas 2020-05-12 11:58:20 +08:00 1
首先不能在 B 上执行，打包过程可能会占用过多资源，会影响 B 上的服务。
实际上应该有个打包机 C，CPU 和磁盘性能最好好些，然后所有项目的打包任务都调度到 C 上。 A 只负责调度，将对应任务调度到 C 上打包，打包完后再由 A 调度部署在 B 上。 |
 |
20
legiorange 2020-05-12 14:30:04 +08:00
现在机器 a 上装了 jenkins 其中配置了节点 机器 b 的信息，想要在机器 b 上发布项目
1. A 机器通过 webhook 到 git 上拉取代码 2.通过 pipeline 或者配置好的命令来通过 Maven 、Ant 、Gradle 打包 此时 jekins 已经完成 CI 的持续集成。 3.通过配置 B 节点通过 docker 、k8s 等实现容器构建部署，相当于把 A 构建好的包下载到 jvm 容器内运行。 另我不同意打包机的观点，大部分情况是节点 A 机器已经基本够用，不够就扩展，又不是做 devsecops |
 |
21
BlackBerry999 2020-05-12 15:11:38 +08:00
回答离 A 和 B 都有，应该相信谁呢？
|
 |
22
julyclyde 2020-05-12 15:29:10 +08:00
回答 A 的朋友们是不是没看清 B 是 jenkins slave 啊？
|
 |
23
Chengxians 2020-05-12 15:33:59 +08:00
jenkins 就该干它该做的事，当然是 a 干完所有的，b 去拉去最新的包重新部署
|
 |
24
haosamax 2020-05-12 17:43:22 +08:00
不会真有人在 b 上吧
|
 |
25
A388 2020-05-12 17:47:15 +08:00
用 B 的也是厉害
|
 |
26
hell0v2 2020-05-12 17:58:46 +08:00
技术上都可行，看具体业务和机器要求吧
|
 |
27
figael 2020-05-12 18:00:16 +08:00
CI （编译）：可在 A 或 B 执行，如果 B 是 A 的 slave 节点，而且被分配。如果仅仅是配置了 ssh，只会在 A 执行。
CD （部署）：B 需要拉取 CI 阶段的产物来运行，这个产物可能在 A，或者 B 。 --- 生产流程，一般 B 不能作为 jenkins slave 节点。 |
 |
28
dolphintwo 2020-05-12 18:02:28 +08:00
A 送分题 下一个
|
 |
29
jynstar 2020-05-12 20:53:36 +08:00 via iPhone
A
|
 |
30
andj4cn 2020-05-13 07:39:26 +08:00 via Android
拉代码和打包是 A 做的，打包结束后包也放在了 A 或者上传到其他位置。这时候需要一步主动操作，就是怎么把包放到 B 上运行。这部分就很自由，一般都是手动操作把包从 A 拉到 B 运行，或者写一个额外的服务拉过来，或者打包结果是 docker 镜像的话 A 上传到私有镜像仓库，手动发布到 k8s 上去。总之拉代码和打包肯定是 A 做，发布视情况而定。
|
 |
31
cominghome 2020-05-13 09:09:15 +08:00
@BlackBerry999 看补充的内容，B 不是 slave 。那显然 1 2 都是在 A 完成的，B 只负责运行代码
|
 |
32
smilzman 2020-05-13 09:10:38 +08:00
首先，在 a 和 b 上打包都没问题，但是你思考一下，如果把问题换成在机器 a 上装了 jenkins，其中配置了节点机器 b 和机器 c 的信息，想要把项目 x 发布到机器 b 和机器 c 上，这样是不是就清晰了？
在发布到一台机子的时候，在哪里打包都一样，但是如果需要同时发布到 b 和 c 是不是需要打包两次、安装多套打包环境？ |
 |
33
tingfang 2020-05-13 16:42:27 +08:00
反正不要在提供服务的机器上打包。
|
Select Language