DevOps

DevOps

闲聊我心中的运维开发

aoxiang 发表了文章 • 0 个评论 • 232 次浏览 • 2019-06-03 12:21 • 来自相关话题

#前言 在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。 诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多 ...查看全部
#前言
在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。

诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多:

* 桌面运维工程师
* 业务运维工程师
* DBA工程师
* 配置工程师
* 运维开发工程师
* 以及其它....

1.png

原本准备写篇前端眼中的运维开发,恰巧前组长写了两篇结合自身六七年开发经验写的体会。用他的文章来阐述再合适不过了。以下来自其投稿以及穿插一些知识普及。
#DevOps:打破协作壁垒
来自维基百科:
2.png

DevOps(Development和Operations的组合詞)是一种重视「软件开发人员(Dev)」和「IT运维技术人员(Ops)」之间沟通合作的文化、运动或慣例。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

透过自动化「软件交付」和「架构变更」的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门,在这种环境下如何采用新的开发方法(例如敏捷软件开发),是一个重要的课题。

按照从前的工作方式,开发和部署,不需要IT支持或者QA深入的跨部门的支持;

而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署,它是一套针对这几个部门间沟通与协作问题的流程和方法。
3.png

具体来说,就是在 软件交付和部署过程中提高沟通与协作的效率,旨在更快、更可靠的的发布更高质量的产品。
#运维开发的价值
从岗位职责来看,运维开发要做的工作是:

通过开发技能帮助运维实现运维工作的自动化。说白了就是“辅助”,或者说是运维的臂膀,需要把运维中遇到的问题提供平台查询,或者把一些常见的重复操作给抽象出来做成工具,减少运维的人工介入。
4.png

运维服务伴随并支撑着业务发展的整个生命周期。

而DevOps将运维服务的执行方式升级为更加软件工程化的手段,减少人肉操作,DevOps 强调自动化、拉动式来提高团队交付效率与质量。

而传统的运维需要谋求技术转型,从原来只关注操作系统层面的技术已经不够了,还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升,也需要持续关注整个业务、应用、服务的生命周期管理。

简单来说,就是把过去传统的黑盒运维的思维方式抛弃,进入白盒运维的时代,我们必须更加深入代码、深入业务运营,让整个线上服务运行于更优质高效的状态。
#运维开发是什么?
要建设运维自动化或者实践 DevOps 离不开运维开发工程师的参与,但要怎样才能更好地发挥运维开发的作用呢?

我曾作为运维开发经理的角色和各种类型的运维开发一起协作过,团队中有本来就做运维开发的,也有本来做其他业务(电商、平台)的开发转来协助运维团队的,还有原本是做业务运维后来转型做运维开发的。
和他们协作一段日子后,总体感觉如下:

运维开发首先是一个程序员,不是运维工程师。

一个好的运维开发需要具备 「运维理解」+「开发能力」:

* 对「开发能力」的技术要求低于其他业务形态(如游戏、电商、搜索等)。
* 对运维业务的理解难度会低于电商、游戏等业务形态,即对「运维理解」的要求不高。
* 对运维相关技术栈的掌握程度要求高,如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、Kubernetes等。

5.png

综上所述,运维开发是一个深度不算太深的职业分支,而现在之所以对运维开发需求量热起来了,主要由于老一辈的资深运维普遍研发能力有限,而这是有历史原因的。等到业界提出 DevOps的时候,他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等高级范畴,所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

所以,当我们有自动化系统的建设需求时,需要更专业的程序员来协助。但一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使,这时候有部分年轻的运维工程师升级了研发技能,转型运维开发,把好使的运维系统做出来了,赢得了运维团队的好评,大家都为「运维开发」点赞。

所以,大家将 「好使的运维系统」 和 「运维开发」 等价起来,以为我们只要招来一个运维开发,那么一套完美的运维平台就能自动诞生出来,这是个很大的误区。
#打造「好使的DevOps系统」
其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」,这两种能力也是可以分离的,不一定要强加在运维开发工程师一个人的身上。

类似其他业务形态的开发过程,需要产品经理和程序员两种角色分离,企业也不会说要招聘既会写代码、又会出需求的程序员。

所以,当运维能把运维自动化的需求细致地文档化下来,把自动化系统的设计、架构等关键环节确立下来,这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员,最终就可以得到「好使的运维系统」。

当然, 一般企业不会专门为运维开发配备「产品经理」,所以运维开发想要再往高级发展的话,也可以替代运维出需求,升级为运维产品经理,以程序员的思维角度来解决运维服务的工程效率和质量问题,我认为这也是类似 Google 所提倡的 SRE 文化。
##DevOps平台
编者补充描述。

光说不练假把戏,编者在上家公司的主职就是将DevOps操作界面化。
其中的核心模块:应用部署发布监控。

图为DevOps应用部署发布监控界面图:
6.png

我们组在做上图的DevOps系统时,面临的情况是:无产品、无设计、需求也是靠业务运维和开发们的口头描述。

其中的核心功能:应用部署界面,在参考其它同类产品后,发现都不适合业务场景,要么功能太分散,要么就仅是流程控制。于是前端功能里,我们做了这些:

* 区分不同环境下的包,实现有序管理。
* 应用的状态可以通过界面做启停、查看配置等任务。
* Jenkins服务操作可通过界面完成,简化配置工程师的工作。
* 业务运维与开发团队的日常发包工作界面化。

此时一个优秀的运维开发需具备以下技能:产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。

所以,当运维需求被理解、分析得足够透彻,以及运维开发获得了「产品经理」能力后,运维开发就是一种普通的开发分支,按需求文档编码即可。
#优秀的运维开发
从事DevOps平台开发相关工作已有六七年了,自身经历总结,觉得一个优秀的运维开发工程师应当具备以下能力和素质。
##提高运维意识。
从下到上,从上到下的工作都要做好,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放运维。

运维意识是很重要,并不是你技术很牛,学的技术很多很熟,就不代表你不需要运维意识。

其实领导很看重运维意识的,例如有没有做好备份,权限分配问题,平台测试情况,故障响应时间等,这些都是意识,而不是你学了很多技术自认大牛了,平台发现故障你又没什么大不子,以为很简单的问题喜欢处理就处理,不需要向其它部门反馈等,领导不是看你的技术如何,而是看你的运维意识如何,你没运维意识,技术再牛也没用,只会让其它部门的人跟你不协调。
##了解业务场景
DevOps平台最终服务于运维部和开发测试部同事,因此只有熟悉了解了每一项业务的运维场景,才能更好去设计功能与代码开发,熟悉业务场景才能方方面面考虑周全,开发出来的代码才能满足各类场景应用。
##拒绝重复犯错
人难免会犯错,这是无法避免的,我们应当根据已有的犯错经验,总结犯错的原因,以及如何避免同类情况再次发生,甚至可以把一些典型的错误在团队中分享,把一个人的错误得到的经验传播于整个团队。
##凡事有备份,可回退
运维工作中经常有一些发布,迁移,备份等复杂操作,因此,在研发DevOPs平台的时候,要做好全面的操作计划,思考每一步可能的回退与备份。
##平台操作尽量简化
DevOps平台目的就是为了能够提高运维的工作效率,解放运维,因此在设计与开发的时候,应当保持操作简单,不要让事情变得太复杂,能点一下到位的,尽量不要让人点五六下才能完成操作。
##注重优化用户体验
DevOps开发是一个迭代的过程,虽然我们常说以功能开发为主,但是用户体验也同等重要,试想一下,纵使你开发的功能众多,如果体验不友好,用户便失去了再次使用的欲望,如果用户拒绝,抵触使用平台,做再多功能也是失败,最终平台推广失败。因此,在研发的过程中,我们应当深入体验自己开发的产品,把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。

在设计与开发的过程中经常会碰到复杂,繁琐的场景,这个时候我们很容易失去耐心,我们要时刻提醒自己,必须严格履行自己的工作职责,端正自己的工作态度,做一件事,要么不做,既然做了就要做好:当你想要放弃的时候,想想当初为什么要开始。
#总结
本文是我个人对运维开发以及其职业发展的一些浅薄理解,总的来说,运维开发还是一个比较有意思且有良好发展的职业分支,虽然偶尔也要背黑锅,但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

链接:https://juejin.im/post/5cf29a6ae51d45778f076cd2

2019企业IT现状和趋势调研报告:70.7%的企业有云原生相关计划

灵雀云 发表了文章 • 0 个评论 • 155 次浏览 • 2019-06-03 11:00 • 来自相关话题

2019年第一季度,灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研,通过定向邀请,3个月内共收集了400余份有效调研问卷,这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。 发起本次调研 ...查看全部
2019年第一季度,灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研,通过定向邀请,3个月内共收集了400余份有效调研问卷,这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。

发起本次调研的初衷,是我们希望了解当前企业,尤其是传统企业目前IT应用开发现状、以及以DevOps、Kubernetes、微服务等为代表的云原生技术在企业的应用情况,从而勾勒出传统行业IT发展趋势,并对于判断国内用户对云原生相关技术的认知度提供一个有价值的参考。
核心要点解读:
1、 约70%的参与调研者所在企业2019年IT预算有上浮;

2、 24.4%的参与调研者表示公司IT系统基本全靠自研,企业开始自建软件研发团队,主导IT应用的研发;

3、 70.7%的参与调研者所在企业表示在2019年有容器、DevOps和微服务方面的规划;

4、 11.4%的参与调研者所在企业已经试点了具有标杆意义的云原生实践,如精英团队的DevOps实践,小范围非核心应用的微服务拆分改造实践等。


pic2.jpg



本次调研的400多位调研对象中,80%以上来自金融、能源、制造、汽车等传统行业,其中17.3%来自基础架构部门, 22.5%来自运维部门,34.1%来自研发部门,还有约10%的被调研对象为企业的CIO/CTO等高级IT管理者。


pic3.jpg



被调研企业中,服务器规模在100-500台的比例为26.8%,500-1000台的企业占比22%,1000台服务器以上规模的14.6%。



IT系统自研还是外包



pic4.jpg




在数字化转型的背景下,传统外包的做法在被逐渐改变。在此次调查中,70.7%的参与调研者表示目前IT系统是自研外包兼而有之,其中核心业务系统以自己开发为主,24.4%的参与调研者表示公司IT系统基本全靠自研,只有4.9%的参与调研者选择了纯外包选项。这表明,企业开始不再将大部分业务系统,尤其是核心业务需求开发外包,开始自建软件研发团队,主导IT应用的研发。只有企业自己主导IT研发,才能够打造IT核心竞争力。

软件能力成为企业的核心竞争力,这恰好是数字化转型的本质之一。何谓成功的数字化转型?灵雀云认为,有三大衡量标志:IT部门由成本中心转为收入中心;企业自己主导IT产品的研发;改进工具、流程、文化来提高交付速度和质量。最终,实现客户满意度的提升、打造差异化竞争优势、加速产品上市。



IT系统更新频率




PIC5.jpg



在IT系统更新频率方面,每月都要更新、升级的比例达到了51.2%的高占比。同时,每3-6个月更新一次的比例达22%。每个传统领域,都受到了来自Fintech金融科技、车联网、物联网、新零售等新技术驱动的创新业务的挑战,传统企业只有借助IT手段才能实现持续发展,在速度和规模上保持竞争力。



IT系统和研发团队TOP 3挑战



pic6.jpg




本次参与调研的企业以中大型企业为主,其中研发团队规模达到100人以上的比例高达44.3%,20-100人规模的占32.4%。

PIC7.jpg




今天,许多企业都经过了大量IT建设,从分散到集中,造成IT系统越来越复杂,信息孤岛林立,架构臃肿等问题突出。调研中企业IT系统支撑所面临的压力位列前三的挑战分别是:系统复杂性越来越高(65.9%);应用交付压力大,交付速度无法满足业务需求(61.4%);运维管理复杂度提升,IT部门很难构建一支全功能团队(53.7%)。


PIC8.jpg



同时,研发团队所面临的挑战前三甲分别是:部署和运维复杂,运维成本高(74.6%);研发、测试、运维等角色之间相互孤立(62.3%);升级和变更流程复杂,IT服务和应用交付周期长(45.7%)。此外,比较突出的挑战还有,工具链无法完整集成,工具使用困难(32.3%),单体应用过于庞大,迭代效率低下(20.4%)。


pic9.jpg



上述结果充分表明,面对高度创新、快速变化和充满不确定性的新型业务需求,传统开发模式和IT架构已经成为掣肘。70.7%的参与调研企业表示2019年有容器、DevOps和微服务方面的规划和实施计划。

只有朝着持续交付、敏捷部署、快速迭代,通过敏捷IT赋予业务足够的敏捷,才能够满足不断变化的业务需求,重塑自身的生产力,形成竞争优势,带来更好的用户体验,这最终落到以Kubernetes/容器、DevOps和微服务为核心的云原生技术的落地上。云原生架构和理念与数字化转型一脉相承,帮助企业更加顺畅地实施数字化转型。



业务上云需求最强烈,开源、数字化转型受追捧



PIC10.jpg




在企业最关注的新兴技术趋势方面,云计算占比82.9%,企业将业务上云,提升IT资源效率作为首要关注对象。大数据和人工智能紧随其后,占比分别为73.2%和46.3%。其中开源解决方案在调研对象中的关注程度达到24.4%。

当前开源技术正在进入快速发展阶段,向着企业应用的方方面面深入。开源及开源社区不断将新的工具、方法和最佳实践用于云原生的实际业务用例,解决云原生用户的关键问题。借助许多开源解决方案,云原生部署的复杂性和难度也在得以降低。

此外,数字化转型的关注度为33.6%。如今每位IT从业者言必称数字化转型,IT能力也直接指向助力数字化转型。CIO和其他IT管理者已将企业的数字化计划置于新的高度,希望通过数字化来改变企业的商业和业务模式,数字化业务将从初步试验走向大规模应用。伴随企业数字化业务的不断成熟,预计未来几年,数字化转型将进入爆发阶段。



传统企业2019年IT预算稳中有升


PIC11.jpg





本次调研中,被调研企业今年IT工作的重点包括业务上云(56.1%),云原生、大数据、人工智能等新技术采用(53.7%),打造数字化团队,引领企业的数字化创新(43.9%),选择传统业务应用的比例不足20%。越来越多的企业将工作负载放在云端,将正在开发的应用或服务托管在云平台上,云市场不断增长。


PIC12.jpg



在IT预算方面,比客观经济形势略显乐观,和2018年IT预算相比,接近70%参与调研企业2019年的IT预算略有上浮,其中增长5%以内的企业占比37.5%,增长5-10%的企业占比21.2%,增长10%以上的企业达到12.7%。

此外,调研结果显示,数字化转型是一项需要通盘考虑的工作,需要项目管理部门、技术管理部门、开发部门、运维部门共同参与,制定统一的数字化转型方案和决策并推进。有些参与调研的企业特别强调2018年已经在全公司范围内试点了具有标杆意义的云原生实践,如精英团队的DevOps实践,小范围非核心应用的微服务拆分改造实践等,并且这些都将在2019年进行大范围推广。

CoDo开源一站式DevOps平台

尼古拉斯 发表了文章 • 0 个评论 • 178 次浏览 • 2019-05-31 15:37 • 来自相关话题

有幸参与到CoDo项目的开发,这是一个非常棒的一站式开源运维平台,分享给大家。 #平台介绍 CODO是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。 CODO前端基于Vue iview开 ...查看全部
有幸参与到CoDo项目的开发,这是一个非常棒的一站式开源运维平台,分享给大家。
#平台介绍

CODO是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。

CODO前端基于Vue iview开发、为用户提供友好的操作界面,增强用户体验。

CODO后端基于Python Tornado开发,其优势为轻量、简洁清晰、异步非阻塞。

CODO开源多云管理平台将为用户提供多功能:ITSM、基于RBAC权限系统、Web Terminnal登陆日志审计、录像回放、强大的作业调度系统、CMDB、监控报警系统、DNS管理、配置中心等。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
##产品架构

1.jpg

##产品功能

2.jpg

##模块说明


* 项目前端:基于Vue + Iview-Admin实现的一套后台管理系统
* 管理后端:基于Tornado实现,提供Restful风格的API,提供基于RBAC的完善权限管理,可对所有用户的操作进行审计
* 定时任务:基于Tornado实现,定时任务系统,完全兼容Linux Crontab语法,且支持到秒级
* 任务调度:基于Tornado实现,系统核心调度,可分布式扩展,自由编排任务,自由定义流程,支持多种触发,支持审批审核,支持操作干预
* 资产管理:基于Tornado实现,资产管理系统,支持手动添加资产,同时也支持从AWS/阿里云/腾讯云自动获取资产信息
* 配置中心:基于Tornado实现,可基于不同项目、环境管理配置,支持语法高亮、历史版本差异对比、快速回滚,并提供Restful风格的API
* 域名管理:基于Tornado实现,支持多区域智能解析、可视化Bind操作、操作日志记录
* 运维工具:基于Tornado实现,运维场景中常用的加密解密、事件、故障、项目记录、提醒、报警等

##在线体验

CoDo提供了在线Demo供使用者体验,Demo账号只有部分权限

- 地址:http://demo.opendevops.cn
- 用户:demo
- 密码:2ZbFYNv9WibWcR7GB6kcEY

3.jpg

##推荐理由

团队出品: GitHub上有很多开源的DevOps工具,几乎全部都由个人发布维护,代码质量、版本进度以及可持续性都无法保障,陷入不能用或不敢用的尴尬境地,CoDo非个人项目,由一个团队负责开发维护,有幸我也是团队中一员,参与贡献了部分代码,所以在稳定性和持续性方面更有保证。

生产实践: CoDo核心代码贡献者全部来自于一线运维团队,团队成员从运维需求出发,致力于解决运维痛点,更了解运维的需求,且核心代码经过了多年生产实践,并非实验产品,运行稳定

功能齐全: CoDo采用微服务的理念构建,模块化开发,目前已有资产管理、定时任务、任务调度、配置中心、域名管理、运维工具几大模块,支持持续集成、持续部署、代码审查、数据库审核与优化建议等众多功能,覆盖大部分的运维场景,让你不再费心劳神在多个系统间奔波,一个平台全搞定

完善支持: CoDo除了提供专业的文档支持外,还同时开始录制一些基础的部署使用视频帮助初学者快速上手

开源免费: 这是一个开源项目,所有功能均可免费使用,源码托管在GitHub
##项目地址


* 官网:http://www.opendevops.cn
* GitHub:https://github.com/opendevops-cn
* 文档地址:http://docs.opendevops.cn/zh/latest
* 安装视频:https://www.bilibili.com/video/av53446517

原文链接:https://mp.weixin.qq.com/s/eZX5qoJzuCSuLI98gSCtpw

火热的云原生到底是什么?一文了解云原生四要素!

阿娇 发表了文章 • 0 个评论 • 240 次浏览 • 2019-05-30 18:33 • 来自相关话题

所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
#云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
1.jpg

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
##云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
2.jpg

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
##云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
3.jpg

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
* 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
#云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
4.jpg

##持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
5.jpg

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
6.jpg

蓝绿(Blue-Green)部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
##微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
7.jpg

Going Agile - Breaking the monolith Conway's Law and Microservices

这样按照组织架构划分的优势在于:

  1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
  2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

  1. 有HA(High Available)的需求需要微服务。
  2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
  3. 经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
##容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
8.jpg

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
9.jpg

容器生态图

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
##DevOps——以终为始,运维合一

10.png

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
#总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

云原生之下的Java

尼古拉斯 发表了文章 • 0 个评论 • 197 次浏览 • 2019-05-30 10:22 • 来自相关话题

自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

DockOne微信分享(二一零):平安证券Kubernetes容器集群的DevOps实践

齐达内 发表了文章 • 0 个评论 • 421 次浏览 • 2019-05-29 11:54 • 来自相关话题

【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同 ...查看全部
【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同行有所借鉴和帮助。
#生产环境的高可用Master部署方案
Kubernetes的高可用Master部署,现在网络上成熟的方案不少。大多数是基于Haproxy和Keepalived实现VIP的自动漂移部署。至于Haproxy和Keepalived,可独立出来,也可寄生于Kubernetes Master节点。

我司在IT设备的管理上有固定的流程,VIP这种IP地址不在标准交付范围之内。于是,我们设计了基于DNS解析的高可用方案。这种方案,是基于Load Balancer变形而来。图示如下:
1.png

这种构架方案,平衡了公司的组织结构和技术实现。如果真发生Master挂掉,系统应用不受影响,DNS的解析切换可在十分钟内指向新的Master IP,评估在可接受范围之内。

公司内部安装Master节点时,使用的基本工具是Kubeadm,但是作了脚本化改造及替换成了自己的证书生成机制。经过这样的改进之后,使用kubeadm进行集群安装时,就更有条理性,步骤更清晰,更易于在公司进行推广。

底层的etcd集群使用独立的Docker方式部署,但共享kubeadm相关目录下的证书文件,方便了api-server和etcd的认证通信。脚本的相关配置如下:
2.png

当以DNS域名的形式进行部署后,各个证书配置认证文件,就不会再以IP形式连接,而是以DNS域名形式连接api-server了。如下图所示:
3.png

#分层的Docker镜像管理
接下来,我们分享一下对Docker镜像的管理。Docker的企业仓库,选用的是业界流行的Harbor仓库。根据公司研发语言及框架的广泛性,采用了三层镜像管理,分为公共镜像,业务基础镜像,业务镜像(tag为部署发布单),层层叠加而成,即形成标准,又照顾了一定的灵活性。

* 公共镜像:一般以alpine基础镜像,加上时区调整,简单工具。
* 业务基础镜像:在公共镜像之上,加入JDK、Tomcat、Node.js、Python等中间件环境。
* 业务镜像:在业务基础镜像之上,再加入业务软件包。

4.png

#Dashboard、Prometheus、Grafana的安全实践
尽管在Kubernetes本身技术栈之外,我司存在体系化的日志收集,指标监控及报警平台,为了运维工具的丰富,我们还是在Kubernetes内集成了常用的Dashboard、Prometheus、Grafana组件,实现一些即时性运维操作。

那么,这些组件部署,我们都纳入一个统一的Nginx一级url下,二级url才是各个组件的管理地址。这样的设计,主要是为了给Dashborad及Prometheus增加一层安全性(Grafana自带登陆验证)。

这时,可能有人有疑问,Dashboard、kubectl都是可以通过cert证书及RBAC机制来实现安全性的,那为什么要自己来引入Nginx作安全控制呢?

在我们的实践过程中,cert证书及RBAC方式,结合SSH登陆帐号,会形成一系列复杂操作,且推广难度高,我们早期实现了这种模式,但目前公司并不具备条件,所以废弃了。公司的Kubernetes集群,有专门团队负责运维,我们就针对团队设计了这个安全方案。

Prometheus的二级目录挂载参数如下:
5.png

Grafana的二级目录挂载参数如下:
6.png

Dashboard在Nginx里的配置如下:
7.png

#一个能生成所有软件包的Jenkins Job
在CI流水线实践,我们选用的GitLab作为源代码管理组件,Jenkins作为编译组件。但为了能实现更高效标准的部署交付,公司内部实现一个项目名为prism(棱镜)的自动编译分发部署平台。在容器化时代,衍生出一个Prism4k项目,专门针对Kubernetes环境作CI/CD流程。Prism4k版的构架图如下所示:
8.png

在这种体系下,Jenkins就作为我们的一个纯编译工具和中转平台,高效的完成从源代码到镜像的生成。

由于每个IT应用相关的变量,脚本都已组织好,放到Prism4k上。故而,Jenkins只需要一个Job,就可以完成各样各样的镜像生成功能。其主要Pipeline脚本如下(由于信息敏感,只列举主要流程,有删节):
9.png

在Jenkins中,我们使用了一个Yet Another Docker Plugin,来进行Jenkins编译集群进行Docker生成时的可扩展性。作到了编译节点的容器即生即死,有编译任务时,指定节点才生成相关容器进行打包等操作。
#计算资源在线配置及应用持续部署
在Prism4k平台中,针对Jenkins的Job变量是通过网页配置的。在发布单的编译镜像过程中,会将各个变量通过API发送到Jenkins,启动Jenkins任务,完成指定task任务。
10.png

Pod的实例数,CPU和内存的配置,同样通过Web方式配置。
11.png

在配置好组件所有要素之后,日常的流程就可以基于不同部门用户的权限把握,实现流水线化的软件持续交付。

* 研发:新建发布单,编译软件包,形成镜像,上传Harbor库。
* 测试:环境流转,避免部署操作污染正在进行中的测试。
* 运维:运维人员进行发布操作。

在FAT这样的测试环境中,为加快测试进度,可灵活的为研发人员赋予运维权限。但在更正式的测试环境和线上生产环境,作为金融行业的IT建设标准,则必须由运维团队成员操作。

下面配合截图,了解一下更具体的三大步骤。

  1. 发布单
12.png

在Prism4k与Jenkins的API交互,我们使用了Jenkins的Python库。

  1. 环境流转
13.png


  1. 部署
14.png


在部署操作过程中,会将这次发布的信息全面展示给运维同事,让运维同事可以进行再次审查,减少发布过程中的异常情况。
#总结
由于Kubernetes版本的快速更新和发布,我们对于其稳定性的功能更为青睐,而对于实验性的功能,或是需要复杂运维技能的功能,则保持理智的观望态度。所以,我们对Kubernetes功能只达到了中度使用。当然,就算是中度使用,Kubernetes的运维和使用技巧,还是有很多方面在此没有涉及到,希望以后有机会,能和各位有更多的沟通和交流。愿容器技术越来越普及,运维的工作越来越有效率和质量。
#Q&A
Q:镜像有进行安全扫描吗:
A:外部基本镜像进入公司内部,我们基于Harbor内置的安全功能进行扫描。

Q:Harbor有没有做相关监控,比如发布了多少镜像,以及镜像同步时长之类的?
A:我们没有在Harbor上作扩展,只是在我们自己的Prism4k上,会统计各个项目的一些镜像发布数据。

Q:有没有用Helm来管理镜像包?后端存储是用的什么,原因是?
A:没有使用Helm。目前集群有存储需求时,使用的是NFS。正在考虑建基于Ceph的存储,因为现在接入项目越来越多,不同的需求会导致不同的存储。

Q:想了解下目前贵公司监控的纬度和监控的指标和告警这块。
A:监控方面,我公司也是大致大致划分为基础资源,中间件,业务指标三大块监控。方法论上也是努力在向业界提倡的RED原则靠拢。

Q:想了解下,Yaml文件怎么管理的,可以自定义生成吗?
A:我们的Yaml文件,都统一纳到Prism4k平台管理,有一些资源是可以自定义的,且针对不同的项目,有不同的Yaml模板,然后,透过django的模块功能统一作解析。熟悉Yaml书写的研发同事可以自己定义自己项目的Yaml模板。

Q:Pipeline会使用Jenkinfile来灵活code化Pipeline,把Pipeline的灵活性和创新性还给开发团队,这比一个模板化的统一Pipeline有哪些优势?
A:Pipeline的运行模式,采用单一Job和每个项目自定义Job,各有不同的应用场景。因为我们的Jenkins是隐于幕后的组件,研发主要基于Prism4k操作,可以相对减少研发的学习成本。相对来说,Jenkins的维护人力也会减少。对于研发各种权限比较高的公司,那统一的Job可能并不合适。

Q:想了解下贵公司使用什么网络方案?Pod的网络访问权限控制怎么实现的?
A:公司现在用的是Flannel网络CNI方案。同时,在不同的集群,也有作Calico网络方案的对比测试。Pod的网络权限,这块暂时没有,只是尝试Istio的可行性研究。

Q: 一个Job生成所有的Docker镜像,如果构建遇到问题,怎么去追踪这些记录?
A:在项目前期接入时,生成镜像的流程都作了宣传和推广。标准化的流程,会减少产生问题的机率。如果在构建中遇到问题,Prism4k的界面中,会直接有链接到本次建的次序号。点击链接,可直接定位到Console输出。

Q:遇到节点Node上出现100+ Pod,Node会卡住,贵公司Pod资源怎么做限制的?
A:我们的业务Pod资源,都作了limit和request限制。如果出现有卡住的情况,现行的方案是基于项目作拆分。Prism4k本身对多环境和多集群都是支持的。

Q:多环境下,集中化的配置管理方案,你们选用的是哪个,或是自研的?
A:我们现在正在研发的Prism4k,前提就是要支持多环境多集群的部署,本身的功能里,yaml文件的配置管理,都是其内置功能。

Q:etcd的--initial-cluster-state选项设置为new,重启etcd后会不会创建新的etcd集群?还是加入原有的etcd集群?
A:我们测试过轮流将服务器(3 Master)完全重启,ectd集群的功能均未受影响。但全部关机重启,还未测试过。所以不好意思,这个问题,我暂时没有考虑过。

Q:网络方案用的什么?在选型的时候有没有对比?
A:目前主要应用的还是Flannel方案,今年春节以来,还测试过Flannel、Caclico、kube-router方案。因为我们的集群有可能越机房,而涉及到BGP协议时,节点无法加入,所以一直选用了Flannel。

Q:部署的动态过程是在Jenkins的Web界面上看还是在自研的Prism4k上能看到,如果是Prism4k的话,整个可视化过程的展示这些等等也是自己开发的吗?Prism4k是用什么语言开发的,Python吗?
A:部署的动态过程,是在Prism4k上显示。可视化方案,也只是简单的使用ajax及websocket。Prism4k后端是基于Django 2.0以上开发,其中使用了RESTful framework、channels等库,前端使用了一些js插件。

以上内容根据2019年5月28日晚微信群分享内容整理。分享人陈刚,平安证券运维研发工程师,负责经纪业务IT应用的持续交付平台的设计和开发。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

DevOps时代测试应该如何应对?

阿娇 发表了文章 • 0 个评论 • 173 次浏览 • 2019-05-28 11:12 • 来自相关话题

#背景 DevOps的概念最早起源于2009年的欧洲,但由于当时配套技术和工具的匮乏,导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服务架构理念的深入实践,提倡持续高效的交付使DevOps成为了一种趋势,容器技术 ...查看全部
#背景

DevOps的概念最早起源于2009年的欧洲,但由于当时配套技术和工具的匮乏,导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服务架构理念的深入实践,提倡持续高效的交付使DevOps成为了一种趋势,容器技术又使得DevOps的实施变得相对容易,所以DevOps在各行业各种规模的组织中开始逐步落地实施。

DevOps是Development和Operations的组合词,它是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(Quality Assurance)部门之间的沟通、协作与整合,旨在以高质量持续发布的产品应对瞬息万变的市场需求。DevOps中质量保障贯穿了整个产品的交付周期,是连接开发和运维之间的桥梁。如果没有全面的质量保障和测试策略,就无法实现持续开发和交付。
1.jpg

QA等同于测试么?回答肯定是否定的。QA包含QC(Quality Control)和测试两部分,其主要目标是规划和建立质量评估体系,以确保产品的预期质量;测试是用来验证产品并找到可能缺陷的过程。QA和测试二者相互关联,不可互换与替代。

持续测试作为DevOps的一个关键环节,是产品质量保证最重要的方法,那么传统的测试人员应该如何转型去适应DevOps呢?如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
#传统测试、敏捷测试和持续测试有何不同

传统测试以手工测试为主,对代码级别的测试投入较少,整体呈倒三角模式, 侧重于发现缺陷并修复;敏捷的出现增大了自动化测试的比例,以底层运行速度快、消耗小的单元测试为主,整体呈正三角模式,相比传统测试反馈更及时,修复缺陷的成本低;持续测试在敏捷测试的基础上,强调测试持续进行,通过各部门的协同工作,持续发现缺陷并迅速修复。
2.jpg

传统测试、敏捷测试和DevOps测试

从传统的瀑布型测试到敏捷测试再到DevOps,三者之间具体有什么区别?这一系列的转型对测试提出了什么样的挑战?DevOps中的测试人员需要掌握哪些技能才能做到全面的质量保障?
##传统测试

传统瀑布式软件开发模式中,开发、测试和运维团队之间无协作关系。开发团队负责代码编写和对应的单元测试;测试团队编写手动测试用例并执行,以业务场景测试和系统集成测试为主;QA团队编写自动化测试用例,往往在产品发布前才进行大规模的产品质量验证。

由此可见,传统测试遵循自上而下的顺序方法,产品的质量在测试阶段确定,对产品进行任何更改都非常困难。自动化测试执行效率低,测试用例执行成本高。各部门之间的独立必然导致重复性测试,无法保证全面的产品质量。
##敏捷测试

随着市场需求的加快,传统的瀑布式软件开发模式已经不能够满足频繁的软件交付,敏捷开发模式应运而生。在敏捷测试中,测试不再是一个单独的阶段,它属于迭代计划的一个组成部分,测试人员始终与开发人员保持同步,共同负责产品的质量保障。敏捷提倡频繁且更快地进行测试,因此自动化测试在敏捷测试中至关重要。

从开发到运营的整体流程来看,敏捷模型仅仅融合了开发和测试两个部分,加快了软件开发的频率。但是实际部署到生产环境仍然是由运维团队独立完成,开发和运维之间依然隔着厚厚的一堵墙,繁琐的发布周期使敏捷工作重新回到了瀑布模式。DevOps的出现成功打破了开发和运维之间的隔阂,解决了从开发到部署的这一难题。
##持续测试

持续测试可以看作敏捷测试的进阶版,意味着持续不断的测试,贯穿了整个软件交付周期,包括从需求分析到产品部署的各种测试阶段。持续测试提倡尽早测试、频繁测试和自动化测试。测试与代码开发同时进行,开发人员和测试人员共同分析测试需求,共同编写和维护测试用例,每开发完一项任务就立即运行自动化测试集对交付质量进行验证,从而形成持续验证。代码一旦成功通过了自动化测试集就会立刻部署到生产环境中,进行生产阶段的持续监控。
#DevOps时代的测试应该怎么做

Laurent曾经从测试左移、右移的角度描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时,测试应该如何相应变化。

测试左移,是指测试人员更早地参与到软件项目前期的各项活动中,在功能开发之前定义好相关的测试用例,提前发现质量问题。早期引入测试过程有助于防止缺陷,并为开发人员提供了在整个开发阶段应用动态变更的灵活性。

测试右移,就是直接在生产环境中监控,并且实时获取用户反馈。在这种方法中,从用户侧收集反馈,根据用户反馈持续改进产品的用户体验满意度,提高产品质量。测试右移有助于更好的响应意外情况。

传统测试主要集中在软件开发周期的最后,产品发布之前。为了迎合不断加快的交付频率,越来越多团队的测试活动开始向左右两侧移动。一般问题修复成本较高和面向企业收费的软件,一旦生产环境中出现了问题会造成比较大的损失,通常采取测试左移的方式;对于具有展示功能的软件产品,更容易在生产环境中发现问题,通常采取测试右移的方式。面对测试左右摇摆的问题,小编从以下几个阶段阐述了DevOps中的测试具体应该如何实现。
3.jpg

DevOps中的测试
##用户需求分析

DevOps模式下,与产品相关的所有角色都要参与到用户需求的分析与拆分中,包括开发、测试、运维、产品经理、市场等角色,需全部角色共同确定需求的质量标准和验收条件,并采取BDD(Behavior Driven Development)的方式定义,从而使产品交付流水线上的所有相关人员都能对需求达成一致的理解。
##编码、构建阶段

测试与开发采用TDD(Test-Driven Development)的方式工作,共同分析用户故事、制定验收条件。测试用例与产品开发同步进行和完成,代码一旦开发完会立即通过这些测试套件。这一阶段的测试多以自动化的代码级测试为主,比如单元测试、组件测试、接口/服务级测试等。通常这类的测试不需要启动整个应用程序,运行时间短,从而获得更快的反馈,因此这些测试位于测试套件的前端。
##验收阶段

验收测试用来验证用户需求是否得到了满足,产品是否可以进入部署阶段。制定全面的用户/业务级的验收测试,既验证了软件产品是否交付了用户期望的业务价值,又可以防止回归问题或者缺陷破坏了软件原有的功能。验收测试分为功能验收测试和非功能验收测试。

功能验收测试

功能验收测试运行在类生产环境中,通过模拟用户在真实环境中的操作来验证用户故事是否完成。手工验收测试将代码部署到UAT(User Acceptance Test)环境中,手动模拟用户的操作进行验证;自动化验收测试采用自动化测试工具和应用交付的方式来模拟用户的使用。常见的功能验收测试包括UI(User Interface)测试、集成测试和服务测试等。

非功能验收测试

这一类测试通常运行在特定的环境中,使用的工具类型取决于被测的产品,一般需要花费较长时间和较复杂的环境来运行,所以这类测试一般位于测试套件的后端。常见的非功能验收测试包括容量测试、易用性测试、安全性测试和兼容性测试等满足其交叉功能特性的测试。
##部署阶段(持续监控)

Jez Humble曾指出:“如果真的想获得持续交付的好处,应该尽早将软件产品部署到生产环境中”。代码通过了开发过程中自动化测试套件后,就直接部署到生产环境中,从而获取更直接的反馈。

部署阶段的测试,更准确的说应该叫做生产环境中的监控,从基础监控、应用监控到业务监控,既覆盖了对新功能的可用性测试,也囊括了对已有功能的实时监控,并通过不断的收集用户意见,及时整理、分析并反馈给研发部门,最终实现产品价值的不断提升。常见的监控有两种:一是直接在生产环境上自动运行测试用例;二是通过向生产环境中引入问题来发现产品在生产环境中的潜在问题。
##持续集成(Continuous Integration)

理想的DevOps周期,是从代码开发到生产环境运行的一键部署。显然DevOps非常重视构建、测试和部署的自动化,使用持续集成成为了持续测试的基础。实现持续测试的重要一步,是创建全面的自动化测试套件以在持续集成构建中使用,代码提交后会立刻经过这套自动化测试套件得以验证。常见的自动化测试套件由单元测试、组件检测和验收测试组成,其中每种测试的代码或功能覆盖率至少要达到80%以上才能保证不引入回归问题。
##协作

持续测试的成功实施离不开团队内、团队间及跨团队的协作。新项目从开始就要保证所有成员的共同参与,在协作开发中,开发人员和测试人员在各自的用户故事上并行工作,如开发人员开始编译代码,测试驱动也需跟着启动。代码开发完成就能迅速获取反馈,大大缩短了反馈周期,协同工作也帮助开发人员更好的理解用户故事的真正实现。测试人员同时要积极的参与到持续部署的流程中,在将产品部署到生产环境的过程中跟运维人员做好无缝衔接,尽早制定在生产环境中的监测计划,并根据运维人员的反馈及时调整测试方案。
#对DevOps测试的一些思考

DevOps中质量保证(QA)不再是测试人员的专属责任,而是全体人员都要为之努力的方向。测试人员提前介入到开发工作中,与开发人员一起制定测试计划;开发人员可以参与配置部署;运维人员可以向自动化测试用例库填写测试用例;测试人员随时将自动化测试用例配置到持续交付链中,所有成员的共同目的都是交付高效、高质量的产品。

持续测试要求测试人员具有一定的编码能力。测试人员不但要掌握常用的测试工具、版本控制工具和集成工具的使用,还要能读懂代码,检查构建日志,不断的优化整个测试策略和测试用例。测试人员还必须参与到整个持续交付过程中,以最高效的方式保证产品的质量。

测试人员应该专注于测试策略的不断优化。自动化测试固然是实现持续集成最重要的方式,但并不是所有的测试都适合自动化,比如易用性测试和界面一致性测试等。测试人员需要集中在不断的测试策略优化上,通过调整各种测试用例的比例、增加测试覆盖度、提高测试用例的质量以及快速的反馈来提高测试效率,实现全面的质量保障。

原文链接:https://cloud.tencent.com/developer/article/1423363

从技术雷达看DevOps的十年——基础设施即代码和云计算

阿娇 发表了文章 • 0 个评论 • 169 次浏览 • 2019-05-24 15:27 • 来自相关话题

从技术雷达看DevOps十年——DevOps和持续交付

阿娇 发表了文章 • 0 个评论 • 192 次浏览 • 2019-05-24 15:02 • 来自相关话题

从前端开发人员到DevOps:CI / CD 简介

tiny2017 发表了文章 • 0 个评论 • 274 次浏览 • 2019-05-23 17:45 • 来自相关话题

【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至 ...查看全部
【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至终传递给我们一种持续学习的精神,这一点同样值得我们学习。
# 介绍
对于有抱负的前端开发者而言,2019年是充满憧憬的一年。

有不计其数的教材、课件和教程,每天还有无数的博客和文章,像雨后春笋般层出不穷。任何想成为专业人士的人都可以获得他们需要的一切——通常还是免费的。

许多人抓住这个机会自学成才,而且他们当中很多人有机会参与完整的项目,可以迅速上手写功能模块,修改Bug并以适当的方式组建代码。

经过一段时间,有些比较幸运的前端开发者就会在互联网的某个角落看到他们自己实现的功能模块,作为一个web app、门户或者一个website——对于初级开发者而言,这真的是一个荣耀的时刻。但令人惊讶的是,他们中很少有人会问一个非常重要的问题:我们开发的应用程序,是怎么放到互联网上的?
1.png

大家普遍认为这是由开发人员完成的,只不过是更“高级别”的开发人员而已。可能一些人听说过DevOps,运营商,云管理员,系统管理员以及其他更具神秘气息的东西。

嗯,这是真的——在某种程度上,编码和测试成功后发生的一切通常都和脚本,Linux命令和容器之类的黑科技有关。还有一条不成文的规定是,只有组织中最有经验和最值得信赖的开发人员/管理员才有资格完成最后的交付工作。

有必要这样吗?这确实是有一定道理的——毕竟,这是一项复杂且极其重要的任务。但是否就意味着这些技能只属于某些精英?当然不是。

作为前端开发者,我们可以选择忽略这一切并相信其他人会完成剩下的所有事情——但我们不应该这样。IT世界的竞争瞬息万变,无论是前端还是后端,对于技术栈的点滴积累将会使你成为一名更具竞争力的开发者。

如果你想在开发方面进步的更快或者在同龄人中脱颖而出,你迟早会需要这些知识。下面就让我告诉你为什么你会需要这些知识。
# 为什么开发人员都应该尝试自动化处理
正如我们前面提到的那样,写代码只是软件开发这个浩大的工程的一部分。我们先来看看任何产品交付所需的基本步骤——不一定是软件:
2.png

严格来说,我们在这里讨论的不一定都是编码。我们关注的是主要的开发阶段完成之后会发生什么?为什么它会如此重要?因为它有可能会很复杂 - 解决方案越严谨,这部分就越复杂。

假设有一个具有一些特定功能的Web应用。我们假定该应用的版本会按照一个一个的功能定期发布,前提是发布到生产环境之前,每一个功能都会进行测试。
3.png

问题来了,我们一般不会只招一名程序员来完成这项工作, 即会有一个团队来负责这些功能。这些假设意味着——除了每个开发人员本地的编码环境和最终稳定的生产环境之外——最好还有一个“staging”环境来验证这些功能。在这个环境中,测试人员/客户可以在实际投入生产环境之前评估它们的质量。

现在我们越来越接近这样的架构:
4.png

正如你所看到的,事情变得越来越复杂(相信我,我们在这里谈论的真的是一个非常简单的例子),但我们在这里不会涉及产品生命周期管理,我们只关注技术。

假设前端开发人员需要几分钟来构建一个应用程序。如果关心代码质量,他们需要运行linting,单元测试,集成测试或者用其他的方式确认之后才能提交。这个过程很耗时。

最后,将打包好的程序放到服务器额外还需要几分钟时间。如果我们给一个程序员分配了以上所有这些任务,请记住我们还没有考虑其切换上下文所需的时间(例如,更改代码分支,重新聚焦到他们的工作上等等)。

现在,谁想要手动部署每个功能?如果每天都测试了三个新功能怎么办?如果有15个呢?依据不同的部署规模,很有可能需要一个以上的全职人员来处理上述任务。

这就是为什么我们需要在这里运用计算机诞生之初的思想:我们应该用一台机器来为我们做这件事。
# 持续集成和持续部署的好处
在我们讨论用于构建,测试和部署代码的特定软件解决方案之前,我们先来熟悉一下描述该过程的两个术语。你可能已经听说过它们了:
5.png

注意,通常CD部分代表持续交付,这个概念略有不同,我们将不会在这篇文章中讨论。这种容易引起混淆的缩写通常是许多学术讨论的基础。Atlassian有一篇很棒的文章解释了它们之间的差异。

为什么有两个单独的短语,它们到底是什么意思?不用担心——为了避免混淆,让我们先弄清楚一点,然后描述两者背后的普遍意义。

CI / CD的持续集成部分涵盖了应用程序完整性的重复测试。从技术角度来看,这意味着我们需要不断执行linting,运行unit / E2E测试,检查源代码质量等。通过持续的方式,意味着必须在push新代码之前完成 - 即它应该自动完成。

例如,CI流程中可以定义一系列单元测试,这些单元测试将在拉取代码请求时一起运行。这种情形下,每次更新代码时,例如对于开发分支,一些机器会检查它是否符合标准且没有错误。

CI / CD的持续部署通常涵盖了构建和将应用程序部署到可用环境的一系列过程——这也是自动完成的。例如,它可以从指定的分支(例如:`master`)获取我们的应用程序代码,使用适当的工具(例如webpack)构建,并将其部署到正确的环境(例如,托管服务)。

它并不只限于生产环境;例如,我们可以配置一个Pipeline(管道)来构建应用程序的“staging”版本,并将其部署到适当的主机用于测试。

这两个术语是软件生命周期管理理论中完全不同源的独立概念,但在实践过程中,它们通常以互补的方式共存于一个大型Pipeline(管道)。为什么它们如此密不可分?因为通常CI和CD存在部分重叠。

例如,我们可能有一个项目,E2E测试和部署都需要用webpack构建前端代码。同时,在大多数“严苛”的生产级项目中,还有许多流程既有CI又有CD。

现在让我们想象在一个功能众多的项目中,CI / CD可以做些什么呢?
6.png

我知道越深入这个主题,流程图就越复杂 ——但是,这样一来在项目会议中用白板表示时,就显得很酷!

现在试想一下我们可以从上面的流程中得到些什么呢?我们从因与果的角度来分析,可以通过抽象特定的场景形成假想的工作流程。例如:

一名开发人员尝试push代码到公共代码库,然后需要执行一组单元测试。

通过这种方式,我们可以清晰得知道什么时候开始行动 - 我们可以通过使用脚本或其他机制实现自动化。在将来使用CI / CD的过程中,你可以为这些场景化的Pipeline命名。

注意上面的粗体字:当和然后,每个阶段都需要一个动作触发。为了运行特定的Pipeline,我们需要某种kickstart或触发器。这些可能是:

  • 计时类触发器(“每天下午6点构建staging版本的应用程序”)
  • 代码库触发器(“每次发布新的拉取请求时运行单元测试。”)
  • 手动触发器(“项目经理启动应用程序构建过程并部署到生产环境。”)
当然也可以通过其他的触发器触发特定的Pipeline,尤其是当我们需要通过许多单独构建的部分集成一个复杂应用程序的时候。好吧,理论说的差不多了,现在来说说为我们完成这些工作的软件。# CI / CD中用到的软件基本上,每个CI / CD软件说到底只是某种类型的任务执行工具,当触发某些操作时会运行Job(任务)。我们的主要工作是通过配置的方式提示要完成哪些Job以及何时完成等。基于这些基本描述,CI / CD软件有许多类型,规格和偏好 - 其中一些软件非常复杂以至于手册都有数百页。但也不用害怕:在本文结束之前,你将熟悉其中一个。对新手而言,我们可以把CI / CD软件分为两类:
  • 可安装软件:可以在你的电脑上或某些远程机器上安装的应用程序或服务(例如,Jenkins,TeamCity)
  • SaaS:由一个外部公司通过Web界面的方式提供的应用程序或服务(例如,CircleCI,Azure DevOps)
真的很难说哪一个更具优势,就像本文的主题一样,它取决于应用程序的要求,组织的预算和政策以及其他因素。值得一提的是,一些受欢迎的源代码托管商(例如,BitBucket)会维护自己的CI / CD Web服务,这些服务和源代码管理系统紧密联系,旨在简化配置过程。此外,一些云托管的CI / CD服务是免费且对公众开放的 - 只要该应用程序是开源的就可以。一个广受欢迎的例子就是CircleCI。我们将充分利用它的优势,简单几步就可以为我们的前端应用程序示例配置一个功能齐全的CI / CD的Pipeline。# 前提和计划CircleCI是一个云上的CI / CD服务,它能够与GitHub集成从而轻松获取源代码。该服务有一个有趣的规则:即pipeline在源代码内部定义。这意味着所有的操作和连锁反应都通过在源代码中配置一个特殊文件来实现,在CircleCI中是通过配置`.circleci`文件夹的`config.yml`文件实现的。本文为了实现教学目的,将执行以下操作:
  • 写一个简单的前端应用程序并将源代码公开放在GitHub上
  • 创建并push包含Pipeline的配置文件`config.yml`
  • 创建一个CircleCI帐户并关联GitHub帐户
  • 找一个地方部署应用程序(这里,我们使用Amazon S3的主机托管服务)
  • 最后,运行创建的Pipeline
整个过程不应超过30分钟。接下来,我们来看看准备工作的清单。你需要:# 第一步:环境设置首先,从上述代码库签一个分支并克隆到本地计算机。如果你是新人,可以看下这波操作都做了什么。上述操作执行成功后,跳转到目标目录并执行以下命令:
npm installnpm start
现在打开浏览器输入到http://localhost:8080,你应该看到这样的画面:
7.png
这是一个非常简单的前端应用程序,表明成功加载了`.js`和`.css`文件。你可以查看源代码,它用了一个非常简单的实现机制。当然,你也可以用该教程中使用你自己的应用,只需要适当的修改创建脚本的命令就可以。只要程序是基于npm之类的工具创建的标准应用,应该都没有问题。在使用自动化流程进行持续集成、持续部署之前,需要先构建应用程序并手动存到S3。这样,我们才能保证目标环境的配置没有问题。首先,我们在本地构建应用程序包。如果你使用我们提供的示例程序,就可以用`npm run build`命令来创建,然后在项目的根目录底下得到一个名为`dist`的文件夹:
8.png
好了,我们的应用程序已经构建并打包完毕。你可以在测试服务器上执行`npx serve -s dist`命令查看它的运行情况。这个例子会运行一个`serve`包,它是一个轻量的HTTP服务器,可用来分发`dist`目录下的内容。运行完命令以后可以通过http://localhost:5000查看,你会发现和它在开发环境服务器中的运行结果一致。OK,我们把应用部署到互联网上,这要从S3开始。作为AWS生态圈的一部分,Amazon S3的概念非常简单:它提供了一个存储,可以上传任何类型的文件(包括静态HTML,CSS和JavaScript等)并启用简单的HTTP服务器来分发这些内容。最棒的是(在某些情况下)它是免费的!首先,登录:
9.png
AWS登录步骤1:提供登录用的电子邮箱
10.png
AWS登录步骤2:输入密码接下来,点击服务按钮并在存储项中选择S3,跳转到S3控制面板。
11.png
现在,我们将创建一个新的存储桶来存储我们的Web应用程序。首先,输入名称,名称只支持字母数字字符和连字符。然后,为存储桶选择适当的域。注意要记录这两个值,稍后会用到。
12.png
13.png
有一点非常重要就是设置适当的权限,这样文件才是公开的类型。因此,单击下一步直到出现设置权限选项,然后点击取消前三个框以启用文件的公开托管方式:
14.png
这样,HTTP服务器就能将上传的文件作为网站公开。在设置完存储桶之后,你可以访问并查看文件列表:
15.png
点击上传按钮,系统将提示你选择要上传的文件,你可以从`dist`文件夹中选择三个包文件上传。这里的操作和之前的一样,一定要到设置权限处选择管理公共权限框下的对该对象赋予公共读取权限,这点非常重要。瞧!文件已经在了,最后一步是要在S3上启用托管服务。通过存储桶视图找到属性按钮,打开静态网站托管选项:
16.png
你需要添加`index.html`作为索引文档,它将作为应用程序的入口。现在,一切准备就绪。在对话框的开头会生成一个新站点的链接,点击就可以查看刚才部署的应用:
17.png
太棒了,我们有了一个网站——可惜这不是这次的目标,因为到此为止什么都没自动化。你肯定不希望用这种方式登录S3控制台并在每次更新时上传一堆文件,那是机器要做的事。那么,我们来建一个持续部署的流程吧!# 第二步:准备CircleCI配置如果仔细查看代码库中的示例程序,你会看见一个CD的定义文件,打开`.circleci/config.yml`文件。
version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: trueworkflows:  version: 2.1  build:    jobs:      - build:          filters:            branches:              only: master
如上所述,`config.yml`是CircleCI可识别的文件,它包含了CD过程中定义好的pipeline信息。本文的例子中,26行代码包含了以下的内容:
  • 构建应用程序需要哪些工具
  • 构建应用程序需要哪些命令
  • 应用程序在哪里以及如何部署
如果你不熟悉YAML文件,你会注意到它大量使用制表格式。这就是这类文件的组织结构:每一部分都有子节点,而层次结构由一个有双空格组成的tab标志。现在,我们来逐层看一下文件结构:
version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4
上面几行代码包含了解析器的版本信息,并定义了部署过程中会用到的附属包(CircleCI命名规则中的“orbs”)。在这里,我们需要导入一个名为`aws-s3`的orb ,它包含把文件发送到S3存储桶所需的工具。
jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: true
上面几行代码包含了Job的定义信息,即Pipeline的核心内容。这里要注意的一点是,像上述第二行中所示我们把Job命名为`build`,稍后我们会在CircleCI控制台的报告中看到这个名字。下一行写着`docker`,这部分我们定义创建应用的容器(在哪台虚拟机运行)。如果不熟悉容器或者Docker,这一步你可以想象成选择一台虚拟机然后创建应用。这里,有一台预装了Python和Node.js的Linux虚拟机,我们需要用Python运行AWS S3的工具,用Node创建前端应用。`environment`和`AWS_REGION`是AWS运行用的环境变量,可以不用在意具体的参数。到此,S3就能运行了。下一部分,`steps`更具自描述性。实际上,它是完成Job需要执行的一系列步骤。这部分的示范定义如下:
  • `checkout`:从代码库中获取源代码
  • `run: npm install`:安装依赖包
  • `run: npm run build`:Pipeline的核心,用于构建代码
  • `aws-s3/sync`:另一个重要步骤,它部署(“同步”)S3存储桶中给定的`dist`路径下的内容。注意,这个示例把`demo-ci-cd-article`作为存储桶的名字,你需要修改存储桶名字,使它和示例中的名称一致。

# 解析CircleCI配置
基本上,你可以把它想象成运行在本地的一个包含一组操作的job,这样就是告诉VM一步一步如何完成。当然,你也可以认为它是具备一些特定功能的特殊的shell脚本。

job有一个重要原则那就是每一个步骤都得成功。有任何一个命令失败,就不再执行后续操作,当前的pipeline的状态也会标记为`FAILED`。Job执行失败的信息会在CI / CD控制台中显示,包括相关错误日志,有助于排错。

失败的原因有很多,比方说,对于一个执行自动测试的pipeline,它可能意味着一次单元测试的失败并且某个开发人员需要修复他的代码,或者也有可能是工具的配置有问题,从而导致构建和部署失败。无论是什么原因,CI / CD流程通常会通过电子邮件的方式通知管理员(或本人)执行失败的消息。

这就是为什么要以相对安全的方式定义jobs,以便在执行某一步出错时,确保之前的步骤不会产生任何永久的负面影响。

马上就要结束了,最后一部分是`workflows`:
workflows:
version: 2.1
perform_build:
jobs:
- build:
filters:
branches:
only: master

在CircleCI中“workflow”是一组互相协作的Job。由于之前我们只定义了一个Job(`build`),我们可以暂时不考虑这部分。但是,通过定义工作流的方式可以实现一个很重要的功能:branch filtering(筛选分支)。

你可以看到配置文件中的最后2行定义了`filters`。在这个例子中,它包含了`branches: only: master`,即定义了只有主分支上的代码更新才会执行构建代码Job。

这样就可以通过CI / CD流程筛选出需要“watched(监控)”的分支。例如,可以在不同的分支上调用不同的工作流(包含不同的Job),然后构建单独的版本,或仅在特定情况下测试等。
# 最后一步:CircleCI实践
如果你还没有完成,通过登录GitHub的方式,关联你的GitHub帐户与CircleCI
18.png

登录GitHub并授权给CircleCI后,你会在导航栏看见一个Add Project(添加项目)的选项。点击它可以查看你在GitHub中的代码库列表:
19.png

不管是拷贝的示例还是你自己准备的应用(记住有一个`.circleci/config.yml`文件),先假设你已经有一个代码库了。
然后,在列表中找到该项目后单击旁边的Set Up Project(设置项目)选项。你会看到一个描述CircleCI规则的画面:
20.png

看到底部Start building(开始构建)的按钮了吗?是的,就是它。点击它来启用我们的自动化流程,让机器为我们工作。
点击这个按钮后,你会看到……一个错误提示。
21.png

好吧,我们还需要配置一个地方:让CircleCI API授权给AWS的机制。到目前为止,我们还没有把AWS密码放入代码,GitHub或CircleCI里,所以AWS还不知道我们要把东西放入S3,所以报错。

通过改CircleCI面板中的项目设置来配置。单击右上角的齿轮图标,然后在左边找AWS权限选项卡,你会看到以下画面:
22.png

Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)是AWS的2个鉴权值,用于对CircleCI等第三方服务的鉴权。例如,将文件上传到S3存储桶。最初,这些密钥将具有与分配给它们的用户相同的权限。

你可以通过AWS控制台的IAM生成这些信息。进入IAM,打开访问秘钥Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)】窗口,点击创建新的访问密钥,生成可以复制到CircleCI的密钥对:
23.png

单击Save AWS keys(保存AWS秘钥)就可以了。你可以在CircleCI上尝试重新初始化代码库,也可以用更加快捷的方式:找到失败的报告,然后点击Rerun workflow(重新执行)工作流程按钮。
24.png

现在所有的问题都搞定了,构建应用应该不会再出状况了。
25.png

太棒了!你可以登录S3控制台并检查文件的修改时间,可以证明文件是新上传的。不过还没完事呢,我们来看看“持续”部分是如何工作的。我将返回代码编辑器,说一下应用(`index.html`)的一个小的变动:
26.png

现在,我们可以将代码推送到代码库:
 git add .
git commit -m “A small update!”
git push origin master

神奇的事情发生了。眨眼之间,在成功推送后,CircleCI已经在用更新后的代码构建应用了:
27.png

几秒钟后,会有一条执行`SUCCESS`的消息。现在,你可以刷新一下S3托管的web页面,就可以看到修改后的应用:
28.png

搞定!这一切都是自动执行的:推送完代码后互联网上的一些机器自动构建并部署到生产环境中。
# 进阶练习
当然,这只是一个简单的例子。现在我们来看一个更复杂的例子。例如,部署到多个环境并更改应用。

回到我们的示例代码,你会发现在`package.json`中有两个独立的构建脚本:一个用于`production`环境,一个用于`staging`环境。由于只是一个示例项目,所以不会发生大的变更。这里,它只是用一个不同的JavaScript控制台消息表示而已。

应用在`staging`环境运行之后打开浏览器,你可以在JavaScript控制台看到相应的日志信息:
29.png

现在,我们利用这个机制扩展构建应用的pipelines。请看以下的代码:
version: 2.1
orbs:
aws-s3: circleci/aws-s3@1.0.4
jobs:
build:
docker:
- image: circleci/python:2.7-node
environment:
AWS_REGION: us-east-1
steps:
- checkout
- run: npm install
- run: npm run build
- aws-s3/sync:
from: dist
to: 's3://demo-ci-cd-article/'
arguments: |
--acl public-read \
--cache-control "max-age=86400" \
overwrite: true
build-staging:
docker:
- image: circleci/python:2.7-node
environment:
AWS_REGION: us-east-1
steps:
- checkout
- run: npm install
- run: npm run build:staging
- aws-s3/sync:
from: dist
to: 's3://demo-ci-cd-article/'
arguments: |
--acl public-read \
--cache-control "max-age=86400" \
overwrite: true
workflows:
version: 2.1
build:
jobs:
- build:
filters:
branches:
only: master
build-staging:
jobs:
- build-staging:
filters:
branches:
only: develop

注意,我们添加了一个新的job和一个新的`build-staging`工作流程。有两点不同:新job调用前面提到的
`npm run build:staging`方法,同时用`develop`分支进行筛选。

这意味着所有到`develop`分支的推送都将用“staging”构建,而`master`分支上的所有变更都将保留其原始状态并触发“production”构建。在这里,双方都会在同一个S3存储桶中,但我们可以修改并让它们在相互隔离的目标环境中运行。

可以试一下:基于`master`分支创建一个新的`develop`分支并将代码推送到代码库。在CircleCI控制台,你会看到调用了不同的工作流程:
30.png

相应的变更推送到了S3存储桶,但这次在staging上构建来自`develop`分支的应用,实现了多版本的构建工作。很好,我们马上就能实现之前描述过的工作流程啦!
# 持续集成部分
我们已经完成了持续部署部分的内容,但什么是持续集成呢?正如之前说过的,这部分涉及到定期检查代码的质量,例如:执行测试。

如果仔细看示例的代码库就可以看到有一个单元测试样例,可以用`npm run test`命令执行该测试样例。它通过断言的方式比较了某些模式下虚函数的结果。
function getMessage() {
return 'True!';
}

// ...

module.exports = getMessage;


const getMessage = require('./jsChecker');
const assert = require('assert');

assert.equal(getMessage(), 'True!');

我们可以在管道中加入测试,然后设置成在每个拉取请求时执行就可以。实现方式是在`config.yml`里创建一个新job和一个新的工作流程:

config.yml



version: 2.1
orbs:
aws-s3: circleci/aws-s3@1.0.4
jobs:
build:
# ...
build-staging:
# ...
test:
docker:
- image: circleci/python:2.7-node
steps:
- checkout
- run: npm install
- run: npm run test
workflows:
version: 2.1
build:
# ...
build-staging:
# ...
test:
jobs:
- test

我们已经定义了一个新job和一个名为`test`的工作流程,唯一的目的是触发`npm run test`脚本。然后,将此文件推送到代码库,看一下CircleCI控制台会发生什么:
31.png

一个新的工作流程被自动触发,并完成了一次成功的测试。接下来把它和GitHub的代码库进行对接,这样一来每次拉取特定分支的请求都会触发该job。要实现这一点,只需要打开GitHub页面并到Settings(设置)页面,选择Branches(分支)
32.png

单击Add rule(添加规则),就可以添加一个新的策略。该策略将在合并拉取请求之前强制执行一系列检查,其中一项检查就是调用CircleCI工作流程,如下所示:
33.png

通过勾选Require status checks to pass before merging(合并之前要检查状态)并勾选的`ci/circleci: test`,就可以将规则设置为在拉取前执行该工作流。

该规则可以通过创建一个新的拉取请求来测试,然后打开Checks(检查)面板来查看测试情况:
34.png

当然,也可以测试该规则无效的情况。你可以提交一个会导致测试失败的变更,把它放到一个新分支上并执行一个拉取请求:
35.png

我们模拟了一个失败的测试,输出结果如下:
assert.equal(getMessage(), 'True!');
-->
[quote] node src/modules/jsChecker.test.js
assert.js:42
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: 'True, but different!' == 'True!'
at Object.

现在这个拉取请求将无法合并,因为它引入了导致测试失败的代码:
36.png

赞!我们的示例项目成功覆盖了连续测试的各种情况,只要测试用例没问题,就不可能把错误的代码引入到生产分支。同样的机制还可用于执行代码linting,静态代码分析,E2E测试和其他自动化检查等。[/quote]

好的,就这样!虽然我们的示例项目非常简单,但它展现了真实且有效的CI / CD流程。无论是集成还是部署都由云上的工具执行,所以开发者可以将所有注意力集中到编码上。

无论涉及多少人,机器都将不知疲倦地工作,并检查一切是否到位。虽然设置这一切也需要花费一些时间,但从长远看,把机械性操作进行自动化处理是非常有意义的一件事。

当然,它不是永远的免税天堂:迟早会产生额外的费用。例如,CircleCI每月提供1,000分钟的免费构建。对于小型团队和简单的开源项目来说足够了,但对大型的企业级项目而言肯定会超过这个配额。
# 延伸阅读
我们学习了许多基础的知识,但这篇文章还有许多重要的内容还没来得及讲解。

有一点就是如何更好的使用环境变量。通常我们都不会直接在源代码中保存密码,API密钥和其他敏感信息。当引入CI / CD自动化流程后,首先需要向机器提供适当的变量,就像我们在示例中使用AWS密码一样。

除此之外,环境变量来可以用来控制构建的过程,例如:应该构建哪个或者应该在特定版本中启用哪些特征之类。你可以通过它们在CircleCI中的使用这篇文章中获得更多的信息。

另一个是:许多CI / CD流程引入了组件管理的概念。组件是对特定构建过程中产生的代码的通称。例如,一个包或具有特定版本的应用程序的容器镜像都可以看做组件。

在特定组织中,由于各种原因导致对组件版本的管理变得格外重要。例如:它们可能会被归类和归档以便用于回滚或其他用途。

另一个重要的部分是角色、权限和安全性。这篇文章涉及到定义Pipelines和工作流的基础操作,但在大型、真实的项目中,有必要将组织的流程和策略等考虑在内。例如,我们希望某个Pipeline只能由公司组织架构中的某个人调用或批准。

另一个例子是对特定管道的设置或VM的配置进行细粒度的控制。但同样,这取决于用什么软件以及特定项目或公司的要求,好的自动化流程没有一个单一的范式,就像好的IT项目没有单一的模式一样。
# 总结
好了,言归正传。

不知道这篇文章会让你有什么样的收获?重要的是,现在你已经对一些“重大”的项目中发生的事情有了一个大致的了解。无论使用何种方法和软件,一些基本的规则总是相似的:有任务、管道和代理执行此工作流程。希望通过这篇文章,会让你对许多概念有一个新的认识。最后,你可以试着创建实际工作中用到的CI / CD Pipeline,并用自动化的方式将应用部署到云上。

接下来你还可以做什么呢?

当然,继续扩充你的知识,努力做的更好。如果你正在为公司开发项目,可以尝试写写代码,创建你自己的测试/部署pipeline。你可以(甚至应该)在你的下一个开源项目中引入自动化测试、打包等。您还可以了解更多的CI / CD软件:例如Travis,Jenkins或Azure DevOps。

此外,你还可以查看我的个人资料中与前端开发相关的其他帖子。祝你好运!

原文链接:From front-end developer to a DevOps: An intro to CI/CD (翻译:Tiny Guo)

闲聊我心中的运维开发

aoxiang 发表了文章 • 0 个评论 • 232 次浏览 • 2019-06-03 12:21 • 来自相关话题

#前言 在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。 诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多 ...查看全部
#前言
在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。

诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多:

* 桌面运维工程师
* 业务运维工程师
* DBA工程师
* 配置工程师
* 运维开发工程师
* 以及其它....

1.png

原本准备写篇前端眼中的运维开发,恰巧前组长写了两篇结合自身六七年开发经验写的体会。用他的文章来阐述再合适不过了。以下来自其投稿以及穿插一些知识普及。
#DevOps:打破协作壁垒
来自维基百科:
2.png

DevOps(Development和Operations的组合詞)是一种重视「软件开发人员(Dev)」和「IT运维技术人员(Ops)」之间沟通合作的文化、运动或慣例。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

透过自动化「软件交付」和「架构变更」的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门,在这种环境下如何采用新的开发方法(例如敏捷软件开发),是一个重要的课题。

按照从前的工作方式,开发和部署,不需要IT支持或者QA深入的跨部门的支持;

而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署,它是一套针对这几个部门间沟通与协作问题的流程和方法。
3.png

具体来说,就是在 软件交付和部署过程中提高沟通与协作的效率,旨在更快、更可靠的的发布更高质量的产品。
#运维开发的价值
从岗位职责来看,运维开发要做的工作是:

通过开发技能帮助运维实现运维工作的自动化。说白了就是“辅助”,或者说是运维的臂膀,需要把运维中遇到的问题提供平台查询,或者把一些常见的重复操作给抽象出来做成工具,减少运维的人工介入。
4.png

运维服务伴随并支撑着业务发展的整个生命周期。

而DevOps将运维服务的执行方式升级为更加软件工程化的手段,减少人肉操作,DevOps 强调自动化、拉动式来提高团队交付效率与质量。

而传统的运维需要谋求技术转型,从原来只关注操作系统层面的技术已经不够了,还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升,也需要持续关注整个业务、应用、服务的生命周期管理。

简单来说,就是把过去传统的黑盒运维的思维方式抛弃,进入白盒运维的时代,我们必须更加深入代码、深入业务运营,让整个线上服务运行于更优质高效的状态。
#运维开发是什么?
要建设运维自动化或者实践 DevOps 离不开运维开发工程师的参与,但要怎样才能更好地发挥运维开发的作用呢?

我曾作为运维开发经理的角色和各种类型的运维开发一起协作过,团队中有本来就做运维开发的,也有本来做其他业务(电商、平台)的开发转来协助运维团队的,还有原本是做业务运维后来转型做运维开发的。
和他们协作一段日子后,总体感觉如下:

运维开发首先是一个程序员,不是运维工程师。

一个好的运维开发需要具备 「运维理解」+「开发能力」:

* 对「开发能力」的技术要求低于其他业务形态(如游戏、电商、搜索等)。
* 对运维业务的理解难度会低于电商、游戏等业务形态,即对「运维理解」的要求不高。
* 对运维相关技术栈的掌握程度要求高,如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、Kubernetes等。

5.png

综上所述,运维开发是一个深度不算太深的职业分支,而现在之所以对运维开发需求量热起来了,主要由于老一辈的资深运维普遍研发能力有限,而这是有历史原因的。等到业界提出 DevOps的时候,他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等高级范畴,所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

所以,当我们有自动化系统的建设需求时,需要更专业的程序员来协助。但一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使,这时候有部分年轻的运维工程师升级了研发技能,转型运维开发,把好使的运维系统做出来了,赢得了运维团队的好评,大家都为「运维开发」点赞。

所以,大家将 「好使的运维系统」 和 「运维开发」 等价起来,以为我们只要招来一个运维开发,那么一套完美的运维平台就能自动诞生出来,这是个很大的误区。
#打造「好使的DevOps系统」
其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」,这两种能力也是可以分离的,不一定要强加在运维开发工程师一个人的身上。

类似其他业务形态的开发过程,需要产品经理和程序员两种角色分离,企业也不会说要招聘既会写代码、又会出需求的程序员。

所以,当运维能把运维自动化的需求细致地文档化下来,把自动化系统的设计、架构等关键环节确立下来,这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员,最终就可以得到「好使的运维系统」。

当然, 一般企业不会专门为运维开发配备「产品经理」,所以运维开发想要再往高级发展的话,也可以替代运维出需求,升级为运维产品经理,以程序员的思维角度来解决运维服务的工程效率和质量问题,我认为这也是类似 Google 所提倡的 SRE 文化。
##DevOps平台
编者补充描述。

光说不练假把戏,编者在上家公司的主职就是将DevOps操作界面化。
其中的核心模块:应用部署发布监控。

图为DevOps应用部署发布监控界面图:
6.png

我们组在做上图的DevOps系统时,面临的情况是:无产品、无设计、需求也是靠业务运维和开发们的口头描述。

其中的核心功能:应用部署界面,在参考其它同类产品后,发现都不适合业务场景,要么功能太分散,要么就仅是流程控制。于是前端功能里,我们做了这些:

* 区分不同环境下的包,实现有序管理。
* 应用的状态可以通过界面做启停、查看配置等任务。
* Jenkins服务操作可通过界面完成,简化配置工程师的工作。
* 业务运维与开发团队的日常发包工作界面化。

此时一个优秀的运维开发需具备以下技能:产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。

所以,当运维需求被理解、分析得足够透彻,以及运维开发获得了「产品经理」能力后,运维开发就是一种普通的开发分支,按需求文档编码即可。
#优秀的运维开发
从事DevOps平台开发相关工作已有六七年了,自身经历总结,觉得一个优秀的运维开发工程师应当具备以下能力和素质。
##提高运维意识。
从下到上,从上到下的工作都要做好,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放运维。

运维意识是很重要,并不是你技术很牛,学的技术很多很熟,就不代表你不需要运维意识。

其实领导很看重运维意识的,例如有没有做好备份,权限分配问题,平台测试情况,故障响应时间等,这些都是意识,而不是你学了很多技术自认大牛了,平台发现故障你又没什么大不子,以为很简单的问题喜欢处理就处理,不需要向其它部门反馈等,领导不是看你的技术如何,而是看你的运维意识如何,你没运维意识,技术再牛也没用,只会让其它部门的人跟你不协调。
##了解业务场景
DevOps平台最终服务于运维部和开发测试部同事,因此只有熟悉了解了每一项业务的运维场景,才能更好去设计功能与代码开发,熟悉业务场景才能方方面面考虑周全,开发出来的代码才能满足各类场景应用。
##拒绝重复犯错
人难免会犯错,这是无法避免的,我们应当根据已有的犯错经验,总结犯错的原因,以及如何避免同类情况再次发生,甚至可以把一些典型的错误在团队中分享,把一个人的错误得到的经验传播于整个团队。
##凡事有备份,可回退
运维工作中经常有一些发布,迁移,备份等复杂操作,因此,在研发DevOPs平台的时候,要做好全面的操作计划,思考每一步可能的回退与备份。
##平台操作尽量简化
DevOps平台目的就是为了能够提高运维的工作效率,解放运维,因此在设计与开发的时候,应当保持操作简单,不要让事情变得太复杂,能点一下到位的,尽量不要让人点五六下才能完成操作。
##注重优化用户体验
DevOps开发是一个迭代的过程,虽然我们常说以功能开发为主,但是用户体验也同等重要,试想一下,纵使你开发的功能众多,如果体验不友好,用户便失去了再次使用的欲望,如果用户拒绝,抵触使用平台,做再多功能也是失败,最终平台推广失败。因此,在研发的过程中,我们应当深入体验自己开发的产品,把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。

在设计与开发的过程中经常会碰到复杂,繁琐的场景,这个时候我们很容易失去耐心,我们要时刻提醒自己,必须严格履行自己的工作职责,端正自己的工作态度,做一件事,要么不做,既然做了就要做好:当你想要放弃的时候,想想当初为什么要开始。
#总结
本文是我个人对运维开发以及其职业发展的一些浅薄理解,总的来说,运维开发还是一个比较有意思且有良好发展的职业分支,虽然偶尔也要背黑锅,但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

链接:https://juejin.im/post/5cf29a6ae51d45778f076cd2

火热的云原生到底是什么?一文了解云原生四要素!

阿娇 发表了文章 • 0 个评论 • 240 次浏览 • 2019-05-30 18:33 • 来自相关话题

所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
#云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
1.jpg

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
##云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
2.jpg

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
##云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
3.jpg

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
* 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
#云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
4.jpg

##持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
5.jpg

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
6.jpg

蓝绿(Blue-Green)部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
##微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
7.jpg

Going Agile - Breaking the monolith Conway's Law and Microservices

这样按照组织架构划分的优势在于:

  1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
  2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

  1. 有HA(High Available)的需求需要微服务。
  2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
  3. 经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
##容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
8.jpg

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
9.jpg

容器生态图

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
##DevOps——以终为始,运维合一

10.png

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
#总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

云原生之下的Java

尼古拉斯 发表了文章 • 0 个评论 • 197 次浏览 • 2019-05-30 10:22 • 来自相关话题

自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

DockOne微信分享(二一零):平安证券Kubernetes容器集群的DevOps实践

齐达内 发表了文章 • 0 个评论 • 421 次浏览 • 2019-05-29 11:54 • 来自相关话题

【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同 ...查看全部
【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同行有所借鉴和帮助。
#生产环境的高可用Master部署方案
Kubernetes的高可用Master部署,现在网络上成熟的方案不少。大多数是基于Haproxy和Keepalived实现VIP的自动漂移部署。至于Haproxy和Keepalived,可独立出来,也可寄生于Kubernetes Master节点。

我司在IT设备的管理上有固定的流程,VIP这种IP地址不在标准交付范围之内。于是,我们设计了基于DNS解析的高可用方案。这种方案,是基于Load Balancer变形而来。图示如下:
1.png

这种构架方案,平衡了公司的组织结构和技术实现。如果真发生Master挂掉,系统应用不受影响,DNS的解析切换可在十分钟内指向新的Master IP,评估在可接受范围之内。

公司内部安装Master节点时,使用的基本工具是Kubeadm,但是作了脚本化改造及替换成了自己的证书生成机制。经过这样的改进之后,使用kubeadm进行集群安装时,就更有条理性,步骤更清晰,更易于在公司进行推广。

底层的etcd集群使用独立的Docker方式部署,但共享kubeadm相关目录下的证书文件,方便了api-server和etcd的认证通信。脚本的相关配置如下:
2.png

当以DNS域名的形式进行部署后,各个证书配置认证文件,就不会再以IP形式连接,而是以DNS域名形式连接api-server了。如下图所示:
3.png

#分层的Docker镜像管理
接下来,我们分享一下对Docker镜像的管理。Docker的企业仓库,选用的是业界流行的Harbor仓库。根据公司研发语言及框架的广泛性,采用了三层镜像管理,分为公共镜像,业务基础镜像,业务镜像(tag为部署发布单),层层叠加而成,即形成标准,又照顾了一定的灵活性。

* 公共镜像:一般以alpine基础镜像,加上时区调整,简单工具。
* 业务基础镜像:在公共镜像之上,加入JDK、Tomcat、Node.js、Python等中间件环境。
* 业务镜像:在业务基础镜像之上,再加入业务软件包。

4.png

#Dashboard、Prometheus、Grafana的安全实践
尽管在Kubernetes本身技术栈之外,我司存在体系化的日志收集,指标监控及报警平台,为了运维工具的丰富,我们还是在Kubernetes内集成了常用的Dashboard、Prometheus、Grafana组件,实现一些即时性运维操作。

那么,这些组件部署,我们都纳入一个统一的Nginx一级url下,二级url才是各个组件的管理地址。这样的设计,主要是为了给Dashborad及Prometheus增加一层安全性(Grafana自带登陆验证)。

这时,可能有人有疑问,Dashboard、kubectl都是可以通过cert证书及RBAC机制来实现安全性的,那为什么要自己来引入Nginx作安全控制呢?

在我们的实践过程中,cert证书及RBAC方式,结合SSH登陆帐号,会形成一系列复杂操作,且推广难度高,我们早期实现了这种模式,但目前公司并不具备条件,所以废弃了。公司的Kubernetes集群,有专门团队负责运维,我们就针对团队设计了这个安全方案。

Prometheus的二级目录挂载参数如下:
5.png

Grafana的二级目录挂载参数如下:
6.png

Dashboard在Nginx里的配置如下:
7.png

#一个能生成所有软件包的Jenkins Job
在CI流水线实践,我们选用的GitLab作为源代码管理组件,Jenkins作为编译组件。但为了能实现更高效标准的部署交付,公司内部实现一个项目名为prism(棱镜)的自动编译分发部署平台。在容器化时代,衍生出一个Prism4k项目,专门针对Kubernetes环境作CI/CD流程。Prism4k版的构架图如下所示:
8.png

在这种体系下,Jenkins就作为我们的一个纯编译工具和中转平台,高效的完成从源代码到镜像的生成。

由于每个IT应用相关的变量,脚本都已组织好,放到Prism4k上。故而,Jenkins只需要一个Job,就可以完成各样各样的镜像生成功能。其主要Pipeline脚本如下(由于信息敏感,只列举主要流程,有删节):
9.png

在Jenkins中,我们使用了一个Yet Another Docker Plugin,来进行Jenkins编译集群进行Docker生成时的可扩展性。作到了编译节点的容器即生即死,有编译任务时,指定节点才生成相关容器进行打包等操作。
#计算资源在线配置及应用持续部署
在Prism4k平台中,针对Jenkins的Job变量是通过网页配置的。在发布单的编译镜像过程中,会将各个变量通过API发送到Jenkins,启动Jenkins任务,完成指定task任务。
10.png

Pod的实例数,CPU和内存的配置,同样通过Web方式配置。
11.png

在配置好组件所有要素之后,日常的流程就可以基于不同部门用户的权限把握,实现流水线化的软件持续交付。

* 研发:新建发布单,编译软件包,形成镜像,上传Harbor库。
* 测试:环境流转,避免部署操作污染正在进行中的测试。
* 运维:运维人员进行发布操作。

在FAT这样的测试环境中,为加快测试进度,可灵活的为研发人员赋予运维权限。但在更正式的测试环境和线上生产环境,作为金融行业的IT建设标准,则必须由运维团队成员操作。

下面配合截图,了解一下更具体的三大步骤。

  1. 发布单
12.png

在Prism4k与Jenkins的API交互,我们使用了Jenkins的Python库。

  1. 环境流转
13.png


  1. 部署
14.png


在部署操作过程中,会将这次发布的信息全面展示给运维同事,让运维同事可以进行再次审查,减少发布过程中的异常情况。
#总结
由于Kubernetes版本的快速更新和发布,我们对于其稳定性的功能更为青睐,而对于实验性的功能,或是需要复杂运维技能的功能,则保持理智的观望态度。所以,我们对Kubernetes功能只达到了中度使用。当然,就算是中度使用,Kubernetes的运维和使用技巧,还是有很多方面在此没有涉及到,希望以后有机会,能和各位有更多的沟通和交流。愿容器技术越来越普及,运维的工作越来越有效率和质量。
#Q&A
Q:镜像有进行安全扫描吗:
A:外部基本镜像进入公司内部,我们基于Harbor内置的安全功能进行扫描。

Q:Harbor有没有做相关监控,比如发布了多少镜像,以及镜像同步时长之类的?
A:我们没有在Harbor上作扩展,只是在我们自己的Prism4k上,会统计各个项目的一些镜像发布数据。

Q:有没有用Helm来管理镜像包?后端存储是用的什么,原因是?
A:没有使用Helm。目前集群有存储需求时,使用的是NFS。正在考虑建基于Ceph的存储,因为现在接入项目越来越多,不同的需求会导致不同的存储。

Q:想了解下目前贵公司监控的纬度和监控的指标和告警这块。
A:监控方面,我公司也是大致大致划分为基础资源,中间件,业务指标三大块监控。方法论上也是努力在向业界提倡的RED原则靠拢。

Q:想了解下,Yaml文件怎么管理的,可以自定义生成吗?
A:我们的Yaml文件,都统一纳到Prism4k平台管理,有一些资源是可以自定义的,且针对不同的项目,有不同的Yaml模板,然后,透过django的模块功能统一作解析。熟悉Yaml书写的研发同事可以自己定义自己项目的Yaml模板。

Q:Pipeline会使用Jenkinfile来灵活code化Pipeline,把Pipeline的灵活性和创新性还给开发团队,这比一个模板化的统一Pipeline有哪些优势?
A:Pipeline的运行模式,采用单一Job和每个项目自定义Job,各有不同的应用场景。因为我们的Jenkins是隐于幕后的组件,研发主要基于Prism4k操作,可以相对减少研发的学习成本。相对来说,Jenkins的维护人力也会减少。对于研发各种权限比较高的公司,那统一的Job可能并不合适。

Q:想了解下贵公司使用什么网络方案?Pod的网络访问权限控制怎么实现的?
A:公司现在用的是Flannel网络CNI方案。同时,在不同的集群,也有作Calico网络方案的对比测试。Pod的网络权限,这块暂时没有,只是尝试Istio的可行性研究。

Q: 一个Job生成所有的Docker镜像,如果构建遇到问题,怎么去追踪这些记录?
A:在项目前期接入时,生成镜像的流程都作了宣传和推广。标准化的流程,会减少产生问题的机率。如果在构建中遇到问题,Prism4k的界面中,会直接有链接到本次建的次序号。点击链接,可直接定位到Console输出。

Q:遇到节点Node上出现100+ Pod,Node会卡住,贵公司Pod资源怎么做限制的?
A:我们的业务Pod资源,都作了limit和request限制。如果出现有卡住的情况,现行的方案是基于项目作拆分。Prism4k本身对多环境和多集群都是支持的。

Q:多环境下,集中化的配置管理方案,你们选用的是哪个,或是自研的?
A:我们现在正在研发的Prism4k,前提就是要支持多环境多集群的部署,本身的功能里,yaml文件的配置管理,都是其内置功能。

Q:etcd的--initial-cluster-state选项设置为new,重启etcd后会不会创建新的etcd集群?还是加入原有的etcd集群?
A:我们测试过轮流将服务器(3 Master)完全重启,ectd集群的功能均未受影响。但全部关机重启,还未测试过。所以不好意思,这个问题,我暂时没有考虑过。

Q:网络方案用的什么?在选型的时候有没有对比?
A:目前主要应用的还是Flannel方案,今年春节以来,还测试过Flannel、Caclico、kube-router方案。因为我们的集群有可能越机房,而涉及到BGP协议时,节点无法加入,所以一直选用了Flannel。

Q:部署的动态过程是在Jenkins的Web界面上看还是在自研的Prism4k上能看到,如果是Prism4k的话,整个可视化过程的展示这些等等也是自己开发的吗?Prism4k是用什么语言开发的,Python吗?
A:部署的动态过程,是在Prism4k上显示。可视化方案,也只是简单的使用ajax及websocket。Prism4k后端是基于Django 2.0以上开发,其中使用了RESTful framework、channels等库,前端使用了一些js插件。

以上内容根据2019年5月28日晚微信群分享内容整理。分享人陈刚,平安证券运维研发工程师,负责经纪业务IT应用的持续交付平台的设计和开发。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

从技术雷达看DevOps十年——DevOps和持续交付

阿娇 发表了文章 • 0 个评论 • 192 次浏览 • 2019-05-24 15:02 • 来自相关话题

从前端开发人员到DevOps:CI / CD 简介

tiny2017 发表了文章 • 0 个评论 • 274 次浏览 • 2019-05-23 17:45 • 来自相关话题

【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至 ...查看全部
【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至终传递给我们一种持续学习的精神,这一点同样值得我们学习。
# 介绍
对于有抱负的前端开发者而言,2019年是充满憧憬的一年。

有不计其数的教材、课件和教程,每天还有无数的博客和文章,像雨后春笋般层出不穷。任何想成为专业人士的人都可以获得他们需要的一切——通常还是免费的。

许多人抓住这个机会自学成才,而且他们当中很多人有机会参与完整的项目,可以迅速上手写功能模块,修改Bug并以适当的方式组建代码。

经过一段时间,有些比较幸运的前端开发者就会在互联网的某个角落看到他们自己实现的功能模块,作为一个web app、门户或者一个website——对于初级开发者而言,这真的是一个荣耀的时刻。但令人惊讶的是,他们中很少有人会问一个非常重要的问题:我们开发的应用程序,是怎么放到互联网上的?
1.png

大家普遍认为这是由开发人员完成的,只不过是更“高级别”的开发人员而已。可能一些人听说过DevOps,运营商,云管理员,系统管理员以及其他更具神秘气息的东西。

嗯,这是真的——在某种程度上,编码和测试成功后发生的一切通常都和脚本,Linux命令和容器之类的黑科技有关。还有一条不成文的规定是,只有组织中最有经验和最值得信赖的开发人员/管理员才有资格完成最后的交付工作。

有必要这样吗?这确实是有一定道理的——毕竟,这是一项复杂且极其重要的任务。但是否就意味着这些技能只属于某些精英?当然不是。

作为前端开发者,我们可以选择忽略这一切并相信其他人会完成剩下的所有事情——但我们不应该这样。IT世界的竞争瞬息万变,无论是前端还是后端,对于技术栈的点滴积累将会使你成为一名更具竞争力的开发者。

如果你想在开发方面进步的更快或者在同龄人中脱颖而出,你迟早会需要这些知识。下面就让我告诉你为什么你会需要这些知识。
# 为什么开发人员都应该尝试自动化处理
正如我们前面提到的那样,写代码只是软件开发这个浩大的工程的一部分。我们先来看看任何产品交付所需的基本步骤——不一定是软件:
2.png

严格来说,我们在这里讨论的不一定都是编码。我们关注的是主要的开发阶段完成之后会发生什么?为什么它会如此重要?因为它有可能会很复杂 - 解决方案越严谨,这部分就越复杂。

假设有一个具有一些特定功能的Web应用。我们假定该应用的版本会按照一个一个的功能定期发布,前提是发布到生产环境之前,每一个功能都会进行测试。
3.png

问题来了,我们一般不会只招一名程序员来完成这项工作, 即会有一个团队来负责这些功能。这些假设意味着——除了每个开发人员本地的编码环境和最终稳定的生产环境之外——最好还有一个“staging”环境来验证这些功能。在这个环境中,测试人员/客户可以在实际投入生产环境之前评估它们的质量。

现在我们越来越接近这样的架构:
4.png

正如你所看到的,事情变得越来越复杂(相信我,我们在这里谈论的真的是一个非常简单的例子),但我们在这里不会涉及产品生命周期管理,我们只关注技术。

假设前端开发人员需要几分钟来构建一个应用程序。如果关心代码质量,他们需要运行linting,单元测试,集成测试或者用其他的方式确认之后才能提交。这个过程很耗时。

最后,将打包好的程序放到服务器额外还需要几分钟时间。如果我们给一个程序员分配了以上所有这些任务,请记住我们还没有考虑其切换上下文所需的时间(例如,更改代码分支,重新聚焦到他们的工作上等等)。

现在,谁想要手动部署每个功能?如果每天都测试了三个新功能怎么办?如果有15个呢?依据不同的部署规模,很有可能需要一个以上的全职人员来处理上述任务。

这就是为什么我们需要在这里运用计算机诞生之初的思想:我们应该用一台机器来为我们做这件事。
# 持续集成和持续部署的好处
在我们讨论用于构建,测试和部署代码的特定软件解决方案之前,我们先来熟悉一下描述该过程的两个术语。你可能已经听说过它们了:
5.png

注意,通常CD部分代表持续交付,这个概念略有不同,我们将不会在这篇文章中讨论。这种容易引起混淆的缩写通常是许多学术讨论的基础。Atlassian有一篇很棒的文章解释了它们之间的差异。

为什么有两个单独的短语,它们到底是什么意思?不用担心——为了避免混淆,让我们先弄清楚一点,然后描述两者背后的普遍意义。

CI / CD的持续集成部分涵盖了应用程序完整性的重复测试。从技术角度来看,这意味着我们需要不断执行linting,运行unit / E2E测试,检查源代码质量等。通过持续的方式,意味着必须在push新代码之前完成 - 即它应该自动完成。

例如,CI流程中可以定义一系列单元测试,这些单元测试将在拉取代码请求时一起运行。这种情形下,每次更新代码时,例如对于开发分支,一些机器会检查它是否符合标准且没有错误。

CI / CD的持续部署通常涵盖了构建和将应用程序部署到可用环境的一系列过程——这也是自动完成的。例如,它可以从指定的分支(例如:`master`)获取我们的应用程序代码,使用适当的工具(例如webpack)构建,并将其部署到正确的环境(例如,托管服务)。

它并不只限于生产环境;例如,我们可以配置一个Pipeline(管道)来构建应用程序的“staging”版本,并将其部署到适当的主机用于测试。

这两个术语是软件生命周期管理理论中完全不同源的独立概念,但在实践过程中,它们通常以互补的方式共存于一个大型Pipeline(管道)。为什么它们如此密不可分?因为通常CI和CD存在部分重叠。

例如,我们可能有一个项目,E2E测试和部署都需要用webpack构建前端代码。同时,在大多数“严苛”的生产级项目中,还有许多流程既有CI又有CD。

现在让我们想象在一个功能众多的项目中,CI / CD可以做些什么呢?
6.png

我知道越深入这个主题,流程图就越复杂 ——但是,这样一来在项目会议中用白板表示时,就显得很酷!

现在试想一下我们可以从上面的流程中得到些什么呢?我们从因与果的角度来分析,可以通过抽象特定的场景形成假想的工作流程。例如:

一名开发人员尝试push代码到公共代码库,然后需要执行一组单元测试。

通过这种方式,我们可以清晰得知道什么时候开始行动 - 我们可以通过使用脚本或其他机制实现自动化。在将来使用CI / CD的过程中,你可以为这些场景化的Pipeline命名。

注意上面的粗体字:当和然后,每个阶段都需要一个动作触发。为了运行特定的Pipeline,我们需要某种kickstart或触发器。这些可能是:

  • 计时类触发器(“每天下午6点构建staging版本的应用程序”)
  • 代码库触发器(“每次发布新的拉取请求时运行单元测试。”)
  • 手动触发器(“项目经理启动应用程序构建过程并部署到生产环境。”)
当然也可以通过其他的触发器触发特定的Pipeline,尤其是当我们需要通过许多单独构建的部分集成一个复杂应用程序的时候。好吧,理论说的差不多了,现在来说说为我们完成这些工作的软件。# CI / CD中用到的软件基本上,每个CI / CD软件说到底只是某种类型的任务执行工具,当触发某些操作时会运行Job(任务)。我们的主要工作是通过配置的方式提示要完成哪些Job以及何时完成等。基于这些基本描述,CI / CD软件有许多类型,规格和偏好 - 其中一些软件非常复杂以至于手册都有数百页。但也不用害怕:在本文结束之前,你将熟悉其中一个。对新手而言,我们可以把CI / CD软件分为两类:
  • 可安装软件:可以在你的电脑上或某些远程机器上安装的应用程序或服务(例如,Jenkins,TeamCity)
  • SaaS:由一个外部公司通过Web界面的方式提供的应用程序或服务(例如,CircleCI,Azure DevOps)
真的很难说哪一个更具优势,就像本文的主题一样,它取决于应用程序的要求,组织的预算和政策以及其他因素。值得一提的是,一些受欢迎的源代码托管商(例如,BitBucket)会维护自己的CI / CD Web服务,这些服务和源代码管理系统紧密联系,旨在简化配置过程。此外,一些云托管的CI / CD服务是免费且对公众开放的 - 只要该应用程序是开源的就可以。一个广受欢迎的例子就是CircleCI。我们将充分利用它的优势,简单几步就可以为我们的前端应用程序示例配置一个功能齐全的CI / CD的Pipeline。# 前提和计划CircleCI是一个云上的CI / CD服务,它能够与GitHub集成从而轻松获取源代码。该服务有一个有趣的规则:即pipeline在源代码内部定义。这意味着所有的操作和连锁反应都通过在源代码中配置一个特殊文件来实现,在CircleCI中是通过配置`.circleci`文件夹的`config.yml`文件实现的。本文为了实现教学目的,将执行以下操作:
  • 写一个简单的前端应用程序并将源代码公开放在GitHub上
  • 创建并push包含Pipeline的配置文件`config.yml`
  • 创建一个CircleCI帐户并关联GitHub帐户
  • 找一个地方部署应用程序(这里,我们使用Amazon S3的主机托管服务)
  • 最后,运行创建的Pipeline
整个过程不应超过30分钟。接下来,我们来看看准备工作的清单。你需要:# 第一步:环境设置首先,从上述代码库签一个分支并克隆到本地计算机。如果你是新人,可以看下这波操作都做了什么。上述操作执行成功后,跳转到目标目录并执行以下命令:
npm installnpm start
现在打开浏览器输入到http://localhost:8080,你应该看到这样的画面:
7.png
这是一个非常简单的前端应用程序,表明成功加载了`.js`和`.css`文件。你可以查看源代码,它用了一个非常简单的实现机制。当然,你也可以用该教程中使用你自己的应用,只需要适当的修改创建脚本的命令就可以。只要程序是基于npm之类的工具创建的标准应用,应该都没有问题。在使用自动化流程进行持续集成、持续部署之前,需要先构建应用程序并手动存到S3。这样,我们才能保证目标环境的配置没有问题。首先,我们在本地构建应用程序包。如果你使用我们提供的示例程序,就可以用`npm run build`命令来创建,然后在项目的根目录底下得到一个名为`dist`的文件夹:
8.png
好了,我们的应用程序已经构建并打包完毕。你可以在测试服务器上执行`npx serve -s dist`命令查看它的运行情况。这个例子会运行一个`serve`包,它是一个轻量的HTTP服务器,可用来分发`dist`目录下的内容。运行完命令以后可以通过http://localhost:5000查看,你会发现和它在开发环境服务器中的运行结果一致。OK,我们把应用部署到互联网上,这要从S3开始。作为AWS生态圈的一部分,Amazon S3的概念非常简单:它提供了一个存储,可以上传任何类型的文件(包括静态HTML,CSS和JavaScript等)并启用简单的HTTP服务器来分发这些内容。最棒的是(在某些情况下)它是免费的!首先,登录:
9.png
AWS登录步骤1:提供登录用的电子邮箱
10.png
AWS登录步骤2:输入密码接下来,点击服务按钮并在存储项中选择S3,跳转到S3控制面板。
11.png
现在,我们将创建一个新的存储桶来存储我们的Web应用程序。首先,输入名称,名称只支持字母数字字符和连字符。然后,为存储桶选择适当的域。注意要记录这两个值,稍后会用到。
12.png
13.png
有一点非常重要就是设置适当的权限,这样文件才是公开的类型。因此,单击下一步直到出现设置权限选项,然后点击取消前三个框以启用文件的公开托管方式:
14.png
这样,HTTP服务器就能将上传的文件作为网站公开。在设置完存储桶之后,你可以访问并查看文件列表:
15.png
点击上传按钮,系统将提示你选择要上传的文件,你可以从`dist`文件夹中选择三个包文件上传。这里的操作和之前的一样,一定要到设置权限处选择管理公共权限框下的对该对象赋予公共读取权限,这点非常重要。瞧!文件已经在了,最后一步是要在S3上启用托管服务。通过存储桶视图找到属性按钮,打开静态网站托管选项:
16.png
你需要添加`index.html`作为索引文档,它将作为应用程序的入口。现在,一切准备就绪。在对话框的开头会生成一个新站点的链接,点击就可以查看刚才部署的应用:
17.png
太棒了,我们有了一个网站——可惜这不是这次的目标,因为到此为止什么都没自动化。你肯定不希望用这种方式登录S3控制台并在每次更新时上传一堆文件,那是机器要做的事。那么,我们来建一个持续部署的流程吧!# 第二步:准备CircleCI配置如果仔细查看代码库中的示例程序,你会看见一个CD的定义文件,打开`.circleci/config.yml`文件。
version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: trueworkflows:  version: 2.1  build:    jobs:      - build:          filters:            branches:              only: master
如上所述,`config.yml`是CircleCI可识别的文件,它包含了CD过程中定义好的pipeline信息。本文的例子中,26行代码包含了以下的内容:
  • 构建应用程序需要哪些工具
  • 构建应用程序需要哪些命令
  • 应用程序在哪里以及如何部署
如果你不熟悉YAML文件,你会注意到它大量使用制表格式。这就是这类文件的组织结构:每一部分都有子节点,而层次结构由一个有双空格组成的tab标志。现在,我们来逐层看一下文件结构:
version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4
上面几行代码包含了解析器的版本信息,并定义了部署过程中会用到的附属包(CircleCI命名规则中的“orbs”)。在这里,我们需要导入一个名为`aws-s3`的orb ,它包含把文件发送到S3存储桶所需的工具。
jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: true
上面几行代码包含了Job的定义信息,即Pipeline的核心内容。这里要注意的一点是,像上述第二行中所示我们把Job命名为`build`,稍后我们会在CircleCI控制台的报告中看到这个名字。下一行写着`docker`,这部分我们定义创建应用的容器(在哪台虚拟机运行)。如果不熟悉容器或者Docker,这一步你可以想象成选择一台虚拟机然后创建应用。这里,有一台预装了Python和Node.js的Linux虚拟机,我们需要用Python运行AWS S3的工具,用Node创建前端应用。`environment`和`AWS_REGION`是AWS运行用的环境变量,可以不用在意具体的参数。到此,S3就能运行了。下一部分,`steps`更具自描述性。实际上,它是完成Job需要执行的一系列步骤。这部分的示范定义如下:
  • `checkout`:从代码库中获取源代码
  • `run: npm install`:安装依赖包
  • `run: npm run build`:Pipeline的核心,用于构建代码
  • `aws-s3/sync`:另一个重要步骤,它部署(“同步”)S3存储桶中给定的`dist`路径下的内容。注意,这个示例把`demo-ci-cd-article`作为存储桶的名字,你需要修改存储桶名字,使它和示例中的名称一致。

# 解析CircleCI配置
基本上,你可以把它想象成运行在本地的一个包含一组操作的job,这样就是告诉VM一步一步如何完成。当然,你也可以认为它是具备一些特定功能的特殊的shell脚本。

job有一个重要原则那就是每一个步骤都得成功。有任何一个命令失败,就不再执行后续操作,当前的pipeline的状态也会标记为`FAILED`。Job执行失败的信息会在CI / CD控制台中显示,包括相关错误日志,有助于排错。

失败的原因有很多,比方说,对于一个执行自动测试的pipeline,它可能意味着一次单元测试的失败并且某个开发人员需要修复他的代码,或者也有可能是工具的配置有问题,从而导致构建和部署失败。无论是什么原因,CI / CD流程通常会通过电子邮件的方式通知管理员(或本人)执行失败的消息。

这就是为什么要以相对安全的方式定义jobs,以便在执行某一步出错时,确保之前的步骤不会产生任何永久的负面影响。

马上就要结束了,最后一部分是`workflows`:
workflows:
version: 2.1
perform_build:
jobs:
- build:
filters:
branches:
only: master

在CircleCI中“workflow”是一组互相协作的Job。由于之前我们只定义了一个Job(`build`),我们可以暂时不考虑这部分。但是,通过定义工作流的方式可以实现一个很重要的功能:branch filtering(筛选分支)。

你可以看到配置文件中的最后2行定义了`filters`。在这个例子中,它包含了`branches: only: master`,即定义了只有主分支上的代码更新才会执行构建代码Job。

这样就可以通过CI / CD流程筛选出需要“watched(监控)”的分支。例如,可以在不同的分支上调用不同的工作流(包含不同的Job),然后构建单独的版本,或仅在特定情况下测试等。
# 最后一步:CircleCI实践
如果你还没有完成,通过登录GitHub的方式,关联你的GitHub帐户与CircleCI
18.png

登录GitHub并授权给CircleCI后,你会在导航栏看见一个Add Project(添加项目)的选项。点击它可以查看你在GitHub中的代码库列表:
19.png

不管是拷贝的示例还是你自己准备的应用(记住有一个`.circleci/config.yml`文件),先假设你已经有一个代码库了。
然后,在列表中找到该项目后单击旁边的Set Up Project(设置项目)选项。你会看到一个描述CircleCI规则的画面:
20.png

看到底部Start building(开始构建)的按钮了吗?是的,就是它。点击它来启用我们的自动化流程,让机器为我们工作。
点击这个按钮后,你会看到……一个错误提示。
21.png

好吧,我们还需要配置一个地方:让CircleCI API授权给AWS的机制。到目前为止,我们还没有把AWS密码放入代码,GitHub或CircleCI里,所以AWS还不知道我们要把东西放入S3,所以报错。

通过改CircleCI面板中的项目设置来配置。单击右上角的齿轮图标,然后在左边找AWS权限选项卡,你会看到以下画面:
22.png

Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)是AWS的2个鉴权值,用于对CircleCI等第三方服务的鉴权。例如,将文件上传到S3存储桶。最初,这些密钥将具有与分配给它们的用户相同的权限。

你可以通过AWS控制台的IAM生成这些信息。进入IAM,打开访问秘钥Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)】窗口,点击创建新的访问密钥,生成可以复制到CircleCI的密钥对:
23.png

单击Save AWS keys(保存AWS秘钥)就可以了。你可以在CircleCI上尝试重新初始化代码库,也可以用更加快捷的方式:找到失败的报告,然后点击Rerun workflow(重新执行)工作流程按钮。
24.png

现在所有的问题都搞定了,构建应用应该不会再出状况了。
25.png

太棒了!你可以登录S3控制台并检查文件的修改时间,可以证明文件是新上传的。不过还没完事呢,我们来看看“持续”部分是如何工作的。我将返回代码编辑器,说一下应用(`index.html`)的一个小的变动:
26.png

现在,我们可以将代码推送到代码库:
 git add .
git commit -m “A small update!”
git push origin master

神奇的事情发生了。眨眼之间,在成功推送后,CircleCI已经在用更新后的代码构建应用了:
27.png

几秒钟后,会有一条执行`SUCCESS`的消息。现在,你可以刷新一下S3托管的web页面,就可以看到修改后的应用:
28.png

搞定!这一切都是自动执行的:推送完代码后互联网上的一些机器自动构建并部署到生产环境中。
# 进阶练习
当然,这只是一个简单的例子。现在我们来看一个更复杂的例子。例如,部署到多个环境并更改应用。

回到我们的示例代码,你会发现在`package.json`中有两个独立的构建脚本:一个用于`production`环境,一个用于`staging`环境。由于只是一个示例项目,所以不会发生大的变更。这里,它只是用一个不同的JavaScript控制台消息表示而已。

应用在`staging`环境运行之后打开浏览器,你可以在JavaScript控制台看到相应的日志信息:
29.png

现在,我们利用这个机制扩展构建应用的pipelines。请看以下的代码:
version: 2.1
orbs:
aws-s3: circleci/aws-s3@1.0.4
jobs:
build:
docker:
- image: circleci/python:2.7-node
environment:
AWS_REGION: us-east-1
steps:
- checkout
- run: npm install
- run: npm run build
- aws-s3/sync:
from: dist
to: 's3://demo-ci-cd-article/'
arguments: |
--acl public-read \
--cache-control "max-age=86400" \
overwrite: true
build-staging:
docker:
- image: circleci/python:2.7-node
environment:
AWS_REGION: us-east-1
steps:
- checkout
- run: npm install
- run: npm run build:staging
- aws-s3/sync:
from: dist
to: 's3://demo-ci-cd-article/'
arguments: |
--acl public-read \
--cache-control "max-age=86400" \
overwrite: true
workflows:
version: 2.1
build:
jobs:
- build:
filters:
branches:
only: master
build-staging:
jobs:
- build-staging:
filters:
branches:
only: develop

注意,我们添加了一个新的job和一个新的`build-staging`工作流程。有两点不同:新job调用前面提到的
`npm run build:staging`方法,同时用`develop`分支进行筛选。

这意味着所有到`develop`分支的推送都将用“staging”构建,而`master`分支上的所有变更都将保留其原始状态并触发“production”构建。在这里,双方都会在同一个S3存储桶中,但我们可以修改并让它们在相互隔离的目标环境中运行。

可以试一下:基于`master`分支创建一个新的`develop`分支并将代码推送到代码库。在CircleCI控制台,你会看到调用了不同的工作流程:
30.png

相应的变更推送到了S3存储桶,但这次在staging上构建来自`develop`分支的应用,实现了多版本的构建工作。很好,我们马上就能实现之前描述过的工作流程啦!
# 持续集成部分
我们已经完成了持续部署部分的内容,但什么是持续集成呢?正如之前说过的,这部分涉及到定期检查代码的质量,例如:执行测试。

如果仔细看示例的代码库就可以看到有一个单元测试样例,可以用`npm run test`命令执行该测试样例。它通过断言的方式比较了某些模式下虚函数的结果。
function getMessage() {
return 'True!';
}

// ...

module.exports = getMessage;


const getMessage = require('./jsChecker');
const assert = require('assert');

assert.equal(getMessage(), 'True!');

我们可以在管道中加入测试,然后设置成在每个拉取请求时执行就可以。实现方式是在`config.yml`里创建一个新job和一个新的工作流程:

config.yml



version: 2.1
orbs:
aws-s3: circleci/aws-s3@1.0.4
jobs:
build:
# ...
build-staging:
# ...
test:
docker:
- image: circleci/python:2.7-node
steps:
- checkout
- run: npm install
- run: npm run test
workflows:
version: 2.1
build:
# ...
build-staging:
# ...
test:
jobs:
- test

我们已经定义了一个新job和一个名为`test`的工作流程,唯一的目的是触发`npm run test`脚本。然后,将此文件推送到代码库,看一下CircleCI控制台会发生什么:
31.png

一个新的工作流程被自动触发,并完成了一次成功的测试。接下来把它和GitHub的代码库进行对接,这样一来每次拉取特定分支的请求都会触发该job。要实现这一点,只需要打开GitHub页面并到Settings(设置)页面,选择Branches(分支)
32.png

单击Add rule(添加规则),就可以添加一个新的策略。该策略将在合并拉取请求之前强制执行一系列检查,其中一项检查就是调用CircleCI工作流程,如下所示:
33.png

通过勾选Require status checks to pass before merging(合并之前要检查状态)并勾选的`ci/circleci: test`,就可以将规则设置为在拉取前执行该工作流。

该规则可以通过创建一个新的拉取请求来测试,然后打开Checks(检查)面板来查看测试情况:
34.png

当然,也可以测试该规则无效的情况。你可以提交一个会导致测试失败的变更,把它放到一个新分支上并执行一个拉取请求:
35.png

我们模拟了一个失败的测试,输出结果如下:
assert.equal(getMessage(), 'True!');
-->
[quote] node src/modules/jsChecker.test.js
assert.js:42
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: 'True, but different!' == 'True!'
at Object.

现在这个拉取请求将无法合并,因为它引入了导致测试失败的代码:
36.png

赞!我们的示例项目成功覆盖了连续测试的各种情况,只要测试用例没问题,就不可能把错误的代码引入到生产分支。同样的机制还可用于执行代码linting,静态代码分析,E2E测试和其他自动化检查等。[/quote]

好的,就这样!虽然我们的示例项目非常简单,但它展现了真实且有效的CI / CD流程。无论是集成还是部署都由云上的工具执行,所以开发者可以将所有注意力集中到编码上。

无论涉及多少人,机器都将不知疲倦地工作,并检查一切是否到位。虽然设置这一切也需要花费一些时间,但从长远看,把机械性操作进行自动化处理是非常有意义的一件事。

当然,它不是永远的免税天堂:迟早会产生额外的费用。例如,CircleCI每月提供1,000分钟的免费构建。对于小型团队和简单的开源项目来说足够了,但对大型的企业级项目而言肯定会超过这个配额。
# 延伸阅读
我们学习了许多基础的知识,但这篇文章还有许多重要的内容还没来得及讲解。

有一点就是如何更好的使用环境变量。通常我们都不会直接在源代码中保存密码,API密钥和其他敏感信息。当引入CI / CD自动化流程后,首先需要向机器提供适当的变量,就像我们在示例中使用AWS密码一样。

除此之外,环境变量来可以用来控制构建的过程,例如:应该构建哪个或者应该在特定版本中启用哪些特征之类。你可以通过它们在CircleCI中的使用这篇文章中获得更多的信息。

另一个是:许多CI / CD流程引入了组件管理的概念。组件是对特定构建过程中产生的代码的通称。例如,一个包或具有特定版本的应用程序的容器镜像都可以看做组件。

在特定组织中,由于各种原因导致对组件版本的管理变得格外重要。例如:它们可能会被归类和归档以便用于回滚或其他用途。

另一个重要的部分是角色、权限和安全性。这篇文章涉及到定义Pipelines和工作流的基础操作,但在大型、真实的项目中,有必要将组织的流程和策略等考虑在内。例如,我们希望某个Pipeline只能由公司组织架构中的某个人调用或批准。

另一个例子是对特定管道的设置或VM的配置进行细粒度的控制。但同样,这取决于用什么软件以及特定项目或公司的要求,好的自动化流程没有一个单一的范式,就像好的IT项目没有单一的模式一样。
# 总结
好了,言归正传。

不知道这篇文章会让你有什么样的收获?重要的是,现在你已经对一些“重大”的项目中发生的事情有了一个大致的了解。无论使用何种方法和软件,一些基本的规则总是相似的:有任务、管道和代理执行此工作流程。希望通过这篇文章,会让你对许多概念有一个新的认识。最后,你可以试着创建实际工作中用到的CI / CD Pipeline,并用自动化的方式将应用部署到云上。

接下来你还可以做什么呢?

当然,继续扩充你的知识,努力做的更好。如果你正在为公司开发项目,可以尝试写写代码,创建你自己的测试/部署pipeline。你可以(甚至应该)在你的下一个开源项目中引入自动化测试、打包等。您还可以了解更多的CI / CD软件:例如Travis,Jenkins或Azure DevOps。

此外,你还可以查看我的个人资料中与前端开发相关的其他帖子。祝你好运!

原文链接:From front-end developer to a DevOps: An intro to CI/CD (翻译:Tiny Guo)

DevOps有“政治倾向性”

Zangying2005 发表了文章 • 0 个评论 • 488 次浏览 • 2019-04-14 18:23 • 来自相关话题

我在这里断言:很多人都认为技术及技术相关部分,本质上与政治无关。但事实并非如此。在接下来的10分钟里,我会试着证明我的观点,希望其中的有些观点可以取得大家的认同。 进一步澄清一下:我所说的政治,并不是类似于“我投票给绿党!”或者“我是 ...查看全部
我在这里断言:很多人都认为技术及技术相关部分,本质上与政治无关。但事实并非如此。在接下来的10分钟里,我会试着证明我的观点,希望其中的有些观点可以取得大家的认同。

进一步澄清一下:我所说的政治,并不是类似于“我投票给绿党!”或者“我是自由主义者!”的政治。而且从组织的角度来看,我们愿意因为某些考虑,而做出一些权衡。
图片_1.png

需要权衡或称为分歧的关键是:我们所创造的技术是我们内在信仰系统的一种表达。如何构建事物是以一种非凡的方式来展现我们内在的价值体系。
# DevOps是非范式的
DevOps这个词流传甚广,对它的理解也因人而异。Jez Humble将其定义为一种系统的操作方式,所操作的系统具有快速变更的特征,例如I.E.,CI/CD,快速反馈环等。还有人将它定义成操作人员,他们使用开发人员的模式来更加快速的运行和部署应用。但在很大程度上的事实却是:存在一种伪共识,认为DevOps与开启组织敏捷性有关系。却没有提及敏捷对不同的组织会意味着不同的东西。

从组织的角度来看,我认为DevOps没有规范的实现方法。如果这么说有点难以理解的话,让我进一步展开。因为语言对不同的人有不同的含义,所以我要在这里做些说明,概述一下我所说的“不同的实现”是什么意思,但不提供我个人的观点。一个组织通常有以下几个关键点:

团队管理的基础设施 VS 集中式管理基础设施

团队有自己的基础设施吗?还是有人在中间专门提供运行?
图片_2.png

如果是前者,开发团队是否必须学习运维?意味着开发人员是否要对自己的基础设施负责?他们是否需要随时保持响应?他们是否可以以任何想要的方式运行他们的应用?

而如果是后者,那么是否意味着有一个专职的操作团队?意味着开发人员是否只需关注自己的应用?那非工作时间的应用支持怎么办呢?换个角度,如果不清楚问题的根源是应用程序还是基础设施时,怎么办呢?

选择一种技术时,存在组织预设和指引吗?您的组织是否偏好某一组特定的技术?
图片_3.png

如果组织没有任何预设意见,是否意味着团队可以运行任何想要的东西?如果是这样,是否有一种机制确保任何人都知道每个人在做什么?当外部团队从安全性或可用性的角度影响了某个服务时,如何看待责任问题?

如果组织有某些预设意见,如何判断一个团队是否可以偏离?如果一个团队决定偏离,决策人员是否有足够的上下文信息(业务和技术)来做出决策?我们又如何确定以上的信息?

如果组织有特定的要求,这是否意味着有业务单元会在更新、更好的技术选择上进行创新?如果是,他们可获得足够的支持吗?相反,其他团队的交付速度是否会成为瓶颈?

以上选项信息,我们会根据我们认可的价值和对事物的评价选择其中的某个选项。
# 没有正确的选择,只有深思熟虑后的结果
我很抱歉不能在此给出一个解决方案,我能够且愿意提供的最好意见是深思熟虑。在选择一种或另一种方法时,都需要慎重考虑多个因素——在理想的情况下,所做的选择都是透明的和经过考虑的。然而,在大多数情况下,它们都是偶然的或随机的。

因为选择都是由人决定的,所以,选择往往受限于决策人知道多少以及知道哪些部分。也许他们所在的公司选择了一条不成功的道路。也许他们已经在这个组织工作多年,并且经历了其他所有方法都失败了(直接或间接的)。

选择受限于人际关系,尽管我很讨厌这么说。但人们更倾向于听信于和自己关系好或相处融洽的人。“我更喜欢和不会给我带来压力的人在一起。我们交谈的频率以及交谈的对象影响着自己的决定。”我在某种程度上,对此表示同情。

选择受限于我们的个人倾向,通常会坚持自己的观点。我想将有强烈感的观点和能严格控制的观点区分开来。完全有可能有选择某个观点的强烈感,但一旦有足够的证据支持它,就可以理解为能严格控制的观点,而选择这个观点。

选择还受限于组织内部的价值体系。如果我们允许团队管理自己的基础设施,这是否意味着我们信任他们?如果我们不这样做,是否意味着我们希望团队能够安全地部署应用?

综上所述,选择会因人而异,由我们所掌握的知识,我们周围的人,以及我们改变立场的能力来决定。最终选择的结果都是基于我们的个人信仰体系。这听起来很像政治。
# 这听起来并不新奇
这个主题的不同方面以前都讨论过,可能有更好的方法来阐述这个事实。如康韦定律说,一个组织创建的软件是该组织通信模式的一个提喻。Edgar Schein认为,我们的价值观影响着我们的文化,而文化又影响着我们所创造的人工制品。
图片_4.png

Andrew Cosgriff曾经反复地痛苦地表达:一切都是一种权衡。

我想说的唯一一件事是:在我们开始谈话之前,我们要敏锐地意识到以下这些因素:
#这意味着什么?
我知道我并没有给出一个固定前进的路径,但是我认为DevOps的“政治倾向”意味着有些事情非常重要。

强烈的观点,松散的把控。有强烈的观点并没有错。它鼓励我们去告诉自己,用知识武装自己,这样我们就能捍卫自己的观点。但当我们在面对相反的证据时不放弃我们的想法,或者我们在选择事实时变得有选择性时(“架构Y很好地应用于X公司,所以它在其他地方应用也没有问题!”)强烈的观点就不再强烈啦。

同理心就是一切。“他者化”描述的是将他人贴上不属于这个群体标签的粗暴行为。对方也存在同样的心理。例如:“别听索尔的,他说了那么多废话。”这将产生排斥的效果,让我们在理解他人的观点时,无形中就带入了偏见。在DevOps的上下文中,很容易陷入自动忽略对立阵营观点的趋势,而不是将他们的观点理解为对方汇集经验的结果,甚至可能会质疑这些经验。

持续的沟通是关键。意见必须经过考验、公开发表和公开辩护。当我们社会中那些更应该受到谴责的部分拥有了同等的支持空间时,真理才会繁荣起来;这也会影响其他人——包括那些还没有下定决心的人(骑墙派)。

不要试图做出正确的选择,而是尽量选择深思熟虑后的结果。至少,在DevOps上下文中,没有最终正确的选择,这实在是太难啦!我们必须努力确保我们的选择中,那些因素是被公平对待,没有裙带关系,要谨记自己的偏见。

在一个没有客观“正确”做事方式的世界里,我们能做的最好的事情就是确保我们被外界所告知:我们是公平的,我们保持谦虚,并一直互惠彼此。
图片_5.png


原文链接:DevOps is political.(翻译:易理林)

Devops入门手册

明远 发表了文章 • 0 个评论 • 700 次浏览 • 2019-04-09 18:21 • 来自相关话题

# DevOps 是什么? “DevOps”这个词是 `Development` 和 `Operations` 这两个词的组合。它是一种促进开发和运维团队之间的协作,以自动化和可重复的方式更快地将代码部署到生产中的文化。 ...查看全部
# DevOps 是什么?
“DevOps”这个词是 `Development` 和 `Operations` 这两个词的组合。它是一种促进开发和运维团队之间的协作,以自动化和可重复的方式更快地将代码部署到生产中的文化

DevOps 帮助团体提高软件和服务的交付速度。它使团队能够更好地为客户服务,并提高在市场中的竞争力。

简而言之, DevOps 可以定义为通过更好的沟通和协作,使开发和运维保持一致。
01.png

# 为什么需要 DevOps ?

  • 在实行 DevOps 之前,开发和运维团队是完全孤立的。
  • 测试和部署是设计在构建之后完成的独立活动。因此,他们比实际构建周期消耗更多时间。
  • 在不使用 DevOps 的情况下,团队成员将大量时间花在测试,部署和设计上,而不是构建项目。
  • 手动部署代码会导致生产中出现人为错误。
  • 开发和运维团队都有各自的时间表,时间的不同步导致生产交付进一步延误。
提高软件交付率是业务方最迫切的需求。根据 Forrester Consulting Study 统计,只有17%的团队可以足够快地交付软件。更是证明了这一痛点。## DevOps 与传统运维有什么不同?让我们将传统软件瀑布开发模型与 DevOps 进行比较,以了解 DevOps 带来的变化。我们假设有一个应用程序计划在2周内上线,代码完成80%。该应用程序是一个新的发布,从购买服务器开始。
B1.png
# 为什么使用 DevOps ?DevOps 允许敏捷开发团队实施持续集成和持续交付。这有助于他们更快地将产品推向市场。其他重要原因是:[list=1]
  • 可预测性:DevOps 可以显着降低新版本的故障率。
  • 自愈性:可以随时将应用回滚到较早的版本。
  • 可维护性:在新版本崩溃或当前系统不可用的情况下,可以毫不费力地进行恢复。
  • 上线时间:DevOps 通过简化软件交付流程将上线时间缩短至50%。对于互联网和移动应用时间更短。
  • 更高的质量:DevOps 帮助团队提高应用程序开发的质量。
  • 降低风险:DevOps 在软件交付的生命周期中包含安全检查。它有助于减少整个软件生命周期中的安全风险。
  • 弹性:软件系统的运行状态更稳定,更安全,更改是可审计的。
  • 成本效益:DevOps 在软件开发过程中提供了成本效益,这始终是互联网公司管理层所期望的。
  • 将大的代码库分成小块:DevOps 是基于敏捷编程方法的。因此,它允许将大的代码库分解为更小且易于管理的块。
  • ## 什么时候使用 DevOps ?DevOps 应该用于大型分布式应用程序,例如电子商务站点或托管在云平台上的应用程序。## 什么时候不使用 DevOps?它不应该用于关键任务应用程序,如银行,电力设施和其他敏感数据站点。此类应用程序需要对生产环境进行严格的访问控制,详细的变更管理策略,完善的数据中心访问控制策略。# DevOps 的生命周期
    02.png
    DevOps 是开发和运维之间的深度集成。在不了解 DevOps 生命周期的情况下,是无法真正理解 DevOps 的。以下是有关 DevOps生命周期的简要信息:[list=1]
  • 开发,在此阶段,整个开发过程分为小的开发周期。这有利于 DevOps 团队加快软件开发和交付过程。
  • 测试,QA 团队使用 `Selenium` 等自动化测试工具来识别和修复新代码中的错误。
  • 集成,在此阶段,新功能与主分支代码集成,并进行测试。只有持续集成和测试才能实现持续交付。
  • 部署,在此阶段,部署过程持续进行。它的执行方式是任何时候在代码中进行的任何更改都不应影响高流量网站的运行。
  • 监测,在此阶段,运维团队将负责处理不合适的系统行为或生产中发现的错误。
  • # DevOps 的工作流
    03.png
    工作流允许排列和分离用户最需要的任务。它还能够在配置任务时反应其最理想过程。# DevOps 与敏捷有什么不同? DevOps VS Agile这是一个典型的IT流程。
    04.png
    敏捷解决了客户和开发人员沟通中的问题。
    05.png
    DevOps 解决了开发人员运维人员沟通中的问题。
    06.png
    B2.png
    # DevOps 原则这里有六个在采用 DevOps 时必不可少的原则:[list=1]
  • 以客户为中心:DevOps 团队必须以客户为中心,因为是他们不断向我的产品和服务投资。
  • 端到端的责任:DevOps 团队需要在产品的整个生命周期提供性能支持。这提高了产品的水平和质量。
  • 持续改进:DevOps 文化专注于持续改进,以尽量减少浪费。它不断加快产品或服务改进的速度。
  • 自动化一切:自动化是 DevOps 流程的重要原则。这不仅适用于软件开发,同时也适用于整个基础架构环境。
  • 作为一个团队工作:在 DevOps 文化角色中,设计人员,开发人员和测试人员已经定义。他们所需要做的就是作为一个团队完成合作。
  • 监控和测试所有内容:DevOps 团队拥有强大的监控和测试程序是非常重要的。
  • # 谁可以做 DevOps 工程师?DevOps 工程师是一名IT专业人员,他与软件开发人员,系统运维人员和其他IT人员一起管理代码发布。DevOps 应具备与开发,测试和运维团队进行沟通和协作的硬技能和软技能。DevOps 方法需要对代码版本进行频繁的增量更改,这意味着频繁的部署和测试方案。尽管 DevOps 工程师需要偶尔从头开始编码,但重要的是他们应该具备软件开发语言的基础知识。DevOps 工程师将与开发团队的工作人员一起解决连接代码的元素(如库或软件开发工具包)所需的编码和脚本。# DevOps 工程师的角色、职责和技能DevOps 工程师负责软件应用程序平台的生产和持续维护。以下是 DevOps 工程师的一些角色,职责和技能:
    • 能够跨平台和应用程序域执行系统故障排除和问题解决。
    • 通过开放的,标准的平台有效管理项目。
    • 提高项目可见性和可追溯性。
    • 通过协作提高开发质量并降低开发成本。
    • 分析、设计和评估自动化脚本和系统。
    • 通过使用最佳的云安全解决方案确保系统的安全。
    • DevOps 工程师应该具备问题解决者和快速学习者的软技能。
    # DevOps 工程师可以挣多少钱?DevOps 是最热门的IT专业之一。这就是为什么那里都有很多机会的原因。因此,即使是初级 DevOps 工程师的薪酬水平也相当高。在美国,初级 DevOps 工程师的平均年薪为78,696美元。# DevOps 培训认证DevOps 培训认证可以帮助任何渴望成为 DevOps 工程师职业的人。认证可从 Amazon web services、Red Hat、Microsoft Academy、DevOps Institute 获得。AWS Certified DevOps Engineer此 DevOps 工程师证书将测试您如何使用最常见的 DevOps 模式在 AWS 上开发,部署和维护应用程序。它还会评估 DevOps 方法的核心原则。该认证有两个必要条件:认证费用为300美元,持续时间为170分钟。Red Hat Certification红帽为 DevOps 专业人士提供不同级别的认证,如下所示:
    • Red Hat Certificate of Expertise in Platform-as-a-Service
    • Red Hat Certificate of Expertise in Containerized Application Development
    • Red Hat Certificate of Expertise in Ansible Automation
    • Red Hat Certificate of Expertise in Configuration Management
    • Red Hat Certificate of Expertise in Container Administration
    Devops InstituteDevops Institute是围绕新兴 DevOps 实践的全球学习社区。该组织正在为 DevOps 能力资格设置质量标准。Devops Institute目前提供三个课程和认证。公司提供的认证课程有:
    • DevOps Foundation
    • DevOps Foundation Certified
    • Certified Agile Service Manager
    • Certified Agile Process Owner
    • DevOps Test Engineering
    • Continuous Delivery Architecture
    • DevOps Leader
    • DevSecOps Engineering
    # DevOps 自动化工具所有测试流程自动化并对其进行配置以实现至关重要的速度和灵活性。此过程称为 DevOps 自动化。维护庞大的IT基础架构的大型 DevOps 团队面临的困难可以简要分为六个不同的类别。[list=1]
  • 基础设施自动化
  • 配置管理
  • 部署自动化
  • 性能管理
  • 日志管理
  • 监测
  • 让我们看看每个类别中的工具以及它们如何解决痛点:## 基础设施自动化亚马逊网络服务(AWS):作为云服务,您无需建立实际的数据中心。此外,它们易于按需扩展。没有前期硬件成本。它可以配置为自动根据流量配置更多服务器。## 配置管理Chef:它是一个有用的 DevOps 工具,用于提升速度,规模和一致性。它可用于简化复杂任务并执行配置管理。使用此工具,DevOps 团队可以避免在一万台服务器上进行更改。相反,只需要在一个地方进行更改,这些更改会自动反映在其他服务器中。## 部署自动化Jenkins:该工具有助于持续集成和测试。通过在部署构建后快速查找问题,更​​轻松地集成项目更改。## 日志管理Splunk:可以解决在一个地方聚合,存储和分析所有日志的问题的工具。## 性能管理App Dynamic:它是一个 DevOps 工具,提供实时性能监控。此工具收集的数据可帮助开发人员在发生问题时进行调试。## 监控Nagios:在基础架构和相关服务出现故障时通知相关人员也很重要。Nagios 就是这样一种工具,它可以帮助 DevOps 团队找到并纠正问题。# DevOps 的未来是怎样的?
    • 团队将代码部署周期转换为数周和数月,而不是数年。
    • 很快就会看到,DevOps 工程师可以比企业中的任何其他人更多地接近和管理终端用户。
    • DevOps 正在成为IT人员的重要技能。例如,Linux 招聘进行的一项调查发现,25%的受访者的求职者寻求 DevOps 工作。
    • DevOps 和持续交付将继续存在。因为公司需要发展,他们别无选择,只能改变。然而,DevOps 概念的主流化则需要5到10年。
    # 总结
    • DevOps 是一种促进开发和运维团队之间的协作,以自动化和可重复的方式更快地将代码部署到生产中的文化
    • 在 DevOps 出现之前运维和开发团队完全独立。
    • 手动部署代码会导致生产中出现人为错误。
    • 在旧的软件开发流程中,运维团队不了解开发团队的进度。因此,运维团队只能根据他们自己的理解制定了基础设施的购买和监控计划。
    • 在 DevOps 流程中,运维团队充分了解开发人员的进度。采购和监控计划准确无误。
    • DevOps 提供可维护性,可预测性,更高质量的代码和更准确的上线时间。
    • 敏捷流程侧重于功能和非功能准备,而 DevOps 则侧重于IT基础架构方面。
    • DevOps 生命周期包括开发,测试,集成,部署和监控。
    • DevOps 工程师将与开发团队工作人员合作,以解决编码和脚本编写需求。
    • DevOps 工程师应该具备问题解决者的软技能,并且是一个快速学习者。
    • DevOps 认证可从 Amazon web services,Red Hat,Microsoft Academy,DevOps Institute 获得
    • DevOps 可帮助团队将代码部署周期转换为数周和数月,而不是数年。

    原文链接:DevOps Tutorial: Complete Beginners Training(翻译:郭旭东)

    DockOne微信分享(二零三):骞云科技DevOps实践

    JetLee 发表了文章 • 0 个评论 • 865 次浏览 • 2019-02-28 22:23 • 来自相关话题

    【编者的话】随着公司业务的快速发展,需要加快开发流程的规范化和自动化,以提高产品的开发效率和交付效率。之前的开发测试和资源管理主要是半自动化的,个人生产力和资源利用率仍有很大提升空间。在DevOps的具体实践中,一方面, Gerrit + GitLab + J ...查看全部
    【编者的话】随着公司业务的快速发展,需要加快开发流程的规范化和自动化,以提高产品的开发效率和交付效率。之前的开发测试和资源管理主要是半自动化的,个人生产力和资源利用率仍有很大提升空间。在DevOps的具体实践中,一方面, Gerrit + GitLab + Jenkins + CMP(Ansible)共同构建了更好的 CI/CD 流程,对自动化持续交付流水线进行了优化;另一方面,CMP(Self-Service Portal)帮助建立了自服务自运维门户,公司所有人员都可以通过统一的门户自助申请各类资源,并自助完成日常运维。
    #为什么我们要加强 DevOps?

    在公司创立早期,为了尽快实现产品从0到1的转化,我们将更多的资源投入到了产品的新功能开发上,在产品开发自动化方面的投入并不高。
    随着公司业务的迅速发展,一方面,团队规模不断扩大,服务器资源也越来越多;另一方面,产品的功能逐渐丰富,开发代码工程数和分支数增加,而开发测试和资源管理仍以半自动化为主。

    面临的问题:
    ##人力资源浪费

    手工打包、手工创建虚机、手工部署、手工升级、较低程度的自动化测试,这些重复且低效的开发测试模式导致开发测试人员不能将宝贵的时间用于更加有创造力的工作上,不利于个人和公司的快速发展。
    ##IaaS资源管理混乱

    我们的开发测试环境主要构建在内部的vSphere和OpenStack云台上,当然也会在Aliyun、AWS、Azure等公有云上创建资源。在日常工作过程中,我们经常会听到这样的声音:“我的环境怎么这么卡”、“阿里云上又没钱啦”、“OpenStack上的机器我要删了啊”、“谁删了我的机器,我的数据还在上面呢”。由于没有权限控制导致资源随意创建,资源不及时释放导致大量资源闲置和浪费,另外还存在资源误删除情况。
    ##内部系统运维成本居高不下

    我们没有专职的内部系统运维人员,平时开发过程中,遇到CPU/Memory调整、磁盘物理卷/逻辑卷扩容、操作系统故障、应用故障等一系列问题都会占用研发人员大量的时间和精力。
    ##产品交付难度大

    为满足稳定性、高可用性、可扩展性等交付需求,我们的产品在软件架构设计上具有较高的复杂度,这样一来安装部署实施的难度也就比较大。售前团队到客户现场做POC,想要快速部署一套公司产品比较困难;售后团队在项目交付的过程中也经常遇到各种各样的安装配置问题。

    基于上述问题,我们希望通过对DevOps工作流程进行改造和增强,以提高产品开发效率和交付效率,以及提升个人生产力和资源利用率。
    #DevOps整体规划

    我们将DevOps工作流程改造分为了两个方面,一个是对CI/CD工作流的优化,一个是搭建自服务自运维门户。
    ##CI/CD目标


    * 所有代码工程能够自动化打包
    * 所有代码提交后能够自动构建编译检查以及单元测试任务
    * 每小时完成一次软件集成、部署以及核心功能的集成测试(API&UI)
    * 每天完成一次完整功能的集成测试(API&UI)
    * 每周完成一次7x24小时Longrun系统测试
    * 自动更新经过测试的nightly build到开发测试环境
    * 自动发布经过测试的weekly build到Demo环境

    ##自服务自运维目标

    公司所有人员,都可以通过一个统一门户Portal,自助申请各种类型的IaaS资源,如: x86物理服务器、vSphere虚拟机、OpenStack虚拟机、Kubernetes上的容器服务,以及Aliyun、AWS、Azure等公有云上的云资源;自助申请日常开发所需的软件应用,如:Nginx、Tomcat、MySQL、RabbitMQ,以及SmartCMP等。

    * 开发Dev,测试QA,售前交付需要使用不同的资源,做到资源隔离;
    * 资源的使用需要有权限控制;
    * 需要能够一键部署单节点和HA多节点应用系统;
    * 提供环境自动初始化,一键升级能力;
    * 提供系统和应用级别的监控告警;
    * 资源需要能够定期回收。

    #构建更好的CI/CD流程

    ##概述

    我们的DevOps工具链由 GitLab、Gerrit、Jenkins、CMP 构成。

    * GitLab:代码托管
    * Gerrit:代码审查
    * Jenkins:单元测试、自动化打包、集成测试
    * CMP:vSphere、OpenStack、Kubernetes等云资源统一管理,应用系统自动化部署,版本更新

    具体的工作流如下图所示:
    01.png

    开发人员提交代码后,触发Jenkins完成代码编译检查和单元测试,Jenkins返回代码检查结果给Gerrit,人工Review后merge代码,触发Jenkins完成该项目的打包。Jenkins定时完成各个工程的集成打包,然后通过调用CMP的API触发自动化部署,部署完成后进行场景化的集成测试,测试完成后卸除资源。
    02.png

    ##持续集成(Jenkins)

    起初我们使用GitLab Runner实现CI,在每个代码工程中添加“.gitlab-ci.yaml”文件,不同项目各自创建和维护自己的.gitlab-ci.yaml脚本,这样的实现可以解决各自工程的编译测试和打包问题,在代码工程数量较少时,我们也使用了较长一段时间。

    现在我们的代码工程数量已超过20个,每个代码工程都设置了访问权限,如果需要专人维护CI脚本的话,那他需要能够访问所有代码工程,显然这样是不合理的,而且把集成打包脚本放在哪个工程里都不合适。

    考虑到Jenkins有强大的CI能力:通过安装插件就能快速与Gerrit、GitLab集成,能够参数化执行各种类型的脚本。所以,我们使用Jenkins代替gitlab-runner完成CI,通过Jenkins可以统一管理各个工程的编译、测试、打包,而且比较方便构建流水线完成较多工程集成打包及测试。
    03.png

    ##持续部署(Ansible)

    我们的产品由20多个服务组成,可部署在一个或多个虚拟机上,使用Shell脚本或Python脚本已经很难完成这么多服务程序的自动化安装部署配置。

    恰巧团队有使用Ansible做复杂系统部署的经验,Ansible的学习成本也较低,所以我们选择使用Ansible Playbook 实现这20多个服务程序的统一编排部署和配置,并且可以同时支持单节点和HA多节点自动化部署。

    下图是Ansible自动化部署拓扑图:
    04.png

    我们设计Ansible Playbook时,将每个服务都独立成一个角色,这样保证了各个服务部署的独立性,这种分布式部署架构为将来容器化部署和微服务化奠定了基础。

    Ansible自动化标准化部署不仅大大缩短了部署时间,也极大地降低了部署出错的概率。原先,按照HA架构部署一套产品需要1天时间来完成各个服务的部署和配置,通过使用Ansible playbook,我们只需要45分钟,而且中间过程完全可以放手去做别的事情。
    ##集成测试(Robot Framework)

    目前,我们在Jenkins中使用Robot Framework框架做集成测试。Robot Framework(以下简称RF)是一个基于Python的、可扩展的、关键字驱动的测试自动化框架。

    选用RF的原因:

    * 一致性:目前公司的UI自动化测试使用的就是RF框架,RF框架也完全有能力做集成测试,因此使用RF框架做集成测试,可以降低学习成本,提高可维护性。
    * 复用性:在安装了Robot-Framework-JMeter-Library后,RF可以运行JMeter脚本,并且将JMeter运行结果转为Html格式。公司目前性能测试用的就是JMeter,对于相同场景,只要小幅修改JMeter脚本即可将其复用到集成测试上面。

    05.png

    选用RF也存在一些问题:

    * 如果不复用JMeter脚本,编写的API测试用例的成本非常高。
    RF对于变量类型的规定堪称僵硬(当然,这么规定带来的好处是方便类型检测),RF中对于字典类型的创建非常麻烦(嵌套的字典实例如下),对于我们公司API请求中携带大量参数的情况,只能创建关键字来解决,不管是采取RF自带创建字典的方法,还是创建关键字的方法,都比较浪费时间(因为难以复用)。
    06.png

    * RF可以轻松扩展关键字,也因此可能带来乱扩展关键字的问题,导致测试用例可读性和可维护性差的问题。

    在RF中,关键字其实就是Python/Java的类方法,因此扩展起来非常容易,但是关键字一旦多起来,一个同事写的测试用例,其他人(甚至他自己过了一段时间)维护就非常麻烦(需要回去看关键字是如何规定的)。因此需要严格规定关键字的创建规范是一件值得深入讨论的事情。
    #建立自服务自运维门户

    我们使用云管理平台(以下简称CMP,Cloud Management Platform)管理公司内部资源,使得公司所有人员,都可以通过CMP提供的自服务门户(Self-Service Portal),完成计算/存储/网络等IaaS资源和软件应用自助申请,并且能够自助进行日常运维操作。
    ##CMP平台准备工作

    通过LDAP方式将公司AD账户导入CMP平台中,为开发、测试、售前售后团队创建不同的业务组和资源池,每个资源池给到不同的资源配额,做到资源合理分配和资源相互隔离。为每个业务组设定一个管理员,审批业务组成员的资源申请。
    07.png

    我们使用Shell、Python脚本或Ansible配置管理工具将内部常用的一些软件及应用系统的安装过程进行封装,并发布到CMP平台中,提供标准化蓝图方便大家申请。
    08.png

    ##自服务自运维门户

    在门户中,大家可以看到已经发布好的服务卡片,通过点击服务卡片即可完成IaaS资源或应用系统的自助申请,在平时的开发测试过程中,我们不再需关心底层复杂的系统或网络配置。
    09.png

    在门户中,大家也可以清晰地看到自己所管理的资源的性能情况,还可以简单便捷地完成一些日常的基础运维操作:重启、调整配置、添加逻辑卷、扩展逻辑卷等。
    10.png

    此外,使用管理账号登录CMP管理平台,可以清晰地看到公司内部资源的总体使用情况。
    11.png

    12.png

    13.png

    #总结与建议

    在骞云科技的DevOps实践中,一方面,我们将GitLab、Gerrit、Jenkins、Ansible、JMeter、Robot Framework等成熟的开源工具开源技术和企业内部的云管理平台相结合,实现了较高程度的开发测试流程自动化,推动了产品的持续集成和持续交付,减少了大量的重复劳动,提高了开发测试效率。

    另一方面,通过使用云管理平台,将复杂异构的IaaS资源服务化,降低了使用难度;结合业务部门需求合理划分资源,减少了资源浪费,加强了资源的有效隔离,避免了误操作;自服务自运维的模式,也极大地提升了公司整体研发效率。

    我们的DevOps实践方案适用的场景非常多样,比如:弹性伸缩、迁移、负载均衡。在传统IT、金融、互联网、游戏等行业也具有普适性。
    #未来发展方向

    在介绍Ansible自动化部署时有提到,我们的业务系统由20多个服务组成,符合服务化的架构设计,目前已经可以满足私有化的部署需求。随着新功能的不断引入,部分业务子系统复杂度和团队开发耦合度会逐渐升高,协作效率和部署效率会变得低下。另外,当前的软件架构和部署架构不能满足将来的SaaS化部署。所以,我们仍需要将服务进行更细粒度的拆分,逐步向微服务架构转变并使用容器化部署,进一步降低开发和部署成本。
    #Q&A

    Q:CMP和各个云平台打通都使用了平台的jar,并且需要各种资源生成,这个工作量也不小吧?并且如果api更新代码量也大吧?
    A:我们的核心业务就是做云管理平台,我们产品已经完成了对各个云平台的对接,主要调用各个云平台的API。公有云的API更新频率并不是很高,每当API有更新时,我们也及时去适配。

    Q:Jenkins初次提交也能触发构建吗?每次自动化构建版本号是如何更新的呢?
    A:我们的项目代码具备构建条件后,才在Jenkins上创建了项目构建Job,所以并没有在初次提交时触发构建。每次构建的版本号由两部分组成,一部分是产品的Release大版本号,另一部分直接使用的Jenkins build number这个环境变量。

    Q:有了Gerrit,为什么还要GitLab,Gerrit也可以托管代码啊?
    A:这个是有历史背景的,我们是先选择使用GitLab做代码托管,后期才加入Gerrit做code review。Gerrit在代码review方面比GitLab的merge request要方便许多,更适合企业内部使用。关于这个,我的想法是,要么将GitLab迁移到Gerrit,要么不用Gerrit,可以使用GitLab的merge request来进行review,那GitLab其实是可以不要的。

    以上内容根据2019年2月26日晚微信群分享内容整理。分享人夏飞,骞云科技SmartCMP云管理平台后端开发负责人,负责云管理平台的建设和推广,目前负责公司内部DevOps工作流程的改造。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesd,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    SQL 不是回避 DevOps 的理由

    JetLee 发表了文章 • 0 个评论 • 794 次浏览 • 2019-02-18 15:01 • 来自相关话题

    【编者的话】DevOps 实践火遍大江南北,从一线大厂扩展推行至传统软件企业,但涉及数据库时都多少有些为难。顾介绍相关实践,以供大家借鉴。 有朋友最近告诉笔者,“我们做不了 DevOps,我们使用了关系数据库。“笔者听罢,差点从椅子上 ...查看全部
    【编者的话】DevOps 实践火遍大江南北,从一线大厂扩展推行至传统软件企业,但涉及数据库时都多少有些为难。顾介绍相关实践,以供大家借鉴。

    有朋友最近告诉笔者,“我们做不了 DevOps,我们使用了关系数据库。“笔者听罢,差点从椅子上摔倒。这个观点在很多层面都是错误的。

    “你不了解我的处境!”他拒绝道。“DevOps 意味着我们需要更高频率的部署我们软件的发布版本!现在我们不能控制部署,我们一年只有很少的时间可以干这个。”

    笔者追问朋友当前的部署流程。

    “每隔几个月我们会有新版发布”,他解释道。“将其部署到生产线需要很多工作。由于我们使用 SQL,部署过程会是这样:第一,我们踢掉所有用户,关闭应用服务。下一步,DBA 修改数据库的 schema。一旦他们的工作完成,新版软件就安装完毕,可以使用了。整个过程花费好几个小时,所以我们一般安排在周末进行……(这让人讨厌)。如果升级失败,我们不得不使用备份的磁带,将一切恢复到初始状态,然后再试一次。”

    他总结道,“仅是规划一次升级部署都需要好几周的协商。我们通常都很难达成共识,这也是为什么我们需要在周末来处理升级。每隔几个月做一次都很痛苦,要面对来自方方面面的压力!我听说一些公司每天能做好几次软件发布。如果我们那样做,我们的应用系统就会因为升级而一直处于下线状态了!”

    这里有很多没有说清楚的地方。让我先澄清一些误解。之后再讨论采用一些技术手段如何让部署更容易。

    首先,DevOps 不是一项技术,它是一套方法论。 关于 DevOps 最精确的定义是,应用敏捷、精益的方法到从源码到部署的全过程。它是为了更快速的交付价值,或者说是用短的时间让一个需求特性从想法转变为生产系统的功能。更高频率的发布意味着减少已经就绪的特性等待上线的时间。

    DevOps 不需要禁止任何特殊的数据库技术。反过来,任何技术也不是采用和不采用 DevOps 的理由,就像使用特殊的语言不是阻碍将敏捷应有到项目中的理由。SQL 是常见的理由,但也是经不起推敲的。

    很理解 DevOps 在一些人头脑里是如何与少 SQL 数据库关联在一起。在2000年到2010年左右,投资和实践 DevOps 的公司大部分是大型网站,它们的共识是推行 NoSQL 数据库(键值存储)。然而两者的联系造成了因果的混淆。这些公司还向员工免费提供丰盛的午餐,但我们都同意这不是 DevOps 的前置条件。

    第二,我不确定一些人是否可以做 DevOps。 你可以使用 DevOps 的技术、方法或其他。也就是说,人们已经很频繁的使用这个词,以致于我想我已经无法去有效讨论这个问题。

    朋友们有一个共识。“看”,他困惑道,“这些部署是危险的。坦白讲,每次我们实施的时候都在拿公司的数据,甚至我的工作在冒险。每隔几个月做一次已经压力很大了,还需要更频繁的做吗?不!先生,那是不负责任!”

    在之前的专栏中提到(小批量原则),当一件事情是高风险的时候,我们会倾向于更少的去尝试做它。但与常识相悖的是,这种做法恰恰会增加风险。下次当你做危险的事情时,你应该更多的实践,针对周围环境而累积的变化会越来越大,越容易造成因为未知的副作用导致失败。相应的,DevOps 采取的做法是,危险的事情应该更频繁的去做。高频次的做法会尽早暴露大大小小的问题,而不是每年一次的大扫除。它强迫我们将过程自动化,自动测试整个过程,让过程更流畅,这样风险会降低。它让人们更多参与到实践中。实践出精品。不再回避我们恐惧的东西,帮助我们跨越危险,克服挑战。像任何经历过术后恢复的人一样,我们不断的实践直到它不再痛苦为止。

    部署有一些固定成本。原则上,你需要逐渐将这些固定成本降低。如果增加部署频率而不降低固定成本,则会伤害业务,这是不负责任的。

    该文章其余部分描述了两种实践,让你即使使用 SQL 也可以快速发布。实施它们需要开发者、质控、运维走出各自的筒仓,彼此协作,这也是 DevOps 的实质。这样的结果是让业务更平滑、更少痛苦、更少压力。
    #技术1:自动 Schema 更新
    在这个古老的方法论中,当团队中的专家(通常为 DBA)手工修改 Schema 时,任何 Schema 的变化都需要整个应用系统关闭。如果你希望实现自动化部署,你需要自动化实现 Schema 的更新。

    因此,应用需要管理 Schema。每个 Schema 的版本都需要记录。应用从 Schema V1 版开始。这个值存在数据库中(大致为 1 列的表,该列字段存储为 1)。当应用启动时,它需要知道兼容 V1 的 Schema,如果它在数据库中找不到这个版本,它可以拒绝运行。

    为了自动更新 Schema,下一版本的软件发布时需要知道自己要求 V2 版的 Schema,知道 SQL 命令会将 V1版的 Schema 升级到 V2版。在启动时,它看到版本为 1,然后运行响应的 Schema 升级命名,并将存在数据库中的版本号升级为 2,之后继续运行应用。

    执行这个操作的软件通常还有一个存储 SQL Schema 升级命令表。这些命令以数组存储,索引 n 表示其是支持从 Vn-1 升级到 Vn。这样,某个版本找不到也没有关系,软件能将数据库恢复到任意需要的 Schema 版本。 实际上,如果发现有没有初始化的数据库(如在测试环境中),它会循环执行若干 Schema 升级,直到获取到最新的版本。不是每个软件的发布都需要升级 Schema,因此隔离 Schema 和软件的版本号。

    已经有一些开源的和商业的系统实践了这个过程。他们的一些产品比其他人更复杂,如支持多语言、多数据库、错误处理及是否支持回滚等。从一项关于“SQL 自动化更新”的研究中,你会发现更多信息。我最熟悉的是面向.NET 代码的开源项目 Mayflower 和面向 Go 的 Goose

    Schema 的修改会导致数据库被锁定几分钟甚至几个小时。这会引起应用系统的超时甚至故障。现代 SQL 数据库已经减少此类问题了,需要感谢无锁 Schema 升级和在线重建索引的特性。这些特性可以在现在 SQL 数据库产品中找到,包括开源产品如 MariaDB、MySQL、PostgresSQL。查阅相关文档,以了解操作时的注意事项。

    一旦你的软件使用了这些技术,采用 CI(持续集成)会变得非常容易。你的自动化测试环境可以包含测试使用旧的 Schema 的数据库并升级它,然后运行新版软件。你的 Schema 升级过程可以在发布到生产环境前,进行数百次的测试。这会为该过程带来更多的信心,减少 Schema 升级的危险,解藕 DBA 本人直接参与到升级。他们可以享受原本属于他们的周末了。

    我对此技术最感兴趣的是,你的 Schema 可以按代码一起管理了。大幅减少了控制台上的手工操作,可以在开发环境、测试环境、UAT(用户验收测试)环境、生产环境中不断演练整个过程。你可以重复执行这个过程,完善它。既然它是代码,你可以应用代码管理的实践和软件工程的计算去管理它。
    #技术2:针对多 Schema 编码
    在分布式计算环境中,如何升级数据库的 Schema 呢?

    典型的网站系统前端是负载均衡服务,后端运行相同软件的多个实例或副本。每个实例都承担一部分 HTTP 负载,也访问相同的数据库实例。

    如果软件和数据库 Schema 紧密耦合,而软件升级又需要数据升级 Schema 时,操作会变得难以操作。如果你先改变 Schema,应用实例会故障或者至少会因此产生混乱;你需要尽可能快的升级实例,但是其实你已经输了这场游戏,因为你已经在承受怒火。

    为什么不限升级应用实例呢?!悲剧的是,如果你逐一升级应用实例,最新升级的实例会不能启动,因为它检测到的是错误的 Schema。只有 Schema 与应用系统匹配时,你才能应用拉起,而也在这个时候停机时间才结束。

    最直接的解决方案是,无视现实规律,改变数据库的 Schema,并同时升级所有应用实例的版本。如果条件真的允许你这样做,一切真可以这样搞定。

    遗憾的是,ACM 有套策略来应对现实法则,同样大部分企业雇主也类似。这也是为什么传统方法是关闭整个应用,升级所有东西,然后再重新上线。这种最佳实践延续直至 IEEE 的朋友核算了如何暂停的过程。

    无论是违法现实规律还是计划的停机,每次停机都会引入更大的问题:你完成了许多的独立系统变更,但只有让系统重新运行后才知道它们是否都还正常。同样也不知道这些累计的改变会引发什么样的破坏。

    大爆炸式升级变更是很危险的,而每次仅做一个变更,并验证这个变更,就会降低风险。如果一次执行多个变更,此时碰到问题,必须逐一运行程序以确定哪个变更引起的问题。如果每次只做一个变更,即使碰到问题,排查会很简单,也很容易回退变更。

    即使是像谷歌这样的拥有极其复杂成熟的测试技术和方法,如果不能理解预发布环境和生产环境间细微的差别也可能会导致部署失败。他们采用“金丝雀”发布形式:升级其中一个实例,然后观察是否运行是否正常,如果没有问题,则继续逐渐而有序的升级其余的实例。这其实不是一项测试技术,而是应对测试不充分而采取的保障策略。需要说明的是,不是因为测试人员不优秀,而是没有人是完美的。金丝雀技术目前已经是产业界流行的最佳实践,而且已经被嵌入到 Kubernetes 系统中。(金丝雀一词来源于煤矿业中金丝雀。煤矿矿工通常会带着鸟进矿,一般会选择金丝雀,因为这种鸟对人体有害的气体非常敏感,如果在矿里有鸟死亡,则被视为危险的信号,提醒大家要撤离。)

    由于软件引起的问题通常与特定的 Schema 相关,解决方案就是松耦合。在设计阶段去解除耦合,让软件可以同时支持多个版本的 Schema,以实现独立激活或者回滚。

    第一阶段是编码不再假定表中的字段。用 SQL 术语说就是,SELECT 语句需要精确指出需要的字段,而不是泛泛的使用 SELECT 。如果需要使用 SELECT ,则不要假定字段按特定的顺序排列。 LAST_NAME 也许今天是第三个字段,但明天就不一定了。

    基于这个原则,从 Schema 中删除字段也会简单一些。新版部署后不使用相关字段,一切都可以正常运转。在所有实例都升级至新版后,再变更 Schema。实际上,冗余的字段可以先忽略,稍后再移除他们,甚至等到下次 Schema 变更时再进行清理工作。

    添加字段也会变得简单,即在第一个实例部署前在 Schema 中添加新字段即可。如前所述,我们采用技术 1(应用管理自己的 Schema),部署一个新发布,它会修改 Schema,但不会使用这个新字段。由于合适的事务锁会控制住并行处理,第一个新升级的实例重启后会更新 Schema。如果有问题,则金丝雀会宕掉。你就可以修复软件,然后实验新的金丝雀。而回退 Schema 的变更也是一个可选的方案。

    由于 Schema 和软件结构,开发者可以按需启动新字段。过去的升级需要考虑多个团队的需求后才能确定一个维护窗口,而现在流程解耦,所有相关方可以有序的工作,而不必相互锁定。

    更多复杂的变更需要更多的规划。当拆分字段,移除字段,添加字段等时,收益才真正体现。

    第一,软件必须按同时支持新旧 Schema 的需求进行编写,更为重要的是必须能处理变化阶段。假定你需要从存储人全名的字段迁移至拆分为几个单个字段(第一个名,中间名,最后的名,头衔等)。软件需要检查哪个字段存在,且可用。在数据库转换过程中,它必须可用正常运行,这个过程中两套字段都会存在。一旦两套字段都存在时,一个批处理任务会将全名拆解为多个部分,然后将原字段置为 NULL 值。代码需要处理这种特殊场景,即有些行已经完成转换,而有些还没有完成转换。

    处理这个过程方案可称之为“五阶段在线 Schema 变更”。它有很多阶段,包括创建新字段,升级软件,迁移数据,移除旧字段。它又被成为McHenry 技术(详见《云系统管理实践》),或者叫《Expand/Contract in Release It!: Design and Deploy Production》)

    在线 Schema 变更的五个阶段:

    1. 运行的代码读写旧 Schema,即从表、视图中选择需要的字段。这是初始状态。
    2. 扩展:Schema 被修改,即增加新字段,但不删除任何旧字段。没有代码需要变更。由于此时新字段没有被使用,所以如果需要回滚也不会很痛苦。
    3. 代码被修改以使用 Schema 中的新字段,并发布至生产环境。如果此时发生回滚,只需回滚至第2阶段。这个时候,执行数据转换操作。
    4. 签约:访问不再使用的旧字段的代码会被清除,且被发布至生产环境。如果此时发生回滚,只需回滚至第 3 阶段。
    5. 从 Schema 中移除旧的不再使用的字段。这个阶段如果发生罕见的回滚事件,则数据库可简单回滚至第 4 阶段。

    这些技术足够处理在线分布式系统中大部分复杂的 Schema 变更。而且,每个变更都可以独立回滚。

    针对特定场景阶段的数量可以裁剪。如果只是加字段,则阶段 5 可以忽略,因为没有需要移除的。四、五阶段可以合并或重叠。第 5 阶段可以合并至另一次 Schema 变更中的第 2 阶段。

    基于这些技术,你可以处理最复杂的 Schema 变更而不会有停机时间。
    #总结
    使用关系数据库并不妨碍推行 DevOps。自动化 Schema 管理加上一些开发原则就可以强化测试、缩短发布周期、降低商业风险。

    自动化发布解放了我们。它将痛苦的、鸭梨山大、人工的升级过程,转换为常规事件,且没有事故。它减轻了商业风险,但更重要的是,创建了一个更可持续的工作环境。

    当你可以充满自信的部署新版时,你就可以更高频率的去发布。以前需要等数周甚至数月的新特性可以更早接触用户。问题修复更快。安全漏洞也及时解决。从而使企业能为客户提供更多价值。

    原文链接:SQL is No Excuse to Avoid DevOps(翻译:黄军雷

    在 DevSecOps 中, Security 在其中的具体实践是怎样的?

    回复

    justinfu 回复了问题 • 2 人关注 • 1 个回复 • 1866 次浏览 • 2017-12-01 10:11 • 来自相关话题

    闲聊我心中的运维开发

    aoxiang 发表了文章 • 0 个评论 • 232 次浏览 • 2019-06-03 12:21 • 来自相关话题

    #前言 在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。 诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多 ...查看全部
    #前言
    在我入职上家公司的运维部之前,我所以为的运维工程师只是修修电脑,拉拉网线,布布机器。

    诸不知,运维所涉及的知识面、专业点非常广,对从业人员素质也要求非常高,运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多:

    * 桌面运维工程师
    * 业务运维工程师
    * DBA工程师
    * 配置工程师
    * 运维开发工程师
    * 以及其它....

    1.png

    原本准备写篇前端眼中的运维开发,恰巧前组长写了两篇结合自身六七年开发经验写的体会。用他的文章来阐述再合适不过了。以下来自其投稿以及穿插一些知识普及。
    #DevOps:打破协作壁垒
    来自维基百科:
    2.png

    DevOps(Development和Operations的组合詞)是一种重视「软件开发人员(Dev)」和「IT运维技术人员(Ops)」之间沟通合作的文化、运动或慣例。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    透过自动化「软件交付」和「架构变更」的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    传统的软件组织将开发、IT运营和质量保障设为各自分离的部门,在这种环境下如何采用新的开发方法(例如敏捷软件开发),是一个重要的课题。

    按照从前的工作方式,开发和部署,不需要IT支持或者QA深入的跨部门的支持;

    而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署,它是一套针对这几个部门间沟通与协作问题的流程和方法。
    3.png

    具体来说,就是在 软件交付和部署过程中提高沟通与协作的效率,旨在更快、更可靠的的发布更高质量的产品。
    #运维开发的价值
    从岗位职责来看,运维开发要做的工作是:

    通过开发技能帮助运维实现运维工作的自动化。说白了就是“辅助”,或者说是运维的臂膀,需要把运维中遇到的问题提供平台查询,或者把一些常见的重复操作给抽象出来做成工具,减少运维的人工介入。
    4.png

    运维服务伴随并支撑着业务发展的整个生命周期。

    而DevOps将运维服务的执行方式升级为更加软件工程化的手段,减少人肉操作,DevOps 强调自动化、拉动式来提高团队交付效率与质量。

    而传统的运维需要谋求技术转型,从原来只关注操作系统层面的技术已经不够了,还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升,也需要持续关注整个业务、应用、服务的生命周期管理。

    简单来说,就是把过去传统的黑盒运维的思维方式抛弃,进入白盒运维的时代,我们必须更加深入代码、深入业务运营,让整个线上服务运行于更优质高效的状态。
    #运维开发是什么?
    要建设运维自动化或者实践 DevOps 离不开运维开发工程师的参与,但要怎样才能更好地发挥运维开发的作用呢?

    我曾作为运维开发经理的角色和各种类型的运维开发一起协作过,团队中有本来就做运维开发的,也有本来做其他业务(电商、平台)的开发转来协助运维团队的,还有原本是做业务运维后来转型做运维开发的。
    和他们协作一段日子后,总体感觉如下:

    运维开发首先是一个程序员,不是运维工程师。

    一个好的运维开发需要具备 「运维理解」+「开发能力」:

    * 对「开发能力」的技术要求低于其他业务形态(如游戏、电商、搜索等)。
    * 对运维业务的理解难度会低于电商、游戏等业务形态,即对「运维理解」的要求不高。
    * 对运维相关技术栈的掌握程度要求高,如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、Kubernetes等。

    5.png

    综上所述,运维开发是一个深度不算太深的职业分支,而现在之所以对运维开发需求量热起来了,主要由于老一辈的资深运维普遍研发能力有限,而这是有历史原因的。等到业界提出 DevOps的时候,他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等高级范畴,所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

    所以,当我们有自动化系统的建设需求时,需要更专业的程序员来协助。但一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使,这时候有部分年轻的运维工程师升级了研发技能,转型运维开发,把好使的运维系统做出来了,赢得了运维团队的好评,大家都为「运维开发」点赞。

    所以,大家将 「好使的运维系统」 和 「运维开发」 等价起来,以为我们只要招来一个运维开发,那么一套完美的运维平台就能自动诞生出来,这是个很大的误区。
    #打造「好使的DevOps系统」
    其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」,这两种能力也是可以分离的,不一定要强加在运维开发工程师一个人的身上。

    类似其他业务形态的开发过程,需要产品经理和程序员两种角色分离,企业也不会说要招聘既会写代码、又会出需求的程序员。

    所以,当运维能把运维自动化的需求细致地文档化下来,把自动化系统的设计、架构等关键环节确立下来,这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员,最终就可以得到「好使的运维系统」。

    当然, 一般企业不会专门为运维开发配备「产品经理」,所以运维开发想要再往高级发展的话,也可以替代运维出需求,升级为运维产品经理,以程序员的思维角度来解决运维服务的工程效率和质量问题,我认为这也是类似 Google 所提倡的 SRE 文化。
    ##DevOps平台
    编者补充描述。

    光说不练假把戏,编者在上家公司的主职就是将DevOps操作界面化。
    其中的核心模块:应用部署发布监控。

    图为DevOps应用部署发布监控界面图:
    6.png

    我们组在做上图的DevOps系统时,面临的情况是:无产品、无设计、需求也是靠业务运维和开发们的口头描述。

    其中的核心功能:应用部署界面,在参考其它同类产品后,发现都不适合业务场景,要么功能太分散,要么就仅是流程控制。于是前端功能里,我们做了这些:

    * 区分不同环境下的包,实现有序管理。
    * 应用的状态可以通过界面做启停、查看配置等任务。
    * Jenkins服务操作可通过界面完成,简化配置工程师的工作。
    * 业务运维与开发团队的日常发包工作界面化。

    此时一个优秀的运维开发需具备以下技能:产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。

    所以,当运维需求被理解、分析得足够透彻,以及运维开发获得了「产品经理」能力后,运维开发就是一种普通的开发分支,按需求文档编码即可。
    #优秀的运维开发
    从事DevOps平台开发相关工作已有六七年了,自身经历总结,觉得一个优秀的运维开发工程师应当具备以下能力和素质。
    ##提高运维意识。
    从下到上,从上到下的工作都要做好,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放运维。

    运维意识是很重要,并不是你技术很牛,学的技术很多很熟,就不代表你不需要运维意识。

    其实领导很看重运维意识的,例如有没有做好备份,权限分配问题,平台测试情况,故障响应时间等,这些都是意识,而不是你学了很多技术自认大牛了,平台发现故障你又没什么大不子,以为很简单的问题喜欢处理就处理,不需要向其它部门反馈等,领导不是看你的技术如何,而是看你的运维意识如何,你没运维意识,技术再牛也没用,只会让其它部门的人跟你不协调。
    ##了解业务场景
    DevOps平台最终服务于运维部和开发测试部同事,因此只有熟悉了解了每一项业务的运维场景,才能更好去设计功能与代码开发,熟悉业务场景才能方方面面考虑周全,开发出来的代码才能满足各类场景应用。
    ##拒绝重复犯错
    人难免会犯错,这是无法避免的,我们应当根据已有的犯错经验,总结犯错的原因,以及如何避免同类情况再次发生,甚至可以把一些典型的错误在团队中分享,把一个人的错误得到的经验传播于整个团队。
    ##凡事有备份,可回退
    运维工作中经常有一些发布,迁移,备份等复杂操作,因此,在研发DevOPs平台的时候,要做好全面的操作计划,思考每一步可能的回退与备份。
    ##平台操作尽量简化
    DevOps平台目的就是为了能够提高运维的工作效率,解放运维,因此在设计与开发的时候,应当保持操作简单,不要让事情变得太复杂,能点一下到位的,尽量不要让人点五六下才能完成操作。
    ##注重优化用户体验
    DevOps开发是一个迭代的过程,虽然我们常说以功能开发为主,但是用户体验也同等重要,试想一下,纵使你开发的功能众多,如果体验不友好,用户便失去了再次使用的欲望,如果用户拒绝,抵触使用平台,做再多功能也是失败,最终平台推广失败。因此,在研发的过程中,我们应当深入体验自己开发的产品,把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。

    在设计与开发的过程中经常会碰到复杂,繁琐的场景,这个时候我们很容易失去耐心,我们要时刻提醒自己,必须严格履行自己的工作职责,端正自己的工作态度,做一件事,要么不做,既然做了就要做好:当你想要放弃的时候,想想当初为什么要开始。
    #总结
    本文是我个人对运维开发以及其职业发展的一些浅薄理解,总的来说,运维开发还是一个比较有意思且有良好发展的职业分支,虽然偶尔也要背黑锅,但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

    链接:https://juejin.im/post/5cf29a6ae51d45778f076cd2

    2019企业IT现状和趋势调研报告:70.7%的企业有云原生相关计划

    灵雀云 发表了文章 • 0 个评论 • 155 次浏览 • 2019-06-03 11:00 • 来自相关话题

    2019年第一季度,灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研,通过定向邀请,3个月内共收集了400余份有效调研问卷,这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。 发起本次调研 ...查看全部
    2019年第一季度,灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研,通过定向邀请,3个月内共收集了400余份有效调研问卷,这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。

    发起本次调研的初衷,是我们希望了解当前企业,尤其是传统企业目前IT应用开发现状、以及以DevOps、Kubernetes、微服务等为代表的云原生技术在企业的应用情况,从而勾勒出传统行业IT发展趋势,并对于判断国内用户对云原生相关技术的认知度提供一个有价值的参考。
    核心要点解读:
    1、 约70%的参与调研者所在企业2019年IT预算有上浮;

    2、 24.4%的参与调研者表示公司IT系统基本全靠自研,企业开始自建软件研发团队,主导IT应用的研发;

    3、 70.7%的参与调研者所在企业表示在2019年有容器、DevOps和微服务方面的规划;

    4、 11.4%的参与调研者所在企业已经试点了具有标杆意义的云原生实践,如精英团队的DevOps实践,小范围非核心应用的微服务拆分改造实践等。


    pic2.jpg



    本次调研的400多位调研对象中,80%以上来自金融、能源、制造、汽车等传统行业,其中17.3%来自基础架构部门, 22.5%来自运维部门,34.1%来自研发部门,还有约10%的被调研对象为企业的CIO/CTO等高级IT管理者。


    pic3.jpg



    被调研企业中,服务器规模在100-500台的比例为26.8%,500-1000台的企业占比22%,1000台服务器以上规模的14.6%。



    IT系统自研还是外包



    pic4.jpg




    在数字化转型的背景下,传统外包的做法在被逐渐改变。在此次调查中,70.7%的参与调研者表示目前IT系统是自研外包兼而有之,其中核心业务系统以自己开发为主,24.4%的参与调研者表示公司IT系统基本全靠自研,只有4.9%的参与调研者选择了纯外包选项。这表明,企业开始不再将大部分业务系统,尤其是核心业务需求开发外包,开始自建软件研发团队,主导IT应用的研发。只有企业自己主导IT研发,才能够打造IT核心竞争力。

    软件能力成为企业的核心竞争力,这恰好是数字化转型的本质之一。何谓成功的数字化转型?灵雀云认为,有三大衡量标志:IT部门由成本中心转为收入中心;企业自己主导IT产品的研发;改进工具、流程、文化来提高交付速度和质量。最终,实现客户满意度的提升、打造差异化竞争优势、加速产品上市。



    IT系统更新频率




    PIC5.jpg



    在IT系统更新频率方面,每月都要更新、升级的比例达到了51.2%的高占比。同时,每3-6个月更新一次的比例达22%。每个传统领域,都受到了来自Fintech金融科技、车联网、物联网、新零售等新技术驱动的创新业务的挑战,传统企业只有借助IT手段才能实现持续发展,在速度和规模上保持竞争力。



    IT系统和研发团队TOP 3挑战



    pic6.jpg




    本次参与调研的企业以中大型企业为主,其中研发团队规模达到100人以上的比例高达44.3%,20-100人规模的占32.4%。

    PIC7.jpg




    今天,许多企业都经过了大量IT建设,从分散到集中,造成IT系统越来越复杂,信息孤岛林立,架构臃肿等问题突出。调研中企业IT系统支撑所面临的压力位列前三的挑战分别是:系统复杂性越来越高(65.9%);应用交付压力大,交付速度无法满足业务需求(61.4%);运维管理复杂度提升,IT部门很难构建一支全功能团队(53.7%)。


    PIC8.jpg



    同时,研发团队所面临的挑战前三甲分别是:部署和运维复杂,运维成本高(74.6%);研发、测试、运维等角色之间相互孤立(62.3%);升级和变更流程复杂,IT服务和应用交付周期长(45.7%)。此外,比较突出的挑战还有,工具链无法完整集成,工具使用困难(32.3%),单体应用过于庞大,迭代效率低下(20.4%)。


    pic9.jpg



    上述结果充分表明,面对高度创新、快速变化和充满不确定性的新型业务需求,传统开发模式和IT架构已经成为掣肘。70.7%的参与调研企业表示2019年有容器、DevOps和微服务方面的规划和实施计划。

    只有朝着持续交付、敏捷部署、快速迭代,通过敏捷IT赋予业务足够的敏捷,才能够满足不断变化的业务需求,重塑自身的生产力,形成竞争优势,带来更好的用户体验,这最终落到以Kubernetes/容器、DevOps和微服务为核心的云原生技术的落地上。云原生架构和理念与数字化转型一脉相承,帮助企业更加顺畅地实施数字化转型。



    业务上云需求最强烈,开源、数字化转型受追捧



    PIC10.jpg




    在企业最关注的新兴技术趋势方面,云计算占比82.9%,企业将业务上云,提升IT资源效率作为首要关注对象。大数据和人工智能紧随其后,占比分别为73.2%和46.3%。其中开源解决方案在调研对象中的关注程度达到24.4%。

    当前开源技术正在进入快速发展阶段,向着企业应用的方方面面深入。开源及开源社区不断将新的工具、方法和最佳实践用于云原生的实际业务用例,解决云原生用户的关键问题。借助许多开源解决方案,云原生部署的复杂性和难度也在得以降低。

    此外,数字化转型的关注度为33.6%。如今每位IT从业者言必称数字化转型,IT能力也直接指向助力数字化转型。CIO和其他IT管理者已将企业的数字化计划置于新的高度,希望通过数字化来改变企业的商业和业务模式,数字化业务将从初步试验走向大规模应用。伴随企业数字化业务的不断成熟,预计未来几年,数字化转型将进入爆发阶段。



    传统企业2019年IT预算稳中有升


    PIC11.jpg





    本次调研中,被调研企业今年IT工作的重点包括业务上云(56.1%),云原生、大数据、人工智能等新技术采用(53.7%),打造数字化团队,引领企业的数字化创新(43.9%),选择传统业务应用的比例不足20%。越来越多的企业将工作负载放在云端,将正在开发的应用或服务托管在云平台上,云市场不断增长。


    PIC12.jpg



    在IT预算方面,比客观经济形势略显乐观,和2018年IT预算相比,接近70%参与调研企业2019年的IT预算略有上浮,其中增长5%以内的企业占比37.5%,增长5-10%的企业占比21.2%,增长10%以上的企业达到12.7%。

    此外,调研结果显示,数字化转型是一项需要通盘考虑的工作,需要项目管理部门、技术管理部门、开发部门、运维部门共同参与,制定统一的数字化转型方案和决策并推进。有些参与调研的企业特别强调2018年已经在全公司范围内试点了具有标杆意义的云原生实践,如精英团队的DevOps实践,小范围非核心应用的微服务拆分改造实践等,并且这些都将在2019年进行大范围推广。

    CoDo开源一站式DevOps平台

    尼古拉斯 发表了文章 • 0 个评论 • 178 次浏览 • 2019-05-31 15:37 • 来自相关话题

    有幸参与到CoDo项目的开发,这是一个非常棒的一站式开源运维平台,分享给大家。 #平台介绍 CODO是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。 CODO前端基于Vue iview开 ...查看全部
    有幸参与到CoDo项目的开发,这是一个非常棒的一站式开源运维平台,分享给大家。
    #平台介绍

    CODO是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。

    CODO前端基于Vue iview开发、为用户提供友好的操作界面,增强用户体验。

    CODO后端基于Python Tornado开发,其优势为轻量、简洁清晰、异步非阻塞。

    CODO开源多云管理平台将为用户提供多功能:ITSM、基于RBAC权限系统、Web Terminnal登陆日志审计、录像回放、强大的作业调度系统、CMDB、监控报警系统、DNS管理、配置中心等。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    ##产品架构

    1.jpg

    ##产品功能

    2.jpg

    ##模块说明


    * 项目前端:基于Vue + Iview-Admin实现的一套后台管理系统
    * 管理后端:基于Tornado实现,提供Restful风格的API,提供基于RBAC的完善权限管理,可对所有用户的操作进行审计
    * 定时任务:基于Tornado实现,定时任务系统,完全兼容Linux Crontab语法,且支持到秒级
    * 任务调度:基于Tornado实现,系统核心调度,可分布式扩展,自由编排任务,自由定义流程,支持多种触发,支持审批审核,支持操作干预
    * 资产管理:基于Tornado实现,资产管理系统,支持手动添加资产,同时也支持从AWS/阿里云/腾讯云自动获取资产信息
    * 配置中心:基于Tornado实现,可基于不同项目、环境管理配置,支持语法高亮、历史版本差异对比、快速回滚,并提供Restful风格的API
    * 域名管理:基于Tornado实现,支持多区域智能解析、可视化Bind操作、操作日志记录
    * 运维工具:基于Tornado实现,运维场景中常用的加密解密、事件、故障、项目记录、提醒、报警等

    ##在线体验

    CoDo提供了在线Demo供使用者体验,Demo账号只有部分权限

    - 地址:http://demo.opendevops.cn
    - 用户:demo
    - 密码:2ZbFYNv9WibWcR7GB6kcEY

    3.jpg

    ##推荐理由

    团队出品: GitHub上有很多开源的DevOps工具,几乎全部都由个人发布维护,代码质量、版本进度以及可持续性都无法保障,陷入不能用或不敢用的尴尬境地,CoDo非个人项目,由一个团队负责开发维护,有幸我也是团队中一员,参与贡献了部分代码,所以在稳定性和持续性方面更有保证。

    生产实践: CoDo核心代码贡献者全部来自于一线运维团队,团队成员从运维需求出发,致力于解决运维痛点,更了解运维的需求,且核心代码经过了多年生产实践,并非实验产品,运行稳定

    功能齐全: CoDo采用微服务的理念构建,模块化开发,目前已有资产管理、定时任务、任务调度、配置中心、域名管理、运维工具几大模块,支持持续集成、持续部署、代码审查、数据库审核与优化建议等众多功能,覆盖大部分的运维场景,让你不再费心劳神在多个系统间奔波,一个平台全搞定

    完善支持: CoDo除了提供专业的文档支持外,还同时开始录制一些基础的部署使用视频帮助初学者快速上手

    开源免费: 这是一个开源项目,所有功能均可免费使用,源码托管在GitHub
    ##项目地址


    * 官网:http://www.opendevops.cn
    * GitHub:https://github.com/opendevops-cn
    * 文档地址:http://docs.opendevops.cn/zh/latest
    * 安装视频:https://www.bilibili.com/video/av53446517

    原文链接:https://mp.weixin.qq.com/s/eZX5qoJzuCSuLI98gSCtpw

    火热的云原生到底是什么?一文了解云原生四要素!

    阿娇 发表了文章 • 0 个评论 • 240 次浏览 • 2019-05-30 18:33 • 来自相关话题

    所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
    所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

    随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

    在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
    #云原生概念的诞生

    云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
    1.jpg

    The Twelve-Factor App

    顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
    ##云原生并不是一个产品

    最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

    云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
    2.jpg

    而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

    所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
    ##云原生计算基金会(CNCF)

    CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

    目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
    3.jpg

    Cloud Native Landscape新版

    CNCF(云原生计算基金会)认为云原生系统需包含的属性:

    * 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
    * 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
    * 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

    正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
    #云原生的四要素:持续交付、DevOps、微服务、容器

    从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
    4.jpg

    ##持续交付——缩小开发者认知,灵活开发方向

    首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

    而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
    5.jpg

    用小步快跑的方式,打破瀑布式开发流程

    那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
    6.jpg

    蓝绿(Blue-Green)部署

    但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
    ##微服务——内聚更强,更加敏捷

    第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

    是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
    7.jpg

    Going Agile - Breaking the monolith Conway's Law and Microservices

    这样按照组织架构划分的优势在于:

    1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
    2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

    另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

    那么在什么情况下需要微服务?我认为有三个标准:

    1. 有HA(High Available)的需求需要微服务。
    2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
    3. 经常变更的需要微服务。

    实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

    但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
    ##容器技术——使资源调度、微服务更容易

    再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

    其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

    VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
    8.jpg

    从 Infra 角度来看技术演进

    从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

    大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

    Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

    Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    9.jpg

    容器生态图

    容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
    ##DevOps——以终为始,运维合一

    10.png

    最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

    DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

    首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

    其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

    总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
    #总结

    综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

    面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

    原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

    云原生之下的Java

    尼古拉斯 发表了文章 • 0 个评论 • 197 次浏览 • 2019-05-30 10:22 • 来自相关话题

    自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
    自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

    Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

    当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

    部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

    云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

    云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

    原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

    DockOne微信分享(二一零):平安证券Kubernetes容器集群的DevOps实践

    齐达内 发表了文章 • 0 个评论 • 421 次浏览 • 2019-05-29 11:54 • 来自相关话题

    【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同 ...查看全部
    【编者的话】最近两三年,Docker容器技术及Kubernetes编排调度系统,在DevOps领域,大有星火燎原,一统天下之势。平安证券IT团队一直紧跟最新技术,践行科技赋能。本次分享,聚焦于公司在DevOps转型过程中的几个典型的技术细节的解决方案,希望对同行有所借鉴和帮助。
    #生产环境的高可用Master部署方案
    Kubernetes的高可用Master部署,现在网络上成熟的方案不少。大多数是基于Haproxy和Keepalived实现VIP的自动漂移部署。至于Haproxy和Keepalived,可独立出来,也可寄生于Kubernetes Master节点。

    我司在IT设备的管理上有固定的流程,VIP这种IP地址不在标准交付范围之内。于是,我们设计了基于DNS解析的高可用方案。这种方案,是基于Load Balancer变形而来。图示如下:
    1.png

    这种构架方案,平衡了公司的组织结构和技术实现。如果真发生Master挂掉,系统应用不受影响,DNS的解析切换可在十分钟内指向新的Master IP,评估在可接受范围之内。

    公司内部安装Master节点时,使用的基本工具是Kubeadm,但是作了脚本化改造及替换成了自己的证书生成机制。经过这样的改进之后,使用kubeadm进行集群安装时,就更有条理性,步骤更清晰,更易于在公司进行推广。

    底层的etcd集群使用独立的Docker方式部署,但共享kubeadm相关目录下的证书文件,方便了api-server和etcd的认证通信。脚本的相关配置如下:
    2.png

    当以DNS域名的形式进行部署后,各个证书配置认证文件,就不会再以IP形式连接,而是以DNS域名形式连接api-server了。如下图所示:
    3.png

    #分层的Docker镜像管理
    接下来,我们分享一下对Docker镜像的管理。Docker的企业仓库,选用的是业界流行的Harbor仓库。根据公司研发语言及框架的广泛性,采用了三层镜像管理,分为公共镜像,业务基础镜像,业务镜像(tag为部署发布单),层层叠加而成,即形成标准,又照顾了一定的灵活性。

    * 公共镜像:一般以alpine基础镜像,加上时区调整,简单工具。
    * 业务基础镜像:在公共镜像之上,加入JDK、Tomcat、Node.js、Python等中间件环境。
    * 业务镜像:在业务基础镜像之上,再加入业务软件包。

    4.png

    #Dashboard、Prometheus、Grafana的安全实践
    尽管在Kubernetes本身技术栈之外,我司存在体系化的日志收集,指标监控及报警平台,为了运维工具的丰富,我们还是在Kubernetes内集成了常用的Dashboard、Prometheus、Grafana组件,实现一些即时性运维操作。

    那么,这些组件部署,我们都纳入一个统一的Nginx一级url下,二级url才是各个组件的管理地址。这样的设计,主要是为了给Dashborad及Prometheus增加一层安全性(Grafana自带登陆验证)。

    这时,可能有人有疑问,Dashboard、kubectl都是可以通过cert证书及RBAC机制来实现安全性的,那为什么要自己来引入Nginx作安全控制呢?

    在我们的实践过程中,cert证书及RBAC方式,结合SSH登陆帐号,会形成一系列复杂操作,且推广难度高,我们早期实现了这种模式,但目前公司并不具备条件,所以废弃了。公司的Kubernetes集群,有专门团队负责运维,我们就针对团队设计了这个安全方案。

    Prometheus的二级目录挂载参数如下:
    5.png

    Grafana的二级目录挂载参数如下:
    6.png

    Dashboard在Nginx里的配置如下:
    7.png

    #一个能生成所有软件包的Jenkins Job
    在CI流水线实践,我们选用的GitLab作为源代码管理组件,Jenkins作为编译组件。但为了能实现更高效标准的部署交付,公司内部实现一个项目名为prism(棱镜)的自动编译分发部署平台。在容器化时代,衍生出一个Prism4k项目,专门针对Kubernetes环境作CI/CD流程。Prism4k版的构架图如下所示:
    8.png

    在这种体系下,Jenkins就作为我们的一个纯编译工具和中转平台,高效的完成从源代码到镜像的生成。

    由于每个IT应用相关的变量,脚本都已组织好,放到Prism4k上。故而,Jenkins只需要一个Job,就可以完成各样各样的镜像生成功能。其主要Pipeline脚本如下(由于信息敏感,只列举主要流程,有删节):
    9.png

    在Jenkins中,我们使用了一个Yet Another Docker Plugin,来进行Jenkins编译集群进行Docker生成时的可扩展性。作到了编译节点的容器即生即死,有编译任务时,指定节点才生成相关容器进行打包等操作。
    #计算资源在线配置及应用持续部署
    在Prism4k平台中,针对Jenkins的Job变量是通过网页配置的。在发布单的编译镜像过程中,会将各个变量通过API发送到Jenkins,启动Jenkins任务,完成指定task任务。
    10.png

    Pod的实例数,CPU和内存的配置,同样通过Web方式配置。
    11.png

    在配置好组件所有要素之后,日常的流程就可以基于不同部门用户的权限把握,实现流水线化的软件持续交付。

    * 研发:新建发布单,编译软件包,形成镜像,上传Harbor库。
    * 测试:环境流转,避免部署操作污染正在进行中的测试。
    * 运维:运维人员进行发布操作。

    在FAT这样的测试环境中,为加快测试进度,可灵活的为研发人员赋予运维权限。但在更正式的测试环境和线上生产环境,作为金融行业的IT建设标准,则必须由运维团队成员操作。

    下面配合截图,了解一下更具体的三大步骤。

    1. 发布单
    12.png

    在Prism4k与Jenkins的API交互,我们使用了Jenkins的Python库。

    1. 环境流转
    13.png


    1. 部署
    14.png


    在部署操作过程中,会将这次发布的信息全面展示给运维同事,让运维同事可以进行再次审查,减少发布过程中的异常情况。
    #总结
    由于Kubernetes版本的快速更新和发布,我们对于其稳定性的功能更为青睐,而对于实验性的功能,或是需要复杂运维技能的功能,则保持理智的观望态度。所以,我们对Kubernetes功能只达到了中度使用。当然,就算是中度使用,Kubernetes的运维和使用技巧,还是有很多方面在此没有涉及到,希望以后有机会,能和各位有更多的沟通和交流。愿容器技术越来越普及,运维的工作越来越有效率和质量。
    #Q&A
    Q:镜像有进行安全扫描吗:
    A:外部基本镜像进入公司内部,我们基于Harbor内置的安全功能进行扫描。

    Q:Harbor有没有做相关监控,比如发布了多少镜像,以及镜像同步时长之类的?
    A:我们没有在Harbor上作扩展,只是在我们自己的Prism4k上,会统计各个项目的一些镜像发布数据。

    Q:有没有用Helm来管理镜像包?后端存储是用的什么,原因是?
    A:没有使用Helm。目前集群有存储需求时,使用的是NFS。正在考虑建基于Ceph的存储,因为现在接入项目越来越多,不同的需求会导致不同的存储。

    Q:想了解下目前贵公司监控的纬度和监控的指标和告警这块。
    A:监控方面,我公司也是大致大致划分为基础资源,中间件,业务指标三大块监控。方法论上也是努力在向业界提倡的RED原则靠拢。

    Q:想了解下,Yaml文件怎么管理的,可以自定义生成吗?
    A:我们的Yaml文件,都统一纳到Prism4k平台管理,有一些资源是可以自定义的,且针对不同的项目,有不同的Yaml模板,然后,透过django的模块功能统一作解析。熟悉Yaml书写的研发同事可以自己定义自己项目的Yaml模板。

    Q:Pipeline会使用Jenkinfile来灵活code化Pipeline,把Pipeline的灵活性和创新性还给开发团队,这比一个模板化的统一Pipeline有哪些优势?
    A:Pipeline的运行模式,采用单一Job和每个项目自定义Job,各有不同的应用场景。因为我们的Jenkins是隐于幕后的组件,研发主要基于Prism4k操作,可以相对减少研发的学习成本。相对来说,Jenkins的维护人力也会减少。对于研发各种权限比较高的公司,那统一的Job可能并不合适。

    Q:想了解下贵公司使用什么网络方案?Pod的网络访问权限控制怎么实现的?
    A:公司现在用的是Flannel网络CNI方案。同时,在不同的集群,也有作Calico网络方案的对比测试。Pod的网络权限,这块暂时没有,只是尝试Istio的可行性研究。

    Q: 一个Job生成所有的Docker镜像,如果构建遇到问题,怎么去追踪这些记录?
    A:在项目前期接入时,生成镜像的流程都作了宣传和推广。标准化的流程,会减少产生问题的机率。如果在构建中遇到问题,Prism4k的界面中,会直接有链接到本次建的次序号。点击链接,可直接定位到Console输出。

    Q:遇到节点Node上出现100+ Pod,Node会卡住,贵公司Pod资源怎么做限制的?
    A:我们的业务Pod资源,都作了limit和request限制。如果出现有卡住的情况,现行的方案是基于项目作拆分。Prism4k本身对多环境和多集群都是支持的。

    Q:多环境下,集中化的配置管理方案,你们选用的是哪个,或是自研的?
    A:我们现在正在研发的Prism4k,前提就是要支持多环境多集群的部署,本身的功能里,yaml文件的配置管理,都是其内置功能。

    Q:etcd的--initial-cluster-state选项设置为new,重启etcd后会不会创建新的etcd集群?还是加入原有的etcd集群?
    A:我们测试过轮流将服务器(3 Master)完全重启,ectd集群的功能均未受影响。但全部关机重启,还未测试过。所以不好意思,这个问题,我暂时没有考虑过。

    Q:网络方案用的什么?在选型的时候有没有对比?
    A:目前主要应用的还是Flannel方案,今年春节以来,还测试过Flannel、Caclico、kube-router方案。因为我们的集群有可能越机房,而涉及到BGP协议时,节点无法加入,所以一直选用了Flannel。

    Q:部署的动态过程是在Jenkins的Web界面上看还是在自研的Prism4k上能看到,如果是Prism4k的话,整个可视化过程的展示这些等等也是自己开发的吗?Prism4k是用什么语言开发的,Python吗?
    A:部署的动态过程,是在Prism4k上显示。可视化方案,也只是简单的使用ajax及websocket。Prism4k后端是基于Django 2.0以上开发,其中使用了RESTful framework、channels等库,前端使用了一些js插件。

    以上内容根据2019年5月28日晚微信群分享内容整理。分享人陈刚,平安证券运维研发工程师,负责经纪业务IT应用的持续交付平台的设计和开发。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    DevOps时代测试应该如何应对?

    阿娇 发表了文章 • 0 个评论 • 173 次浏览 • 2019-05-28 11:12 • 来自相关话题

    #背景 DevOps的概念最早起源于2009年的欧洲,但由于当时配套技术和工具的匮乏,导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服务架构理念的深入实践,提倡持续高效的交付使DevOps成为了一种趋势,容器技术 ...查看全部
    #背景

    DevOps的概念最早起源于2009年的欧洲,但由于当时配套技术和工具的匮乏,导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服务架构理念的深入实践,提倡持续高效的交付使DevOps成为了一种趋势,容器技术又使得DevOps的实施变得相对容易,所以DevOps在各行业各种规模的组织中开始逐步落地实施。

    DevOps是Development和Operations的组合词,它是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(Quality Assurance)部门之间的沟通、协作与整合,旨在以高质量持续发布的产品应对瞬息万变的市场需求。DevOps中质量保障贯穿了整个产品的交付周期,是连接开发和运维之间的桥梁。如果没有全面的质量保障和测试策略,就无法实现持续开发和交付。
    1.jpg

    QA等同于测试么?回答肯定是否定的。QA包含QC(Quality Control)和测试两部分,其主要目标是规划和建立质量评估体系,以确保产品的预期质量;测试是用来验证产品并找到可能缺陷的过程。QA和测试二者相互关联,不可互换与替代。

    持续测试作为DevOps的一个关键环节,是产品质量保证最重要的方法,那么传统的测试人员应该如何转型去适应DevOps呢?如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #传统测试、敏捷测试和持续测试有何不同

    传统测试以手工测试为主,对代码级别的测试投入较少,整体呈倒三角模式, 侧重于发现缺陷并修复;敏捷的出现增大了自动化测试的比例,以底层运行速度快、消耗小的单元测试为主,整体呈正三角模式,相比传统测试反馈更及时,修复缺陷的成本低;持续测试在敏捷测试的基础上,强调测试持续进行,通过各部门的协同工作,持续发现缺陷并迅速修复。
    2.jpg

    传统测试、敏捷测试和DevOps测试

    从传统的瀑布型测试到敏捷测试再到DevOps,三者之间具体有什么区别?这一系列的转型对测试提出了什么样的挑战?DevOps中的测试人员需要掌握哪些技能才能做到全面的质量保障?
    ##传统测试

    传统瀑布式软件开发模式中,开发、测试和运维团队之间无协作关系。开发团队负责代码编写和对应的单元测试;测试团队编写手动测试用例并执行,以业务场景测试和系统集成测试为主;QA团队编写自动化测试用例,往往在产品发布前才进行大规模的产品质量验证。

    由此可见,传统测试遵循自上而下的顺序方法,产品的质量在测试阶段确定,对产品进行任何更改都非常困难。自动化测试执行效率低,测试用例执行成本高。各部门之间的独立必然导致重复性测试,无法保证全面的产品质量。
    ##敏捷测试

    随着市场需求的加快,传统的瀑布式软件开发模式已经不能够满足频繁的软件交付,敏捷开发模式应运而生。在敏捷测试中,测试不再是一个单独的阶段,它属于迭代计划的一个组成部分,测试人员始终与开发人员保持同步,共同负责产品的质量保障。敏捷提倡频繁且更快地进行测试,因此自动化测试在敏捷测试中至关重要。

    从开发到运营的整体流程来看,敏捷模型仅仅融合了开发和测试两个部分,加快了软件开发的频率。但是实际部署到生产环境仍然是由运维团队独立完成,开发和运维之间依然隔着厚厚的一堵墙,繁琐的发布周期使敏捷工作重新回到了瀑布模式。DevOps的出现成功打破了开发和运维之间的隔阂,解决了从开发到部署的这一难题。
    ##持续测试

    持续测试可以看作敏捷测试的进阶版,意味着持续不断的测试,贯穿了整个软件交付周期,包括从需求分析到产品部署的各种测试阶段。持续测试提倡尽早测试、频繁测试和自动化测试。测试与代码开发同时进行,开发人员和测试人员共同分析测试需求,共同编写和维护测试用例,每开发完一项任务就立即运行自动化测试集对交付质量进行验证,从而形成持续验证。代码一旦成功通过了自动化测试集就会立刻部署到生产环境中,进行生产阶段的持续监控。
    #DevOps时代的测试应该怎么做

    Laurent曾经从测试左移、右移的角度描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时,测试应该如何相应变化。

    测试左移,是指测试人员更早地参与到软件项目前期的各项活动中,在功能开发之前定义好相关的测试用例,提前发现质量问题。早期引入测试过程有助于防止缺陷,并为开发人员提供了在整个开发阶段应用动态变更的灵活性。

    测试右移,就是直接在生产环境中监控,并且实时获取用户反馈。在这种方法中,从用户侧收集反馈,根据用户反馈持续改进产品的用户体验满意度,提高产品质量。测试右移有助于更好的响应意外情况。

    传统测试主要集中在软件开发周期的最后,产品发布之前。为了迎合不断加快的交付频率,越来越多团队的测试活动开始向左右两侧移动。一般问题修复成本较高和面向企业收费的软件,一旦生产环境中出现了问题会造成比较大的损失,通常采取测试左移的方式;对于具有展示功能的软件产品,更容易在生产环境中发现问题,通常采取测试右移的方式。面对测试左右摇摆的问题,小编从以下几个阶段阐述了DevOps中的测试具体应该如何实现。
    3.jpg

    DevOps中的测试
    ##用户需求分析

    DevOps模式下,与产品相关的所有角色都要参与到用户需求的分析与拆分中,包括开发、测试、运维、产品经理、市场等角色,需全部角色共同确定需求的质量标准和验收条件,并采取BDD(Behavior Driven Development)的方式定义,从而使产品交付流水线上的所有相关人员都能对需求达成一致的理解。
    ##编码、构建阶段

    测试与开发采用TDD(Test-Driven Development)的方式工作,共同分析用户故事、制定验收条件。测试用例与产品开发同步进行和完成,代码一旦开发完会立即通过这些测试套件。这一阶段的测试多以自动化的代码级测试为主,比如单元测试、组件测试、接口/服务级测试等。通常这类的测试不需要启动整个应用程序,运行时间短,从而获得更快的反馈,因此这些测试位于测试套件的前端。
    ##验收阶段

    验收测试用来验证用户需求是否得到了满足,产品是否可以进入部署阶段。制定全面的用户/业务级的验收测试,既验证了软件产品是否交付了用户期望的业务价值,又可以防止回归问题或者缺陷破坏了软件原有的功能。验收测试分为功能验收测试和非功能验收测试。

    功能验收测试

    功能验收测试运行在类生产环境中,通过模拟用户在真实环境中的操作来验证用户故事是否完成。手工验收测试将代码部署到UAT(User Acceptance Test)环境中,手动模拟用户的操作进行验证;自动化验收测试采用自动化测试工具和应用交付的方式来模拟用户的使用。常见的功能验收测试包括UI(User Interface)测试、集成测试和服务测试等。

    非功能验收测试

    这一类测试通常运行在特定的环境中,使用的工具类型取决于被测的产品,一般需要花费较长时间和较复杂的环境来运行,所以这类测试一般位于测试套件的后端。常见的非功能验收测试包括容量测试、易用性测试、安全性测试和兼容性测试等满足其交叉功能特性的测试。
    ##部署阶段(持续监控)

    Jez Humble曾指出:“如果真的想获得持续交付的好处,应该尽早将软件产品部署到生产环境中”。代码通过了开发过程中自动化测试套件后,就直接部署到生产环境中,从而获取更直接的反馈。

    部署阶段的测试,更准确的说应该叫做生产环境中的监控,从基础监控、应用监控到业务监控,既覆盖了对新功能的可用性测试,也囊括了对已有功能的实时监控,并通过不断的收集用户意见,及时整理、分析并反馈给研发部门,最终实现产品价值的不断提升。常见的监控有两种:一是直接在生产环境上自动运行测试用例;二是通过向生产环境中引入问题来发现产品在生产环境中的潜在问题。
    ##持续集成(Continuous Integration)

    理想的DevOps周期,是从代码开发到生产环境运行的一键部署。显然DevOps非常重视构建、测试和部署的自动化,使用持续集成成为了持续测试的基础。实现持续测试的重要一步,是创建全面的自动化测试套件以在持续集成构建中使用,代码提交后会立刻经过这套自动化测试套件得以验证。常见的自动化测试套件由单元测试、组件检测和验收测试组成,其中每种测试的代码或功能覆盖率至少要达到80%以上才能保证不引入回归问题。
    ##协作

    持续测试的成功实施离不开团队内、团队间及跨团队的协作。新项目从开始就要保证所有成员的共同参与,在协作开发中,开发人员和测试人员在各自的用户故事上并行工作,如开发人员开始编译代码,测试驱动也需跟着启动。代码开发完成就能迅速获取反馈,大大缩短了反馈周期,协同工作也帮助开发人员更好的理解用户故事的真正实现。测试人员同时要积极的参与到持续部署的流程中,在将产品部署到生产环境的过程中跟运维人员做好无缝衔接,尽早制定在生产环境中的监测计划,并根据运维人员的反馈及时调整测试方案。
    #对DevOps测试的一些思考

    DevOps中质量保证(QA)不再是测试人员的专属责任,而是全体人员都要为之努力的方向。测试人员提前介入到开发工作中,与开发人员一起制定测试计划;开发人员可以参与配置部署;运维人员可以向自动化测试用例库填写测试用例;测试人员随时将自动化测试用例配置到持续交付链中,所有成员的共同目的都是交付高效、高质量的产品。

    持续测试要求测试人员具有一定的编码能力。测试人员不但要掌握常用的测试工具、版本控制工具和集成工具的使用,还要能读懂代码,检查构建日志,不断的优化整个测试策略和测试用例。测试人员还必须参与到整个持续交付过程中,以最高效的方式保证产品的质量。

    测试人员应该专注于测试策略的不断优化。自动化测试固然是实现持续集成最重要的方式,但并不是所有的测试都适合自动化,比如易用性测试和界面一致性测试等。测试人员需要集中在不断的测试策略优化上,通过调整各种测试用例的比例、增加测试覆盖度、提高测试用例的质量以及快速的反馈来提高测试效率,实现全面的质量保障。

    原文链接:https://cloud.tencent.com/developer/article/1423363

    从技术雷达看DevOps的十年——基础设施即代码和云计算

    阿娇 发表了文章 • 0 个评论 • 169 次浏览 • 2019-05-24 15:27 • 来自相关话题

    从技术雷达看DevOps十年——DevOps和持续交付

    阿娇 发表了文章 • 0 个评论 • 192 次浏览 • 2019-05-24 15:02 • 来自相关话题

    从前端开发人员到DevOps:CI / CD 简介

    tiny2017 发表了文章 • 0 个评论 • 274 次浏览 • 2019-05-23 17:45 • 来自相关话题

    【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至 ...查看全部
    【编者的话】如果你是一名前端开发者,且认为作为一名开发人员只要管好前端这摊子就算大功告成了,那你就out了。原文作者从一个前端开发者的角度,阐述了DevOps的理念,并结合一些示例和实践,告诉我们了解并运用持续集成和持续部署的诸多好处。但我认为,原文作者从始至终传递给我们一种持续学习的精神,这一点同样值得我们学习。
    # 介绍
    对于有抱负的前端开发者而言,2019年是充满憧憬的一年。

    有不计其数的教材、课件和教程,每天还有无数的博客和文章,像雨后春笋般层出不穷。任何想成为专业人士的人都可以获得他们需要的一切——通常还是免费的。

    许多人抓住这个机会自学成才,而且他们当中很多人有机会参与完整的项目,可以迅速上手写功能模块,修改Bug并以适当的方式组建代码。

    经过一段时间,有些比较幸运的前端开发者就会在互联网的某个角落看到他们自己实现的功能模块,作为一个web app、门户或者一个website——对于初级开发者而言,这真的是一个荣耀的时刻。但令人惊讶的是,他们中很少有人会问一个非常重要的问题:我们开发的应用程序,是怎么放到互联网上的?
    1.png

    大家普遍认为这是由开发人员完成的,只不过是更“高级别”的开发人员而已。可能一些人听说过DevOps,运营商,云管理员,系统管理员以及其他更具神秘气息的东西。

    嗯,这是真的——在某种程度上,编码和测试成功后发生的一切通常都和脚本,Linux命令和容器之类的黑科技有关。还有一条不成文的规定是,只有组织中最有经验和最值得信赖的开发人员/管理员才有资格完成最后的交付工作。

    有必要这样吗?这确实是有一定道理的——毕竟,这是一项复杂且极其重要的任务。但是否就意味着这些技能只属于某些精英?当然不是。

    作为前端开发者,我们可以选择忽略这一切并相信其他人会完成剩下的所有事情——但我们不应该这样。IT世界的竞争瞬息万变,无论是前端还是后端,对于技术栈的点滴积累将会使你成为一名更具竞争力的开发者。

    如果你想在开发方面进步的更快或者在同龄人中脱颖而出,你迟早会需要这些知识。下面就让我告诉你为什么你会需要这些知识。
    # 为什么开发人员都应该尝试自动化处理
    正如我们前面提到的那样,写代码只是软件开发这个浩大的工程的一部分。我们先来看看任何产品交付所需的基本步骤——不一定是软件:
    2.png

    严格来说,我们在这里讨论的不一定都是编码。我们关注的是主要的开发阶段完成之后会发生什么?为什么它会如此重要?因为它有可能会很复杂 - 解决方案越严谨,这部分就越复杂。

    假设有一个具有一些特定功能的Web应用。我们假定该应用的版本会按照一个一个的功能定期发布,前提是发布到生产环境之前,每一个功能都会进行测试。
    3.png

    问题来了,我们一般不会只招一名程序员来完成这项工作, 即会有一个团队来负责这些功能。这些假设意味着——除了每个开发人员本地的编码环境和最终稳定的生产环境之外——最好还有一个“staging”环境来验证这些功能。在这个环境中,测试人员/客户可以在实际投入生产环境之前评估它们的质量。

    现在我们越来越接近这样的架构:
    4.png

    正如你所看到的,事情变得越来越复杂(相信我,我们在这里谈论的真的是一个非常简单的例子),但我们在这里不会涉及产品生命周期管理,我们只关注技术。

    假设前端开发人员需要几分钟来构建一个应用程序。如果关心代码质量,他们需要运行linting,单元测试,集成测试或者用其他的方式确认之后才能提交。这个过程很耗时。

    最后,将打包好的程序放到服务器额外还需要几分钟时间。如果我们给一个程序员分配了以上所有这些任务,请记住我们还没有考虑其切换上下文所需的时间(例如,更改代码分支,重新聚焦到他们的工作上等等)。

    现在,谁想要手动部署每个功能?如果每天都测试了三个新功能怎么办?如果有15个呢?依据不同的部署规模,很有可能需要一个以上的全职人员来处理上述任务。

    这就是为什么我们需要在这里运用计算机诞生之初的思想:我们应该用一台机器来为我们做这件事。
    # 持续集成和持续部署的好处
    在我们讨论用于构建,测试和部署代码的特定软件解决方案之前,我们先来熟悉一下描述该过程的两个术语。你可能已经听说过它们了:
    5.png

    注意,通常CD部分代表持续交付,这个概念略有不同,我们将不会在这篇文章中讨论。这种容易引起混淆的缩写通常是许多学术讨论的基础。Atlassian有一篇很棒的文章解释了它们之间的差异。

    为什么有两个单独的短语,它们到底是什么意思?不用担心——为了避免混淆,让我们先弄清楚一点,然后描述两者背后的普遍意义。

    CI / CD的持续集成部分涵盖了应用程序完整性的重复测试。从技术角度来看,这意味着我们需要不断执行linting,运行unit / E2E测试,检查源代码质量等。通过持续的方式,意味着必须在push新代码之前完成 - 即它应该自动完成。

    例如,CI流程中可以定义一系列单元测试,这些单元测试将在拉取代码请求时一起运行。这种情形下,每次更新代码时,例如对于开发分支,一些机器会检查它是否符合标准且没有错误。

    CI / CD的持续部署通常涵盖了构建和将应用程序部署到可用环境的一系列过程——这也是自动完成的。例如,它可以从指定的分支(例如:`master`)获取我们的应用程序代码,使用适当的工具(例如webpack)构建,并将其部署到正确的环境(例如,托管服务)。

    它并不只限于生产环境;例如,我们可以配置一个Pipeline(管道)来构建应用程序的“staging”版本,并将其部署到适当的主机用于测试。

    这两个术语是软件生命周期管理理论中完全不同源的独立概念,但在实践过程中,它们通常以互补的方式共存于一个大型Pipeline(管道)。为什么它们如此密不可分?因为通常CI和CD存在部分重叠。

    例如,我们可能有一个项目,E2E测试和部署都需要用webpack构建前端代码。同时,在大多数“严苛”的生产级项目中,还有许多流程既有CI又有CD。

    现在让我们想象在一个功能众多的项目中,CI / CD可以做些什么呢?
    6.png

    我知道越深入这个主题,流程图就越复杂 ——但是,这样一来在项目会议中用白板表示时,就显得很酷!

    现在试想一下我们可以从上面的流程中得到些什么呢?我们从因与果的角度来分析,可以通过抽象特定的场景形成假想的工作流程。例如:

    一名开发人员尝试push代码到公共代码库,然后需要执行一组单元测试。

    通过这种方式,我们可以清晰得知道什么时候开始行动 - 我们可以通过使用脚本或其他机制实现自动化。在将来使用CI / CD的过程中,你可以为这些场景化的Pipeline命名。

    注意上面的粗体字:当和然后,每个阶段都需要一个动作触发。为了运行特定的Pipeline,我们需要某种kickstart或触发器。这些可能是:

    • 计时类触发器(“每天下午6点构建staging版本的应用程序”)
    • 代码库触发器(“每次发布新的拉取请求时运行单元测试。”)
    • 手动触发器(“项目经理启动应用程序构建过程并部署到生产环境。”)
    当然也可以通过其他的触发器触发特定的Pipeline,尤其是当我们需要通过许多单独构建的部分集成一个复杂应用程序的时候。好吧,理论说的差不多了,现在来说说为我们完成这些工作的软件。# CI / CD中用到的软件基本上,每个CI / CD软件说到底只是某种类型的任务执行工具,当触发某些操作时会运行Job(任务)。我们的主要工作是通过配置的方式提示要完成哪些Job以及何时完成等。基于这些基本描述,CI / CD软件有许多类型,规格和偏好 - 其中一些软件非常复杂以至于手册都有数百页。但也不用害怕:在本文结束之前,你将熟悉其中一个。对新手而言,我们可以把CI / CD软件分为两类:
    • 可安装软件:可以在你的电脑上或某些远程机器上安装的应用程序或服务(例如,Jenkins,TeamCity)
    • SaaS:由一个外部公司通过Web界面的方式提供的应用程序或服务(例如,CircleCI,Azure DevOps)
    真的很难说哪一个更具优势,就像本文的主题一样,它取决于应用程序的要求,组织的预算和政策以及其他因素。值得一提的是,一些受欢迎的源代码托管商(例如,BitBucket)会维护自己的CI / CD Web服务,这些服务和源代码管理系统紧密联系,旨在简化配置过程。此外,一些云托管的CI / CD服务是免费且对公众开放的 - 只要该应用程序是开源的就可以。一个广受欢迎的例子就是CircleCI。我们将充分利用它的优势,简单几步就可以为我们的前端应用程序示例配置一个功能齐全的CI / CD的Pipeline。# 前提和计划CircleCI是一个云上的CI / CD服务,它能够与GitHub集成从而轻松获取源代码。该服务有一个有趣的规则:即pipeline在源代码内部定义。这意味着所有的操作和连锁反应都通过在源代码中配置一个特殊文件来实现,在CircleCI中是通过配置`.circleci`文件夹的`config.yml`文件实现的。本文为了实现教学目的,将执行以下操作:
    • 写一个简单的前端应用程序并将源代码公开放在GitHub上
    • 创建并push包含Pipeline的配置文件`config.yml`
    • 创建一个CircleCI帐户并关联GitHub帐户
    • 找一个地方部署应用程序(这里,我们使用Amazon S3的主机托管服务)
    • 最后,运行创建的Pipeline
    整个过程不应超过30分钟。接下来,我们来看看准备工作的清单。你需要:# 第一步:环境设置首先,从上述代码库签一个分支并克隆到本地计算机。如果你是新人,可以看下这波操作都做了什么。上述操作执行成功后,跳转到目标目录并执行以下命令:
    npm installnpm start
    现在打开浏览器输入到http://localhost:8080,你应该看到这样的画面:
    7.png
    这是一个非常简单的前端应用程序,表明成功加载了`.js`和`.css`文件。你可以查看源代码,它用了一个非常简单的实现机制。当然,你也可以用该教程中使用你自己的应用,只需要适当的修改创建脚本的命令就可以。只要程序是基于npm之类的工具创建的标准应用,应该都没有问题。在使用自动化流程进行持续集成、持续部署之前,需要先构建应用程序并手动存到S3。这样,我们才能保证目标环境的配置没有问题。首先,我们在本地构建应用程序包。如果你使用我们提供的示例程序,就可以用`npm run build`命令来创建,然后在项目的根目录底下得到一个名为`dist`的文件夹:
    8.png
    好了,我们的应用程序已经构建并打包完毕。你可以在测试服务器上执行`npx serve -s dist`命令查看它的运行情况。这个例子会运行一个`serve`包,它是一个轻量的HTTP服务器,可用来分发`dist`目录下的内容。运行完命令以后可以通过http://localhost:5000查看,你会发现和它在开发环境服务器中的运行结果一致。OK,我们把应用部署到互联网上,这要从S3开始。作为AWS生态圈的一部分,Amazon S3的概念非常简单:它提供了一个存储,可以上传任何类型的文件(包括静态HTML,CSS和JavaScript等)并启用简单的HTTP服务器来分发这些内容。最棒的是(在某些情况下)它是免费的!首先,登录:
    9.png
    AWS登录步骤1:提供登录用的电子邮箱
    10.png
    AWS登录步骤2:输入密码接下来,点击服务按钮并在存储项中选择S3,跳转到S3控制面板。
    11.png
    现在,我们将创建一个新的存储桶来存储我们的Web应用程序。首先,输入名称,名称只支持字母数字字符和连字符。然后,为存储桶选择适当的域。注意要记录这两个值,稍后会用到。
    12.png
    13.png
    有一点非常重要就是设置适当的权限,这样文件才是公开的类型。因此,单击下一步直到出现设置权限选项,然后点击取消前三个框以启用文件的公开托管方式:
    14.png
    这样,HTTP服务器就能将上传的文件作为网站公开。在设置完存储桶之后,你可以访问并查看文件列表:
    15.png
    点击上传按钮,系统将提示你选择要上传的文件,你可以从`dist`文件夹中选择三个包文件上传。这里的操作和之前的一样,一定要到设置权限处选择管理公共权限框下的对该对象赋予公共读取权限,这点非常重要。瞧!文件已经在了,最后一步是要在S3上启用托管服务。通过存储桶视图找到属性按钮,打开静态网站托管选项:
    16.png
    你需要添加`index.html`作为索引文档,它将作为应用程序的入口。现在,一切准备就绪。在对话框的开头会生成一个新站点的链接,点击就可以查看刚才部署的应用:
    17.png
    太棒了,我们有了一个网站——可惜这不是这次的目标,因为到此为止什么都没自动化。你肯定不希望用这种方式登录S3控制台并在每次更新时上传一堆文件,那是机器要做的事。那么,我们来建一个持续部署的流程吧!# 第二步:准备CircleCI配置如果仔细查看代码库中的示例程序,你会看见一个CD的定义文件,打开`.circleci/config.yml`文件。
    version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: trueworkflows:  version: 2.1  build:    jobs:      - build:          filters:            branches:              only: master
    如上所述,`config.yml`是CircleCI可识别的文件,它包含了CD过程中定义好的pipeline信息。本文的例子中,26行代码包含了以下的内容:
    • 构建应用程序需要哪些工具
    • 构建应用程序需要哪些命令
    • 应用程序在哪里以及如何部署
    如果你不熟悉YAML文件,你会注意到它大量使用制表格式。这就是这类文件的组织结构:每一部分都有子节点,而层次结构由一个有双空格组成的tab标志。现在,我们来逐层看一下文件结构:
    version: 2.1orbs:  aws-s3: circleci/aws-s3@1.0.4
    上面几行代码包含了解析器的版本信息,并定义了部署过程中会用到的附属包(CircleCI命名规则中的“orbs”)。在这里,我们需要导入一个名为`aws-s3`的orb ,它包含把文件发送到S3存储桶所需的工具。
    jobs:  build:    docker:      - image: circleci/python:2.7-node    environment:      AWS_REGION: us-east-1    steps:      - checkout      - run: npm install      - run: npm run build      - aws-s3/sync:          from: dist          to: 's3://demo-ci-cd-article/'          arguments: |            --acl public-read \            --cache-control "max-age=86400" \          overwrite: true
    上面几行代码包含了Job的定义信息,即Pipeline的核心内容。这里要注意的一点是,像上述第二行中所示我们把Job命名为`build`,稍后我们会在CircleCI控制台的报告中看到这个名字。下一行写着`docker`,这部分我们定义创建应用的容器(在哪台虚拟机运行)。如果不熟悉容器或者Docker,这一步你可以想象成选择一台虚拟机然后创建应用。这里,有一台预装了Python和Node.js的Linux虚拟机,我们需要用Python运行AWS S3的工具,用Node创建前端应用。`environment`和`AWS_REGION`是AWS运行用的环境变量,可以不用在意具体的参数。到此,S3就能运行了。下一部分,`steps`更具自描述性。实际上,它是完成Job需要执行的一系列步骤。这部分的示范定义如下:
    • `checkout`:从代码库中获取源代码
    • `run: npm install`:安装依赖包
    • `run: npm run build`:Pipeline的核心,用于构建代码
    • `aws-s3/sync`:另一个重要步骤,它部署(“同步”)S3存储桶中给定的`dist`路径下的内容。注意,这个示例把`demo-ci-cd-article`作为存储桶的名字,你需要修改存储桶名字,使它和示例中的名称一致。

    # 解析CircleCI配置
    基本上,你可以把它想象成运行在本地的一个包含一组操作的job,这样就是告诉VM一步一步如何完成。当然,你也可以认为它是具备一些特定功能的特殊的shell脚本。

    job有一个重要原则那就是每一个步骤都得成功。有任何一个命令失败,就不再执行后续操作,当前的pipeline的状态也会标记为`FAILED`。Job执行失败的信息会在CI / CD控制台中显示,包括相关错误日志,有助于排错。

    失败的原因有很多,比方说,对于一个执行自动测试的pipeline,它可能意味着一次单元测试的失败并且某个开发人员需要修复他的代码,或者也有可能是工具的配置有问题,从而导致构建和部署失败。无论是什么原因,CI / CD流程通常会通过电子邮件的方式通知管理员(或本人)执行失败的消息。

    这就是为什么要以相对安全的方式定义jobs,以便在执行某一步出错时,确保之前的步骤不会产生任何永久的负面影响。

    马上就要结束了,最后一部分是`workflows`:
    workflows:
    version: 2.1
    perform_build:
    jobs:
    - build:
    filters:
    branches:
    only: master

    在CircleCI中“workflow”是一组互相协作的Job。由于之前我们只定义了一个Job(`build`),我们可以暂时不考虑这部分。但是,通过定义工作流的方式可以实现一个很重要的功能:branch filtering(筛选分支)。

    你可以看到配置文件中的最后2行定义了`filters`。在这个例子中,它包含了`branches: only: master`,即定义了只有主分支上的代码更新才会执行构建代码Job。

    这样就可以通过CI / CD流程筛选出需要“watched(监控)”的分支。例如,可以在不同的分支上调用不同的工作流(包含不同的Job),然后构建单独的版本,或仅在特定情况下测试等。
    # 最后一步:CircleCI实践
    如果你还没有完成,通过登录GitHub的方式,关联你的GitHub帐户与CircleCI
    18.png

    登录GitHub并授权给CircleCI后,你会在导航栏看见一个Add Project(添加项目)的选项。点击它可以查看你在GitHub中的代码库列表:
    19.png

    不管是拷贝的示例还是你自己准备的应用(记住有一个`.circleci/config.yml`文件),先假设你已经有一个代码库了。
    然后,在列表中找到该项目后单击旁边的Set Up Project(设置项目)选项。你会看到一个描述CircleCI规则的画面:
    20.png

    看到底部Start building(开始构建)的按钮了吗?是的,就是它。点击它来启用我们的自动化流程,让机器为我们工作。
    点击这个按钮后,你会看到……一个错误提示。
    21.png

    好吧,我们还需要配置一个地方:让CircleCI API授权给AWS的机制。到目前为止,我们还没有把AWS密码放入代码,GitHub或CircleCI里,所以AWS还不知道我们要把东西放入S3,所以报错。

    通过改CircleCI面板中的项目设置来配置。单击右上角的齿轮图标,然后在左边找AWS权限选项卡,你会看到以下画面:
    22.png

    Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)是AWS的2个鉴权值,用于对CircleCI等第三方服务的鉴权。例如,将文件上传到S3存储桶。最初,这些密钥将具有与分配给它们的用户相同的权限。

    你可以通过AWS控制台的IAM生成这些信息。进入IAM,打开访问秘钥Access Key ID(访问秘钥ID)Secret Access Key(加密访问秘钥)】窗口,点击创建新的访问密钥,生成可以复制到CircleCI的密钥对:
    23.png

    单击Save AWS keys(保存AWS秘钥)就可以了。你可以在CircleCI上尝试重新初始化代码库,也可以用更加快捷的方式:找到失败的报告,然后点击Rerun workflow(重新执行)工作流程按钮。
    24.png

    现在所有的问题都搞定了,构建应用应该不会再出状况了。
    25.png

    太棒了!你可以登录S3控制台并检查文件的修改时间,可以证明文件是新上传的。不过还没完事呢,我们来看看“持续”部分是如何工作的。我将返回代码编辑器,说一下应用(`index.html`)的一个小的变动:
    26.png

    现在,我们可以将代码推送到代码库:
     git add .
    git commit -m “A small update!”
    git push origin master

    神奇的事情发生了。眨眼之间,在成功推送后,CircleCI已经在用更新后的代码构建应用了:
    27.png

    几秒钟后,会有一条执行`SUCCESS`的消息。现在,你可以刷新一下S3托管的web页面,就可以看到修改后的应用:
    28.png

    搞定!这一切都是自动执行的:推送完代码后互联网上的一些机器自动构建并部署到生产环境中。
    # 进阶练习
    当然,这只是一个简单的例子。现在我们来看一个更复杂的例子。例如,部署到多个环境并更改应用。

    回到我们的示例代码,你会发现在`package.json`中有两个独立的构建脚本:一个用于`production`环境,一个用于`staging`环境。由于只是一个示例项目,所以不会发生大的变更。这里,它只是用一个不同的JavaScript控制台消息表示而已。

    应用在`staging`环境运行之后打开浏览器,你可以在JavaScript控制台看到相应的日志信息:
    29.png

    现在,我们利用这个机制扩展构建应用的pipelines。请看以下的代码:
    version: 2.1
    orbs:
    aws-s3: circleci/aws-s3@1.0.4
    jobs:
    build:
    docker:
    - image: circleci/python:2.7-node
    environment:
    AWS_REGION: us-east-1
    steps:
    - checkout
    - run: npm install
    - run: npm run build
    - aws-s3/sync:
    from: dist
    to: 's3://demo-ci-cd-article/'
    arguments: |
    --acl public-read \
    --cache-control "max-age=86400" \
    overwrite: true
    build-staging:
    docker:
    - image: circleci/python:2.7-node
    environment:
    AWS_REGION: us-east-1
    steps:
    - checkout
    - run: npm install
    - run: npm run build:staging
    - aws-s3/sync:
    from: dist
    to: 's3://demo-ci-cd-article/'
    arguments: |
    --acl public-read \
    --cache-control "max-age=86400" \
    overwrite: true
    workflows:
    version: 2.1
    build:
    jobs:
    - build:
    filters:
    branches:
    only: master
    build-staging:
    jobs:
    - build-staging:
    filters:
    branches:
    only: develop

    注意,我们添加了一个新的job和一个新的`build-staging`工作流程。有两点不同:新job调用前面提到的
    `npm run build:staging`方法,同时用`develop`分支进行筛选。

    这意味着所有到`develop`分支的推送都将用“staging”构建,而`master`分支上的所有变更都将保留其原始状态并触发“production”构建。在这里,双方都会在同一个S3存储桶中,但我们可以修改并让它们在相互隔离的目标环境中运行。

    可以试一下:基于`master`分支创建一个新的`develop`分支并将代码推送到代码库。在CircleCI控制台,你会看到调用了不同的工作流程:
    30.png

    相应的变更推送到了S3存储桶,但这次在staging上构建来自`develop`分支的应用,实现了多版本的构建工作。很好,我们马上就能实现之前描述过的工作流程啦!
    # 持续集成部分
    我们已经完成了持续部署部分的内容,但什么是持续集成呢?正如之前说过的,这部分涉及到定期检查代码的质量,例如:执行测试。

    如果仔细看示例的代码库就可以看到有一个单元测试样例,可以用`npm run test`命令执行该测试样例。它通过断言的方式比较了某些模式下虚函数的结果。
    function getMessage() {
    return 'True!';
    }

    // ...

    module.exports = getMessage;


    const getMessage = require('./jsChecker');
    const assert = require('assert');

    assert.equal(getMessage(), 'True!');

    我们可以在管道中加入测试,然后设置成在每个拉取请求时执行就可以。实现方式是在`config.yml`里创建一个新job和一个新的工作流程:

    config.yml



    version: 2.1
    orbs:
    aws-s3: circleci/aws-s3@1.0.4
    jobs:
    build:
    # ...
    build-staging:
    # ...
    test:
    docker:
    - image: circleci/python:2.7-node
    steps:
    - checkout
    - run: npm install
    - run: npm run test
    workflows:
    version: 2.1
    build:
    # ...
    build-staging:
    # ...
    test:
    jobs:
    - test

    我们已经定义了一个新job和一个名为`test`的工作流程,唯一的目的是触发`npm run test`脚本。然后,将此文件推送到代码库,看一下CircleCI控制台会发生什么:
    31.png

    一个新的工作流程被自动触发,并完成了一次成功的测试。接下来把它和GitHub的代码库进行对接,这样一来每次拉取特定分支的请求都会触发该job。要实现这一点,只需要打开GitHub页面并到Settings(设置)页面,选择Branches(分支)
    32.png

    单击Add rule(添加规则),就可以添加一个新的策略。该策略将在合并拉取请求之前强制执行一系列检查,其中一项检查就是调用CircleCI工作流程,如下所示:
    33.png

    通过勾选Require status checks to pass before merging(合并之前要检查状态)并勾选的`ci/circleci: test`,就可以将规则设置为在拉取前执行该工作流。

    该规则可以通过创建一个新的拉取请求来测试,然后打开Checks(检查)面板来查看测试情况:
    34.png

    当然,也可以测试该规则无效的情况。你可以提交一个会导致测试失败的变更,把它放到一个新分支上并执行一个拉取请求:
    35.png

    我们模拟了一个失败的测试,输出结果如下:
    assert.equal(getMessage(), 'True!');
    -->
    [quote] node src/modules/jsChecker.test.js
    assert.js:42
    throw new errors.AssertionError({
    ^
    AssertionError [ERR_ASSERTION]: 'True, but different!' == 'True!'
    at Object.

    现在这个拉取请求将无法合并,因为它引入了导致测试失败的代码:
    36.png

    赞!我们的示例项目成功覆盖了连续测试的各种情况,只要测试用例没问题,就不可能把错误的代码引入到生产分支。同样的机制还可用于执行代码linting,静态代码分析,E2E测试和其他自动化检查等。[/quote]

    好的,就这样!虽然我们的示例项目非常简单,但它展现了真实且有效的CI / CD流程。无论是集成还是部署都由云上的工具执行,所以开发者可以将所有注意力集中到编码上。

    无论涉及多少人,机器都将不知疲倦地工作,并检查一切是否到位。虽然设置这一切也需要花费一些时间,但从长远看,把机械性操作进行自动化处理是非常有意义的一件事。

    当然,它不是永远的免税天堂:迟早会产生额外的费用。例如,CircleCI每月提供1,000分钟的免费构建。对于小型团队和简单的开源项目来说足够了,但对大型的企业级项目而言肯定会超过这个配额。
    # 延伸阅读
    我们学习了许多基础的知识,但这篇文章还有许多重要的内容还没来得及讲解。

    有一点就是如何更好的使用环境变量。通常我们都不会直接在源代码中保存密码,API密钥和其他敏感信息。当引入CI / CD自动化流程后,首先需要向机器提供适当的变量,就像我们在示例中使用AWS密码一样。

    除此之外,环境变量来可以用来控制构建的过程,例如:应该构建哪个或者应该在特定版本中启用哪些特征之类。你可以通过它们在CircleCI中的使用这篇文章中获得更多的信息。

    另一个是:许多CI / CD流程引入了组件管理的概念。组件是对特定构建过程中产生的代码的通称。例如,一个包或具有特定版本的应用程序的容器镜像都可以看做组件。

    在特定组织中,由于各种原因导致对组件版本的管理变得格外重要。例如:它们可能会被归类和归档以便用于回滚或其他用途。

    另一个重要的部分是角色、权限和安全性。这篇文章涉及到定义Pipelines和工作流的基础操作,但在大型、真实的项目中,有必要将组织的流程和策略等考虑在内。例如,我们希望某个Pipeline只能由公司组织架构中的某个人调用或批准。

    另一个例子是对特定管道的设置或VM的配置进行细粒度的控制。但同样,这取决于用什么软件以及特定项目或公司的要求,好的自动化流程没有一个单一的范式,就像好的IT项目没有单一的模式一样。
    # 总结
    好了,言归正传。

    不知道这篇文章会让你有什么样的收获?重要的是,现在你已经对一些“重大”的项目中发生的事情有了一个大致的了解。无论使用何种方法和软件,一些基本的规则总是相似的:有任务、管道和代理执行此工作流程。希望通过这篇文章,会让你对许多概念有一个新的认识。最后,你可以试着创建实际工作中用到的CI / CD Pipeline,并用自动化的方式将应用部署到云上。

    接下来你还可以做什么呢?

    当然,继续扩充你的知识,努力做的更好。如果你正在为公司开发项目,可以尝试写写代码,创建你自己的测试/部署pipeline。你可以(甚至应该)在你的下一个开源项目中引入自动化测试、打包等。您还可以了解更多的CI / CD软件:例如Travis,Jenkins或Azure DevOps。

    此外,你还可以查看我的个人资料中与前端开发相关的其他帖子。祝你好运!

    原文链接:From front-end developer to a DevOps: An intro to CI/CD (翻译:Tiny Guo)