- 主题:怀念过去jenkins一把梭时代的ci/cd
美好旧时光的CI/CD:
内网装个jenkins，鼠标点点从git拉代码，调maven/npm/...构建
写段脚本把生成结果上传服务器
重启服务，完活
容器/公有云时代的CI/CD：
写脚本将目标文件上传到S3，在aws管理控制台里写段脚本
从ec2到s3拉数据，更新/发布服务，再把这段脚本保存在云端以备调用
创建一个单独的ci/cd流程项目
将以上各种脚本的调用全写进一个dockerfile
把构建出来的docker镜像上传某个公有repo
在业务项目中再写个脚本，让脚本在提交master时自动在git服务器云端执行
脚本会依次下载各种docker镜像，创建容器
执行容器内的脚本，完成构建，上传目标文件，发布全过程
最后别忘了为ci/cd流程项目配置一个
更新dockerfile后自动构建docker镜像并发布到公共repo的脚本……
好处是，从头到尾，你不需要任何一台本地服务器，也没有任何重复性劳动
代价是，必须学习三种不同领域脚本的语法格式
--
FROM 116.233.186.*
其实主要就是现在开始流行把脚本放在docker镜像里跑
然后如果必须自定义流程
就凭空多出来一整套维护dockerfile/找公共repo托管/为dockerfile本身建发布流程
的工作量
【 在 guestking (无) 的大作中提到: 】
: 我的旧时光就是本地maven install，然后上传ecs，再跑一下脚本
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*
但是对于服务调度方节省了很多折腾环境的工作……
毕竟现在的运行时除了java/python/node/powershell/bash这些老黄历外，
还有一大堆诸如aws-cli,azure-cli,firebase,heroku之类的存在
【 在 sayinger (言者) 的大作中提到: 】
: 在dockerfile里写流程本来就是歪门邪道，性能就是一坨...
: 容器里跑脚本没有错，但放dockerfile里就是滥用
--
FROM 116.233.186.*
jenkins直接在vpc内部跑么？
【 在 cmkylin (Kylin.C) 的大作中提到: 】
: 看标题吓我一跳，还以为自己out了。
: 实际上，aws+jackins，一样就是点点点就完事儿啊，舒服的很。
--
FROM 116.233.186.*
大部分都是这样干的吧
最多敏感信息拉到环境变量里
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这么说, 你们应该是在代码仓库里维护了各个环境的配置了, 生产环境换一个profile就可以用?
--
FROM 116.233.186.*
不同环境下支持服务访问地址、logger格式之类也没那么敏感了
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 我的原则是代码仓库里不留配置
: 各个环境的访问权限是一把钥匙, 各个环境的服务配置是另一把钥匙, 拿到代码就等于拿到了后者
: 而员工总是会离职的, 离职了代码99%会留一份, 这个代码说不准什么时候手一抖就上github了
: ...................
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*