赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

18 | 持续交付流水线软件构建难吗?有哪些关键问题?

赵成 2018-02-07
上期文章我们介绍了需求分解与应用对应的管理方式,以及提交环节的开发协作模式,今天我们详细介绍一下提交阶段的构建环节,也就是我们经常提到的代码的编译打包。

构建环节

由于静态语言从过程上要比动态语言复杂一些,代码提交后,对于 Java 和 C++ 这样的静态语言,我们要进行代码编译和打包。而对于 PHP 和 Python 这样的动态语言,就不需要编译,直接打包即可。
同时,编译过程就开始要依赖多环境以及多环境下的配置管理,并根据不同的环境获取不同的配置,然后打包到最终的软件发布包中。
下面我就结合自己的实践经验,以 Java 为例,对构建环节做下介绍。
构建过程中我们要用到以下 4 种工具
Gitlab,代码管理工具,也是版本管理工具;
Maven,依赖管理和自动化构建工具,业界同类型的工具还有 Gradle 等;
Docker,用来提供一个干净独立的编译环境;
自动化脚本和平台,自动化构建的任务我们使用 Python 脚本来实现代码获取、编译执行、软件包生成等。
具体整个构建过程图示如下:
我们以 Java 为例描述如下。
1. 首先准备好 JDK 的编译镜像,这个镜像环境与线上运行环境保持一致,比如 OS 版本、内核参数以及 JDK 版本等基础环境。当需要启动一个构建任务时,就创建一个对应的 Docker 实例,作为独立的编译环境。
2. 构建任务会根据应用配置管理中的 Git 地址,将代码克隆下来放到指定的编译目录。Docker 实例启动后,将编译目录挂载到 Docker 实例中。
3. 执行 mvn package 命令进行编译打包,最终会生成一个可发布 war 的软件包。同样的,对于 C++、Go、Node.js,也会准备好类似的编译镜像。不同的是,打包时,对于 C++ 中的 cmake 和 make,Go 中的 go install 等等,最终也会生成一个可发布的软件包。
4. 构建完成后,生成软件包放到指定构件库目录,或者直接发布到 maven 的构件库中管理,然后将 Docker 实例销毁。
上述就是一个完整的构建过程。在这里,你一定会有一些疑问,那么,我先回答几个比较常见的问题,欢迎你留言和我继续讨论。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 喜剧。
    如果多套环境多套编译感觉在效率上有点低。针对java程序,我们能否统一打成jar包,然后利用启动参数来控制你是在使用什么样的配置文件呢?如果使用的是微服务架构,我们是否最好将配置文件剥离出来,使用配置中心来管理?

    作者回复: 有很多配置是启动时就会依赖的,特别是跟环境相关的这些,比如数据库连接不上可能就直接启动异常了,进程无法正常启动,那读取配置中心的配置也就无从谈起了。

    2018-02-10
    3
  • 赵丹
    我们公司用的svn进行代码管理,jenkins,ant工具实现的自动化构建部署,我们使用的工具部署方式需要调整吗,怎么调整会更好些,希望老师给点建议。
    2018-05-15
    1
  • 海格
    我们就是使用的配置中心,编译完打包车docker镜像,然后调用接口进行部署,启动容器,在启动容器的时候会传入几个参数,会先拉取配置文件,然后在运行jar包。
    2018-04-04
    1
  • Adam
    我是这样做的。pod里面initcontainer配置一个拉取config的程序(程序得开发写好封装成镜像),初始化容器运行完成后才会开始运行业务容器。initcontainer传入不同的环境变量以及应用名就可以拉取对应的配置。
    2019-03-26
  • 松花皮蛋me
    我们是只打包一次,然后发布时根据环境将配置文件更换,配置文件和启动脚本和库都是分文件夹存放的。另外docker镜像发布是趋势,不需要先申请机器,快速扩容
    2019-02-17
  • 快乐就好
    现在kubernetes 可以说已经足够完善了,对于应用的发布,我们发布是直接发布应用打包到容器的容器吗?是否有什么缺陷?
    2018-08-18
  • 森馫鑫
    可能有读者会问:为什么不直接生成 Docker 镜像,后续直接发布镜像?

    这里我能想到一个场景就是客户端的持续发布,这个是无法用镜像代替的。
    2018-07-15
  • 天使
    通过环境变量配置docker,应用读取环境变量获得应用配置;通过config server为应用提供代码配置;docker 的好处在于开发机器上可以迅速启动进行调试;依赖太多的话,启动docker的时候将依赖连到线上dev或qa环境
    2018-05-24
  • 江龙
    实现一套配置中心服务,每个环境独立的一套配置中心,服务起来时会相应的去对应的配置中心中动态请求配置。这样就能实现只一次构建,且代码与配置分离

    作者回复: 有些配置是启动时就依赖的,这种配置只能在构建时打入软件包

    2018-03-01
收起评论
9
返回
顶部