基于容器化PaaS平台的DevOps建设规划.docx

1、基于容器化PaaS平台的DevOps建设规划 基于容器化 PaaS 平台的 DevOps 建设规划 DevOps 要实现从项目管理、开发、测试、部署、运维、监控反馈整个应用生命周期的管理和治理，涉及的流程和工具链还是很多的。证券企业无论在人力还是技术积累等方面往往都是相对薄弱的，所以基于容器化 PaaS 平台的轻量化 DevOps 平台可能在一段时间内是相对适合的，能以低成本学习投入更快的提升研发和运维的效率。为此， twt 社区也邀请到了行业和领域技术专家以及红帽资深解决方案架构师分享了他们的容器云项目实践经验，并解答了社区会员提出的很多典型问题，由社区专家Steven99进行了全面的梳理和

2、总结，希望对大家有所帮助和借鉴。一、 容器化 PaaS 平台和 DevOps 的关系讨论【Q1】如何理解容器云平台和 DevOps 之间的关系 ? 基于容器化 PaaS 平台的 DevOps 有什么优势？【A1】 Steven99 某证券公司 软件架构设计师：容器云平台可以是DevOps的一部分, 也就是提供运行时环境,部署运维日志监控反馈等基于容器云平台的DevOps是轻量的, 或者用于PoC测试目的的,在于快速构建环境和完成部署.节省成本,维护工作量也相对较小.适合中小公司或者对研发等并不是要求特别高的公司.建议根据自己的实际情况选择合适的方式,devops建设并不容易,也不仅仅是开发运维

3、这么简单,流程、标准、度量、奖惩、组织、后勤保障等都密切相关【A2】 rechen 某大型银行 云计算架构师：1、容器云平台，需要DevOps以标准化和提升IT研发和交付能力。DevOps可以部署在容器云平台上。2、基于容器化PaaS平台的DevOps，可以使用容器云的资源，譬如DevOps平台的相关技术组件，可以以容器方式部署在容器云上，以支持多pipeline流水线并发编译所需要的弹性资源。【A3】魏新宇 红帽 资深解决方案架构师：广义上的DevOps建设会包含：人、流程、工具等多方面内容。IT 厂商提供的微服务和 DevOps 主要指的是工具层面的落地和流程咨询。在 Kubernetes

4、 和容器普及之前，我们通过虚拟机也可以实现DevOps，只是速度相对较慢，因此普及性不高（想象一下通过 x86 虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为 DevOps 工具层面的落地提供非常好的承载平台，使得这两年容器云平台风生水起。这就好比 4G （ 2014 年出现）和微信（ 2011 年出现）之间的关系：在手机网速 3G 的时代，流量按照兆收费，（即使有）大家对于微信语音聊天、微信视频也不会太感兴趣。到了 4G 时代，网速提高而且收费大幅下降，像微信这样的社交和互联网支付工具才能兴起和流行。OpenShift 以容器技术和 Kubernetes 为基础，在此之上扩展提

5、供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（ S2I/Jenkins ）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，实现DevOps落地效率比较高。【Q2】想要落地devops的话，只考虑好的paas容器平台就够了么？【A1】wykkx 某基金公司 系统架构师：还差的非常远。devops是以业务需求驱动为主体，需要打通业务，项目管理，开发，测试，运维一整套流程的。这里涉及的不仅仅是技术问题，更多的是文化，管理，技术的一个整体的规划。所以要想落地devops，简单来说，首先需要形成一个整体的规划，其次需要引入工具平台支持，这个工

6、具平台是否为paas容器平台，没有任何关系。最后，在工具落地后，采用mvp原则，让大家看到收益，然后进一步推广。【A2】 Steven99 某证券公司 软件架构设计师：确切地说远远不够DevOps涉及的东西很多，开发运维项目管理全过程都密切相关。DevOps的目的是提升效率，所以不在于用什么平台，而在于根据企业实际情况选择合适的组件和流程、工具、方法、组织架构、奖惩措施等，尽可能以自动化的方式高效交付，同时激励相关人员的主动性，提高规范化和标准化要求，这是一个螺旋提升的过程，一个不断完善的过程【A3】gxcornflakes 某金融单位 信息技术经理：DevOps是一种理念，是轻量级的ITIL

7、，技术部一般基于ITIL提供服务目录完成服务请求，中间有复杂的审批、手动操作，DevOps将服务流程规范化、标准化并通过自动化技术实现pipline，提升工作效率。要想落地DevOps，关键是思维和理念的提升，再次是团队的变革，还有平台和工具的支持。PaaS仅仅是一个支持平台，解决一部分问题。【A4】魏新宇红帽 资深解决方案架构师：容器云只是DevOps的底座。这个底座上面还需要很多内容，我们仅以工具层举例：项目管理：禅道、 Jira 、 Trello 等。知识管理：MediaWiki 、 Confluence 等。源代码版本控制（ SCM ）：GitHub 、 Gitlab 、 BitBuc

8、ket 、 SubVersion 、 Gogs 等。代码复审：Gitlab 、 Gerrit 、 Fisheye 等。构建工具：Ant 、 Maven 、 Gradle 等。持续集成（ CI ）：Jenkins 、 Bamboo 、 CircleCI 、 Travis CI 等。单元测试：Junit 、 Mocha 、 PyUnit 等。静态代码分析：Findbugs 、 Sonarqube 、 CppTest 等。测试用例管理：Testlink 、 QC 等。API 测试：Jmeter 、 Postman 等。功能测试：Selenium 、 Katalon Studio 、 Watir 、

9、Cucumber 等。性能测试：Jmeter 、 Gradle 、 Loadrunner 等。配置管理：Ansible 、 Chef 、 Puppet 、 SaltStack 等。监控告警：Zabbix 、 Prometheus 、 Grafana 、 Sensu 等。二进制库：Artifactory 、 Nexus 等。镜像仓库：Docker Distribution 、 Harbor 、 Quay 、 Nexus3 、 Artifactory 等我们再看一个图，其中的OpenShift是底座，上面有很多工具。【Q3】PaaS平台和DevOps平台的融合和边界问题？【A1】 rechen 某

10、大型银行 云计算架构师：1、PaaS平台和DevOps平台融合为一还是分开建设，这和每家单位的组织机构有关系。如果工程管理的平台和工具，已经有一个单独的职能部门在负责，则DevOps平台由此部门承接。此时，PaaS平台宜分开建设。2、 分开建设的话，PaaS平台和DevOps 的边界在容器镜像，一般情况有通过容器仓库进行交互。【A2】魏新宇红帽 资深解决方案架构师：如果按照客户的IT建设，是先有IaaS，再有容器云/PaaS。关于PaaS和IaaS边际，以OpenShift4为例，虚拟机及以下，是IaaS层；虚拟机中的操作系统及以上，是PaaS层。这主要是因为OpenShift的宿主机操作系统

11、已经被OpenShift统一纳管了。关于IaaS和PaaS统一还是分开建设，这取决于具体的情况。1.对于大的银行，客户的IaaS未必只承载容器云，可能还承载大量的虚拟机上的应用，因此统一建设有一定难度。况且IaaS通常有专门的部门的负责。2.对于中小金融的某个单的的项目，比如容器云项目，在符合公司的规划下，可以考虑IaaS和PaaS统一建设。现在OpenShift4可以通过Machine API对IaaS（如vSphere，红帽OpenStack，AWS，Azure）进行纳管。【Q4】如何规划容器化PaaS和DevOps？【A1】魏新宇红帽 资深解决方案架构师：可以把容器云平台理解成航母，把容

12、器云上的容器化应用理解为航母舰载机。PaaS、DevOps、微服务这三个概念，不是纯IT技术技术术语。在容器云普及之前，这三个概念就已经有了。无非是如何技术落地的问题。没有容器云，通过虚拟机也能实现 PaaS、DevOps、微服务 。只是相对效率低一些，所以之前这些技术也没被大规模使用。容器云为 PaaS、DevOps、微服务提供了非常好的技术落地实现。云原生是近两年兴起的概念。这个概念大体就是纯IT领域的术语了。2018 年， CNCF 组织对云原生进行了重新定义“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、

13、微服务、不可变基础设施和声明式 API ”。从 CNCF 对云原的定义来看，它和容器、服务网格、微服务等技术是密切相关的。云原生的范畴更广，包含了轻量级的应用开发框架内容。【A2】mtming333 甜橙金融翼支付 系统运维工程师：容器：船上的集装箱容器云：很多船上的集装箱容器化 PaaS ：很多船上的集装箱的指挥中心混合云：租赁船上的集装箱 + 自购船上的集装箱DevOps ：造集装箱货物的人和管集装箱的人都在船上一起干活微服务：集装箱里的货物云原生：未经改装拿来就用的公共船、集装箱、指挥中心【Q5】使用容器平台做devops对比使用虚拟机环境做devops有什么优缺点？【A1】 reche

14、n 某大型银行 云计算架构师：1、使用虚拟机环境做devops，优点是虚拟机环境能够完整支持windows，linux等环境。使用容器平台做devops一般以linux容器环境为主。2、如果单位已经建设有容器平台且有团队研发和运维，则建议优先选择使用容器平台做devops，实施成本可平摊，在容器平台上做DEVOPS已经有很成熟的技术方案，实施难度不大。且能够获得较好的扩展性。3、如果单位没有容器平台的基础设施支持，而且像VMWARE的虚拟机环境，则建议使用虚拟机环境做 DEVOPS，是实施成本小，难度小。其扩展性可以使用云管平台或者自动化脚本来实现。【Q6】IaaS、PaaS、SaaS、Dev

15、Ops等概念技术在业务领域的着重点？【A1】 rechen 某大型银行 云计算架构师：1、从业务领域角度看，IaaS, PaaS, DevOps的建设，是IT部门能够提升研发效能和交付效率。而SaaS则更贴近业务，业务部门可以承接运营，直接面向市场为客户提供服务。【A2】wykkx 某基金公司 系统架构师：iaas平台主要是提供计算/存储/安全/网络方面的能力，即基础设施即服务，主要的建设部门是数据中心或者是运维部门；paas平台主要提供中间件能力/数据服务能力/编码服务化能力，主导部门主要是运维部门和开发部门；saas是软件即服务，一般把IT作为成本中心的企业（例如银行/证券等），是很少提供

16、saas服务的。Devops主要是以业务驱动为核心，满足业务需求，打通业务/需求/开发/测试/运维一整套流程，devops的落地是一整套管理/文件/工具落地的集合体，目的是为了以最低成本和最快速度实现业务需求，实现业务价值。二、 在金融证券行业的场景讨论【Q7】容器化PaaS平台在证券行业的应用前景和场景是什么？【A1】wykkx 某基金公司 系统架构师：首先对这个问题进行拆解，容器化和paas平台两者没有必然的联系。容器化可以做iaas层的一种承载方式，也可以是paas层，saas层的承载方式。paas平台可以基于容器或者虚拟机部署，提供诸如中间件服务、数据库服务、devops流水线、分布式

17、链路跟踪等能力。其次，paas平台的能力，在证券行业可能有80%的场景是为自研应用服务，（外购系统很多出于产品化的原因都是做了完整的自包含），所以在设计paas平台时，应该多收集开发团队的需求点。最后谈下devops与容器，其实devops的落地与容器并没有太强的关联，只是说目前商用的容器平台利用镜像的特点和容器平台多租户的特点，较为便捷的落地了devops。但是基于虚拟机的方式实现devops也并不难，所以两者在我看来没有促进与否的问题。【A2】mtming333 甜橙金融翼支付系统运维工程师：我倒觉得应该是容器化PaaS平台去促进DevOps落地，做好了容器paas，用户爱用了，才能继续d

18、evops的工作流程改造【A3】魏新宇红帽 资深解决方案架构师：我咨询过一些证券行业的IT专家，目前证券行业使用容器，主要是少量的中间件容器化。在容器云的使用上，金融行业里保险公司走的快一些，有的保险公司基于容器云承载互联网核心、销售管理系统等业务。因此对于证券行业而言，后续互联网接入、DevOps的流水线，可以迁移到容器云，提升效率。【A4】gxcornflakes 某金融单位 信息技术经理：1、容器化PaaS平台在证券行业的应用前景和场景是什么？随着证券行业应用系统自主化建设，PaaS容器云将应用越来越广泛，主要场景有几个方面：1、互联网应用系统；快速部署，弹性伸缩；2、微服务（中台应用）

19、；3、大数据人工智能应用；2、如何结合DevOps促进容器化PaaS平台的落地？DevOps一种文化，即轻量级ITIL理念。DevOps的思想是要求作业流水线化实现自动化，即要求流水线的每个step标准化、规范化，而PaaS容器平台落地就是对资源和应用的标准化，所以DevOps和PaaS是相互促进【Q8】金融行业如果从全局数字化运营的角度规划整套DevOps平台？【A1】 Steven99 某证券公司 软件架构设计师：这个内容就太多了，devops提供敏捷的研发运维流程、工具、方法、规范等。但它也仅是数字化转型中的一小部分。数字化转型重点在于利用金融科技实现业务的变革和创新，业务模式的变革和创

20、新。这需要公司全局的规划和布局，不同公司的情况不一样，路经和方法也可能不一样，适合自己的事最好的。但有一条需要记住，提高效率！无论是开发运维效率或者是业务响应效率，这是devops等需要首先的目的【A2】 rechen 某大型银行 云计算架构师：组织架构上要有充分的保障，DEVOPS团队的人员除了负责平台建设，流程规范，还要负责运营和推广培训。一种比较好的安排是由项目管理团队负责规划和实施DEVOPS平台【Q9】证券行业一流券商容器化目前已经涉及到哪些应用场景？【A1】魏新宇红帽 资深解决方案架构师：据我了解是互联网渠道接入和部分中间件的容器化。但我觉得后续场景会越来越多，尤其是DevOps和

21、互联网接入层，比较适合证券行业对突发大访问量业务的需求。【A2】 Steven99 某证券公司 软件架构设计师：弹性伸缩、环境一致性、灰度发布、服务治理、多集群容灾备份、中台支撑、平台融合等【Q10】券商适合云上的容器还是需要自建容器平台？【A1】魏新宇红帽 资深解决方案架构师：对于大型银行来讲，一定是用在数据中心内建私有云，一方面出于数据安全，一方面是技术自主可控。对于券商而言，可以考虑公有云和私有云混合的模式，比如互联网的接入，可以放到公有云上，但容器云核心的部分，最好自建，而且使用开源的方案，避免被锁死。【A2】 Steven99 某证券公司 软件架构设计师：不同公司有不同的想法和做法，

22、取决于你怎么看待数据价值，以及云厂商有多大程度的可信度，公有云的可靠性、可用性等能力就我们而言，自建的容器云平台，是支撑众多业务系统的基础平台，也是devops中的重要运行时部分。三、 Openshift应用讨论【Q11】Openshift 作为一种容器技术有开源和商用，那么目前有哪些服务场景在使用？【A1】 rechen 某大型银行 云计算架构师：生产环境建议采用openshift商用版本。openshift能够承载java平台，.net core平台的业务应用系统，包括OA办公，内部管理，在线交易系统。【A2】 ypl75 金融业 工程師：我们公司目前运用在网络银行、行动银行及API管理系

23、统。【A3】魏新宇红帽 资深解决方案架构师：OpenShift本身是一个开源的软件，它有还有对应的社区版本OKD。这就和RHEL和CentOS的关系。在金融行业，目前银行和保险行业使用OpenShift较多，应用如：直销银行、保险公司的销售管理系统、互联网核心。如果站在IT角度，我们主要通过那哪些应用适合上容器，哪些不适合上容器来判断。可以参照下面标准：1.已建立了清晰的可自动化的编译及构建流程应用使用了如Maven、Gradle、Make或Shell等工具实现了构建编译步骤的自动化。这将方便应用在容器平台上实现自动化的编译及构建。2.已实现应用配置参数外部化应用已将配置参数外部化与配置文件或

24、环境变量中，以便于应用容器能适配不同的运行环境。3.已提供合理可靠的健康检查接口容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。4.已实现状态外部化，实现应用实例无状态化应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。5.不涉及底层的操作系统依赖及复杂的网络通信机制应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。6.部署交付件及运行平台的大小在2GB以内轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。7.启动时间在5分钟以内过长的启动时间将不能发挥容器敏捷的特性。【Q12】相比于K8S，OpenShift在帮助

25、客户构建PaaS平台的优势在哪？【A1】wykkx 某基金公司 系统架构师：这个问题主要涉及几个点：一是k8s属于开源产品，需要使用方完全负责生命周期的运维工作，对使用者的要求较高；openshift属于商用产品，有厂商负责生命周期的运维工作。二是k8s由于其开源架构，社区活跃度较高，可以获取到更多的外部信息；三是k8s在paas层原生提供的功能比openshift原生提供的功能丰富一些。如果是自研能力较强，建议使用k8s，如果是团队自身能力不足建议使用openshift来进行系统建设。【A2】 rechen 某大型银行 云计算架构师：相比于社区K8S，OpenShift产品的优势在于稳定性，

26、安全加固，以及技术支持。【A3】魏新宇红帽 资深解决方案架构师：优势其他专家已经说得很清楚了。这里我补充一下OpenShift对K8S的扩展，以方便理解。详见：【Q13】应用容器化改造上openshift时，有那些规范和注意事项？【A1】魏新宇红帽 资深解决方案架构师：详见【Q11】。其他的注意事项，内容很多，建议可以关注我那本OpenShift在企业中的实践书籍，里面通过2-3章进行了阐述。就日志而言，目前还是输出 json比较多，可以借助于jq工具对json文件进行格式化。就scc而言，通常不会使用anyuid，如果个别应用需要高权限，则单独给他的Service Account赋权就可以，

27、例如oc adm policy add-scc-to-user anyuid -z apacheuser这样虽然稍微麻烦一点，但对金融客户而言，安全性和稳定性是第一位的。【A2】 rechen 某大型银行 云计算架构师：在企业进行应用容器化改造工作，建议有统一开发框架的支持。开发框架可以提供统一公共组件以落地标准化技术规范，譬如统一日志格式，错误码格式等。【Q14】OpenShift在帮助企业构建敏态IT、进行数字化转型的步骤是什么？【A1】魏新宇红帽 资深解决方案架构师：我以OpenShift举例进行说明：图中的纵坐标为业务敏捷性，企业业务敏捷性方面的转型通常包含以下几步：第一步：构建 Pa

28、aS 平台。PaaS 平台为开发人员提供了构建应用程序的环境，旨在加快应用开发的速度，实现平台即服务，使业务敏捷且具有弹性。近几年容器技术的崛起更是促进了 PaaS 的发展，红帽 OpenShift 就是首屈一指企业级容器 PaaS 平台。第二步：基于 PaaS 实现 DevOps 。PaaS 平台是通过提高基础设施的敏捷而加快业务的敏捷，而 DevOps 则是在流程交付上加快业务的敏捷。通过 DevOps 可以实现应用的持续集成、持续交付，加速价值流交付，实现业务的快速迭代。第三步：借助于轻量级应用服务器，为现有单体应用提速。在开启云原生应用之旅时，企业不能只关注开发新的应用。很多传统应用都

29、是确保企业顺利运营和不断创收的关键所在，不能简单地取而代之。企业需将这类应用与新的云原生应用整合到一起。但是，问题是我们如何加快现有单体式应用的运行速度。正确的方法是：将现有的单体式架构迁移到模块化程度更高且基于服务的架构中，并采用基于 API 的通信方式，从而实施快速单体式方案。在开始实施将单体式应用重构为微服务的艰巨任务前，企业应该先为他们的单体式架构奠定坚实的基础。虽然单体式应用的敏捷性欠佳，但其受到诟病的主要原因是自身的构建方式。运行快速的单体式应用可以实现微服务所能带来的诸多敏捷性优势，而且不会增加相关的复杂性和成本。通过对快速单体式方案进行评估，可以确保应用在构建时遵循严苛的设计原

30、则，以及正确定义了域边界。这样，企业就能在需要时以更加循序渐进、风险更低的方式过渡至微服务架构。如能以这种方式实现快速单体式应用的转型，即可为优良的微服务架构打下扎实的基础。借助于 Red Hat OpenShift 和轻量级的应用服务器 Red Hat JBoss EAP 、 JBoss Web Server ，我们可以将传统单体应用迁移到容器中，为现有单体应用提速。此外，随着 OpenShift 承载的单体应用越来越多，就会涉及通过数据网格为单体应用提速。此外，随着越来越多的业务迁移到 OpenShift ，这必然会牵扯到不同业务系统之间的协议转换，即分布式集成。第四步：选择云原生的应用开

31、发和运行框架。随着物联网（ IoT ）、机器学习、人工智能（ AI ）、数据挖掘、图像识别、自动驾驶汽车等新兴技术的兴起，应运而生的应用开发框架也越来越多，我们需要根据特定的业务应用需求来选择语言或框架，因此不同的云原生应用会采用不同的应用开发框架。这就要求容器 PaaS 平台能够支持多种应用开发框架。红帽 OpenShift 不仅支持传统 JavaEE 应用、 SpringBoot 应用，红帽也发布了基于 Java 的云原生开发框架：Quarkus 。此外，随着 IoT 、 AI 的普及，实时数据流平台显得越来越重要。在 IoT 平台上，如何能够实现对数据库的变化数据捕获也是我们需要考虑的。此外，如何在 OpenShift 上更进一步地运行 Serverless 也是需要我们关注的。通过 IT 自动化管理、避免手动执行 IT 任务，是加速交付云原生应用的重点。IT 自动化管理工具会创建可重复的流程、规则和框架，以替代或减少会延迟上市的劳动密集型人工介入。这些工具可以进一步延伸到具体的技术（如容器）、方法（如 DevOps ），再到更广泛的领域（如云计算、安全性、测试、监控和警报）。因此，自动化是 IT 优化和数字化转型的关键，可以缩短实现价值所需的总时长。第五步：实现微服务治