火力全开 | 持续集成、持续交付 | 5分钟了解一个容器典型应用场景系列

5分钟了解一个容器典型应用场景系列篇

关于容器解决方案的概念、架构、成功案例,笔者已经分享了很多了。为了使读者能够花更短的时间,迅速感性地解容器的典型应用场景。笔者从今天开始,推出“5分钟了解一个容器典型应用场景”系列片。每次分享一个场景,采用文字描述+视频展示的方式。本系列分享内容将分别是:灰度发布、CI/CD、开发自动化、微服务、业务弹性扩展。

声明:本实验基于红帽淡成等专家提供的实验步骤和实验环境/脚本整理而成。在此表示感谢。

本系列第一篇:火力全开 | 灰度发布 | 5分钟了解一个容器典型应用场景系列

概念介绍

持续集成与持续交付(CI/CD)

谈到敏捷开发与自动化,可能大家第一时间想到的是devops(开发运维一席话)。而实际上,从传统的开发模式,提升到devops,至少需要如下几个阶段:

持续集成(CI)==>持续交付(CD)==>持续部署==>Devops。

在四个阶段中,前一个阶段是后一个阶段的基础,随着阶段的提升,每个概念覆盖的流程越来越多,而DevOps则是终极目标。

客户在自身的IT环境中,使用持续交付还是持续部署,抑或推广devops,这更多是从企业内部的规章制度或自身业务特点方面来考虑;从技术方面,openshift能够实现devops全流程的打通。

持续集成的目的,在保证高质量的基础上,就是让产品可以快速迭代。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。所以说,持续交付,持续交付是将持续集成产生的软件,进行自动化测试。

持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。持续部署与持续交付的区别,是当代码在dev阶段测试通过后,自动部署到生产。具体可以参考下图。

而DevOps则是覆盖从开发到运维的全流程,并且是自动化完成的。

操作步骤

本篇实验所分享的是CI/CD。

在实验中,第一步首先创建一个项目用于测试。

第二步,创建jenkins的服务。需要注意的是,在openshift3.4版本中,jenkins已经与openshift做到深度集成,统一认证。部署完成后的jenkins,可以通过openshift账号直接登录。而这里,我们用到的jenkins的容器镜像,也是红帽认证过的镜像。

第三步,通过已经写好的json文件部署pipeline。需要注意的是,这个json(pipeline.json)文件中不仅定义了pipeline的各个阶段,还定义了其管理的应用。

查看json配置文件的阶段定义(为了方便读者看清,笔者将代码贴出来):

"jenkinsfile": "node(){\n \nstage '编译构建容器镜像'\n sleep 1 \necho '编译构建容器镜'\n \nstage '开发环境部署'\nsleep 1 \necho '开

发环境部署'\n \nstage '测试环境部署'\nsleep 1 \necho '测试环境部'\n \nstage '确认测试通过'\nsleep 1 \ninput '测试是否成功?'\n \nstage '生产环境部署'\necho '生产环境部署'\n}"

而json配置文件中这段代码的定义,当pipeline创建好以后,将会以如下方式展现,五个阶段是完全对应的。

在json中,其对所管理代码的定义如下,是php:

第四步,触发pipeline。应用将经历“编译构建容器镜像”、“开发环境部署”、“测试环境部署”、“确认测试通过”

此时,下发操作指令(点击Input Required),批准还是拒绝。这步是通过链接到jenkins来实现的。而正是这一步,说明了持续交付与持续部署的区别。(前者需要人为批准测试成功的代码是否部署到生产上,后者自动部署到生产环境上)。

如果点击Proceed,那么测试成功的代码将会部署到生产环境。如果点击Abort,那么操作将终止,测试成功的代码不会部署到生产上。如果成功部署到生产上,那么pipeline将如下显示。

操作视频

总结

本文简单地展示了Openshift持续集成、持续交付的功能。在实验展示中,我们也能够清晰地认识到了持续交付与持续部署之间的差别(前者需要人为批准测试成功的代码是否部署到生产上,后者则直接自动部署到生产环境)。而客户在自己的IT环境中,使用持续交付还是持续部署,抑或推广devops,这更多是从企业内部的规章制度或自身业务特点方面来考虑;从技术方面,openshift能够实现devops全流程的打通。

原文发布于微信公众号 - 大魏分享(david-share)

原文发表时间:2017-03-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏web前端教室

【流行】现在前端流行的技术是哪几种?

其实从根本上来讲,前端开发过去、现在、将来,至少在可能预见的将来,有且只有三种技术,就是html、css、js,其它的都是围绕着这三种技术在打转。

17030
来自专栏云计算D1net

克服多云管理的6种工具

如今,服务器的数量正在激增,而现在的工作将由数十台、数百台甚至数千台服务器进行处理。以往人们可以用Word或Excel文档中的剪贴板或清单直接保存所有内容,现在...

51630
来自专栏子勰随笔

SDK那些事(总纲)

366100
来自专栏哲学驱动设计

企业 SOA 设计(2)–组件化产品开发平台

上一篇《企业 SOA 设计(1)–ESB 设计》中,写到我们的 SOA 设计分为两个层面来进行:一个是系统间的 SOA 设计,主要通过 ESB 来完成;另一方面...

23150
来自专栏CDA数据分析师

搭好数据架构,这7个技术是关键

? 本文转自网络,如涉侵权请及时联系我们 企业IT基础设施平台的重新构建是一项复杂的任务。重新构建平台通常由一系列变化的关键业务驱动因素引发,现在情况正是如此...

42450
来自专栏程序你好

微服务中能付出什么, 得到什么

10030
来自专栏韩伟的专栏

游戏服务器端有什么特别

在游戏服务器端开发所有要面对的问题中,有两个是最核心和最普遍的:一是和客户端的通讯;二是游戏登录用户的数据处理。

1.2K140
来自专栏Java后端技术栈

2018年微服务将疯狂至死?带你领略不一样的思维历程!

原文作者:Dave Kerr;原文地址:https://www.jdon.com/49261

20340
来自专栏云计算D1net

为企业内部部署的应用程序创建一个云开发环境

借助来自许多成熟的公有云服务的精心策划部署策略的内置工具,企业组织机构的IT团队可以——而且也应该将他们的测试/开发迁移到公共云服务了。 即使您企业在短期内不会...

29140
来自专栏娱乐心理测试

关于iOS实现前台,后台,锁屏或关闭app语音播报

98740

扫码关注云+社区

领取腾讯云代金券