远程代码仓库用的是阿里云 code,没有 CI 。服务器没有备份,怕我一不下心 rm -rf /
老大只是今天下班前提了一下,还没给服务器登录帐号。
自己部署会方便一点。我该不该争取自己部署项目呢?
1
QingStone 2020-12-11 20:27:17 +08:00 via iPhone
哈哈哈哈,跟我一样。每次部署怂得一批!
|
2
hcsu 2020-12-11 20:28:01 +08:00 via iPhone
我也是…每次操作生产怂的一批
|
3
nightwitch 2020-12-11 20:30:06 +08:00 6
"服务器没有备份"
出事是迟早的 |
4
40EaE5uJO3Xt1VVa 2020-12-11 20:32:34 +08:00
3l 说得对
|
5
echowuhao 2020-12-11 20:41:32 +08:00
CI 都没有的公司,要么跟老大说,自己来弄 CI 。要么赶紧跑路。
|
6
darksword21 2020-12-11 21:00:22 +08:00 via iPhone
反正做事之前准备好备份和恢复。然后放开干
|
7
taogen OP @nightwitch 这就是墨菲定律啊
|
8
rabbbit 2020-12-11 21:24:55 +08:00 6
那必须得中午部署了
|
9
wxsm 2020-12-11 21:59:43 +08:00
简单,写个 bash,在自己机器上执行一次,没问题就到远程机器上执行。
|
10
dream4ever 2020-12-11 22:02:36 +08:00
权限控制呢?限制账号只能操作指定目录?
|
11
raaaaaar 2020-12-11 22:15:40 +08:00 via Android
权限被吃了吗?就是干这个事的啊
|
12
jimiy 2020-12-11 22:26:40 +08:00
部署前,先把上一个可运行版本先备份,然后再部署新的,给自己一个退路啊
|
13
Noisky 2020-12-11 22:36:14 +08:00
一定一定要先备份
|
14
f165af34d4830eeb 2020-12-11 22:40:35 +08:00 5
你们有体验过给生产环境服务器调整分区么?我觉得应该和给飞行中的飞机换发动机的感觉差不多。
|
15
iloveayu 2020-12-11 22:53:10 +08:00 1
代码都有了,先在自己本机装虚机部署,跑通整个流程,实际部署时心里就有底了。
正式环境部署前,云服务器先来个镜像,本地虚机先打快照,手潮误删滚回就好。 |
16
hushao 2020-12-12 04:49:19 +08:00
既然老大有这个想法,自己就争取一下吧,生产部署也没什么可怕的。
事先做好部署方案,形成文档,固化成 shell 脚本,自己本地测试通过,然后拿给老大过目,生产环境严格按照文档或者测试通过的脚本来。 生产部署前一定记得备份! |
17
securityCoding 2020-12-12 10:19:14 +08:00 1
为什么不直接起一个 jenkins.... pkg 包每次构建扔到 oss 上面呗
|
18
taogen OP @securityCoding 看了一下,阿里云 code 仓库有 webhooks,可以考虑使用 Jenkins 。
有一点疑惑,pkg 包扔到 oss 上怎么结合 Jenkins 是怎么操作呀?( Jenkins 不太熟悉 |
19
ericgui 2020-12-12 11:14:00 +08:00
如果你们有负载均衡,就可以放心的多了
|
20
loveyu 2020-12-12 11:26:13 +08:00
先本机测试,搭一个完整的环境,脚本全部先验证一遍。
|
21
securityCoding 2020-12-12 11:32:17 +08:00
@taogen jenkins pipline 可以自定义一个上传文件到 oss 的 stage, stage 里面可以执行命令.
下面是我项目里面的 stage 定义供参考 stage('上传 JAR 至 OSS') { steps { script { path = env.WORKSPACE + "/" + params.moduleDir + "/build/libs" echo 'jar 包目录:' + path jarName = params.jarName echo 'jar 包名称:' + jarName branch = env.BRANCH_NAME echo 'jar 构建分支:' + branch sh(script: "/home/user_00/./oss_deploy.sh " + " " + path + " " + jarName + " " + branch + " ", returnStdout: true) } } post { failure { println('上传失败') } success { println('上传成功') } } } |
22
taogen OP @securityCoding 感谢
|
24
codehz 2020-12-12 13:25:49 +08:00 via Android
楼上这种拼凑字符串的怎么看问题都比较大(
|
25
lower 2020-12-12 15:16:22 +08:00
编译操作可能会对服务器 CPU 有大量消耗,不要直接在应用服务器上搞;
尽量只在生产服务器做有限的备份 /替换 /热更新等基本操作哇…… |
27
lower 2020-12-12 17:02:48 +08:00
|
28
mlxj 2020-12-12 17:05:49 +08:00
心里默认一定不要“rm -rf”;
心里默认一定不要“rm -rf” 心里默认一定不要“rm -rf” 心里默认一定 要“rm -rf” 心里默认一定 要“rm -rf” 心里默认一定 要“rm -rf” |
30
js8510 2020-12-12 17:29:26 +08:00 via Android
短期 hacking solution 可以 没啥大毛病。长期建议是使用 成熟的 CI/CD solution 比如你这个 hotswap solution 如果 v2 OOM/dead loop 然后 server no response 无法 rollback 你怎么办?
|
31
boolstone 2020-12-12 17:38:03 +08:00
我记得阿里云已经禁止 rm -rf / 要加参数才可以
|
32
taogen OP @js8510 这种情况,那只能登录服务器查看 gc 日志、进程状态和系统资源占用,或者重启服务器。迫于不是 leader CI/CD 不好推行。
|
34
baozhuo 2020-12-14 09:13:00 +08:00 via Android
反正我是担责任的情况下能不自己部署,甩给别人不香吗?反正我不背锅
|
35
draguo 2020-12-14 10:59:03 +08:00 1
用阿里 code,直接用云效更方便
|
36
julyclyde 2020-12-14 11:07:01 +08:00
这个方案看起来不是很靠谱
不过各企业具体情况不一样,你也可以先做出来再沟通 |