基于容器化PaaS平台的DevOps建设规划.docx
《基于容器化PaaS平台的DevOps建设规划.docx》由会员分享，可在线阅读，更多相关《基于容器化PaaS平台的DevOps建设规划.docx（28页珍藏版）》请在冰豆网上搜索。
基于容器化PaaS平台的DevOps建设规划
基于容器化PaaS平台的DevOps建设规划
DevOps要实现从项目管理、开发、测试、部署、运维、监控反馈整个应用生命周期的管理和治理，涉及的流程和工具链还是很多的。
证券企业无论在人力还是技术积累等方面往往都是相对薄弱的，所以基于容器化PaaS平台的轻量化DevOps平台可能在一段时间内是相对适合的，能以低成本学习投入更快的提升研发和运维的效率。
为此，twt社区也邀请到了行业和领域技术专家以及红帽资深解决方案架构师分享了他们的容器云项目实践经验，并解答了社区会员提出的很多典型问题，由社区专家Steven99进行了全面的梳理和总结，希望对大家有所帮助和借鉴。
一、容器化PaaS平台和DevOps的关系讨论
【Q1】如何理解容器云平台和DevOps之间的关系?
基于容器化PaaS平台的DevOps有什么优势？
【A1】Steven99某证券公司软件架构设计师：
容器云平台可以是DevOps的一部分,也就是提供运行时环境,部署运维日志监控反馈等
基于容器云平台的DevOps是轻量的,或者用于PoC测试目的的,在于快速构建环境和完成部署.节省成本,维护工作量也相对较小.适合中小公司或者对研发等并不是要求特别高的公司.
建议根据自己的实际情况选择合适的方式,devops建设并不容易,也不仅仅是开发运维这么简单,流程、标准、度量、奖惩、组织、后勤保障等都密切相关
【A2】rechen某大型银行云计算架构师：
1、容器云平台，需要DevOps以标准化和提升IT研发和交付能力。
DevOps可以部署在容器云平台上。
2、基于容器化PaaS平台的DevOps，可以使用容器云的资源，譬如DevOps平台的相关技术组件，可以以容器方式部署在容器云上，以支持多pipeline流水线并发编译所需要的弹性资源。
【A3】魏新宇红帽资深解决方案架构师：
广义上的DevOps建设会包含：
人、流程、工具等多方面内容。
IT厂商提供的微服务和DevOps主要指的是工具层面的落地和流程咨询。
在Kubernetes和容器普及之前，我们通过虚拟机也可以实现DevOps，只是速度相对较慢，因此普及性不高（想象一下通过x86虚拟化来实现中间件集群弹性伸缩的效率）。
而正是容器的出现，为DevOps工具层面的落地提供非常好的承载平台，使得这两年容器云平台风生水起。
这就好比4G（2014年出现）和微信（2011年出现）之间的关系：
在手机网速3G的时代，流量按照兆收费，（即使有）大家对于微信语音聊天、微信视频也不会太感兴趣。
到了4G时代，网速提高而且收费大幅下降，像微信这样的社交和互联网支付工具才能兴起和流行。
OpenShift以容器技术和Kubernetes为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（S2I/Jenkins）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，实现DevOps落地效率比较高。
【Q2】想要落地devops的话，只考虑好的paas容器平台就够了么？
【A1】wykkx某基金公司系统架构师：
还差的非常远。
。
。
devops是以业务需求驱动为主体，需要打通业务，项目管理，开发，测试，运维一整套流程的。
这里涉及的不仅仅是技术问题，更多的是文化，管理，技术的一个整体的规划。
所以要想落地devops，简单来说，首先需要形成一个整体的规划，其次需要引入工具平台支持，这个工具平台是否为paas容器平台，没有任何关系。
最后，在工具落地后，采用mvp原则，让大家看到收益，然后进一步推广。
【A2】Steven99某证券公司软件架构设计师：
确切地说远远不够
DevOps涉及的东西很多，开发运维项目管理全过程都密切相关。
DevOps的目的是提升效率，所以不在于用什么平台，而在于根据企业实际情况选择合适的组件和流程、工具、方法、组织架构、奖惩措施等，尽可能以自动化的方式高效交付，同时激励相关人员的主动性，提高规范化和标准化要求，这是一个螺旋提升的过程，一个不断完善的过程
【A3】gxcornflakes某金融单位信息技术经理：
DevOps是一种理念，是轻量级的ITIL，技术部一般基于ITIL提供服务目录完成服务请求，中间有复杂的审批、手动操作，DevOps将服务流程规范化、标准化并通过自动化技术实现pipline，提升工作效率。
要想落地DevOps，关键是思维和理念的提升，再次是团队的变革，还有平台和工具的支持。
PaaS仅仅是一个支持平台，解决一部分问题。
【A4】魏新宇 红帽资深解决方案架构师：
容器云只是DevOps的底座。
这个底座上面还需要很多内容，我们仅以工具层举例：
项目管理：
禅道、Jira、Trello等。
知识管理：
MediaWiki、Confluence等。
源代码版本控制（SCM）：
GitHub、Gitlab、BitBucket、SubVersion、Gogs等。
代码复审：
Gitlab、Gerrit、Fisheye等。
构建工具：
Ant、Maven、Gradle等。
持续集成（CI）：
Jenkins、Bamboo、CircleCI、TravisCI等。
单元测试：
Junit、Mocha、PyUnit等。
静态代码分析：
Findbugs、Sonarqube、CppTest等。
测试用例管理：
Testlink、QC等。
API测试：
Jmeter、Postman等。
功能测试：
Selenium、KatalonStudio、Watir、Cucumber等。
性能测试：
Jmeter、Gradle、Loadrunner等。
配置管理：
Ansible、Chef、Puppet、SaltStack等。
监控告警：
Zabbix、Prometheus、Grafana、Sensu等。
二进制库：
Artifactory、Nexus等。
镜像仓库：
DockerDistribution、Harbor、Quay、Nexus3、Artifactory等
我们再看一个图，其中的OpenShift是底座，上面有很多工具。
【Q3】PaaS平台和DevOps平台的融合和边界问题？
【A1】rechen某大型银行云计算架构师：
1、PaaS平台和DevOps平台融合为一还是分开建设，这和每家单位的组织机构有关系。
如果工程管理的平台和工具，已经有一个单独的职能部门在负责，则DevOps平台由此部门承接。
此时，PaaS平台宜分开建设。
2、分开建设的话，PaaS平台和DevOps的边界在容器镜像，一般情况有通过容器仓库进行交互。
【A2】魏新宇 红帽资深解决方案架构师：
如果按照客户的IT建设，是先有IaaS，再有容器云/PaaS。
关于PaaS和IaaS边际，以OpenShift4为例，虚拟机及以下，是IaaS层；虚拟机中的操作系统及以上，是PaaS层。
这主要是因为OpenShift的宿主机操作系统已经被OpenShift统一纳管了。
关于IaaS和PaaS统一还是分开建设，这取决于具体的情况。
1.对于大的银行，客户的IaaS未必只承载容器云，可能还承载大量的虚拟机上的应用，因此统一建设有一定难度。
况且IaaS通常有专门的部门的负责。
2.对于中小金融的某个单的的项目，比如容器云项目，在符合公司的规划下，可以考虑IaaS和PaaS统一建设。
现在OpenShift4可以通过MachineAPI对IaaS（如vSphere，红帽OpenStack，AWS，Azure）进行纳管。
【Q4】如何规划容器化PaaS和DevOps？
【A1】魏新宇 红帽资深解决方案架构师：
可以把容器云平台理解成航母，把容器云上的容器化应用理解为航母舰载机。
PaaS、DevOps、微服务这三个概念，不是纯IT技术技术术语。
在容器云普及之前，这三个概念就已经有了。
无非是如何技术落地的问题。
没有容器云，通过虚拟机也能实现PaaS、DevOps、微服务。
只是相对效率低一些，所以之前这些技术也没被大规模使用。
容器云为PaaS、DevOps、微服务提供了非常好的技术落地实现。
云原生是近两年兴起的概念。
这个概念大体就是纯IT领域的术语了。
2018年，CNCF组织对云原生进行了重新定义“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API”。
从CNCF对云原的定义来看，它和容器、服务网格、微服务等技术是密切相关的。
云原生的范畴更广，包含了轻量级的应用开发框架内容。
【A2】mtming333甜橙金融翼支付系统运维工程师：
容器：
船上的集装箱
容器云：
很多船上的集装箱
容器化PaaS：
很多船上的集装箱的指挥中心
混合云：
租赁船上的集装箱+自购船上的集装箱
DevOps：
造集装箱货物的人和管集装箱的人都在船上一起干活
微服务：
集装箱里的货物
云原生：
未经改装拿来就用的公共船、集装箱、指挥中心
【Q5】使用容器平台做devops对比使用虚拟机环境做devops有什么优缺点？
【A1】rechen某大型银行云计算架构师：
1、使用虚拟机环境做devops，优点是虚拟机环境能够完整支持windows，linux等环境。
使用容器平台做devops一般以linux容器环境为主。
2、如果单位已经建设有容器平台且有团队研发和运维，则建议优先选择使用容器平台做devops，实施成本可平摊，在容器平台上做DEVOPS已经有很成熟的技术方案，实施难度不大。
且能够获得较好的扩展性。
3、如果单位没有容器平台的基础设施支持，而且像VMWARE的虚拟机环境，则建议使用虚拟机环境做DEVOPS，是实施成本小，难度小。
其扩展性可以使用云管平台或者自动化脚本来实现。
【Q6】IaaS、PaaS、SaaS、DevOps等概念技术在业务领域的着重点？
【A1】rechen某大型银行云计算架构师：
1、从业务领域角度看，IaaS,PaaS,DevOps的建设，是IT部门能够提升研发效能和交付效率。
而SaaS则更贴近业务，业务部门可以承接运营，直接面向市场为客户提供服务。
【A2】wykkx某基金公司系统架构师：
iaas平台主要是提供计算/存储/安全/网络方面的能力，即基础设施即服务，主要的建设部门是数据中心或者是运维部门；paas平台主要提供中间件能力/数据服务能力/编码服务化能力，主导部门主要是运维部门和开发部门；saas是软件即服务，一般把IT作为成本中心的企业（例如银行/证券等），是很少提供saas服务的。
Devops主要是以业务驱动为核心，满足业务需求，打通业务/需求/开发/测试/运维一整套流程，devops的落地是一整套管理/文件/工具落地的集合体，目的是为了以最低成本和最快速度实现业务需求，实现业务价值。
二、在金融证券行业的场景讨论
【Q7】容器化PaaS平台在证券行业的应用前景和场景是什么？
【A1】wykkx某基金公司系统架构师：
首先对这个问题进行拆解，容器化和paas平台两者没有必然的联系。
容器化可以做iaas层的一种承载方式，也可以是paas层，saas层的承载方式。
paas平台可以基于容器或者虚拟机部署，提供诸如中间件服务、数据库服务、devops流水线、分布式链路跟踪等能力。
其次，paas平台的能力，在证券行业可能有80%的场景是为自研应用服务，（外购系统很多出于产品化的原因都是做了完整的自包含），所以在设计paas平台时，应该多收集开发团队的需求点。
最后谈下devops与容器，其实devops的落地与容器并没有太强的关联，只是说目前商用的容器平台利用镜像的特点和容器平台多租户的特点，较为便捷的落地了devops。
但是基于虚拟机的方式实现devops也并不难，所以两者在我看来没有促进与否的问题。
【A2】mtming333甜橙金融翼支付 系统运维工程师：
我倒觉得应该是容器化PaaS平台去促进DevOps落地，做好了容器paas，用户爱用了，才能继续devops的工作流程改造
【A3】魏新宇 红帽资深解决方案架构师：
我咨询过一些证券行业的IT专家，目前证券行业使用容器，主要是少量的中间件容器化。
在容器云的使用上，金融行业里保险公司走的快一些，有的保险公司基于容器云承载互联网核心、销售管理系统等业务。
因此对于证券行业而言，后续互联网接入、DevOps的流水线，可以迁移到容器云，提升效率。
【A4】gxcornflakes某金融单位信息技术经理：
1、容器化PaaS平台在证券行业的应用前景和场景是什么？
随着证券行业应用系统自主化建设，PaaS容器云将应用越来越广泛，主要场景有几个方面：
1、互联网应用系统；快速部署，弹性伸缩；2、微服务（中台应用）；3、大数据人工智能应用；
2、如何结合DevOps促进容器化PaaS平台的落地？
DevOps一种文化，即轻量级ITIL理念。
DevOps的思想是要求作业流水线化实现自动化，即要求流水线的每个step标准化、规范化，而PaaS容器平台落地就是对资源和应用的标准化，所以DevOps和PaaS是相互促进
【Q8】金融行业如果从全局数字化运营的角度规划整套DevOps平台？
【A1】Steven99某证券公司软件架构设计师：
这个内容就太多了，devops提供敏捷的研发运维流程、工具、方法、规范等。
但它也仅是数字化转型中的一小部分。
数字化转型重点在于利用金融科技实现业务的变革和创新，业务模式的变革和创新。
这需要公司全局的规划和布局，不同公司的情况不一样，路经和方法也可能不一样，适合自己的事最好的。
但有一条需要记住，提高效率！
无论是开发运维效率或者是业务响应效率，这是devops等需要首先的目的
【A2】rechen某大型银行云计算架构师：
组织架构上要有充分的保障，DEVOPS团队的人员除了负责平台建设，流程规范，还要负责运营和推广培训。
一种比较好的安排是由项目管理团队负责规划和实施DEVOPS平台
【Q9】证券行业一流券商容器化目前已经涉及到哪些应用场景？
【A1】魏新宇 红帽资深解决方案架构师：
据我了解是互联网渠道接入和部分中间件的容器化。
但我觉得后续场景会越来越多，尤其是DevOps和互联网接入层，比较适合证券行业对突发大访问量业务的需求。
【A2】Steven99某证券公司软件架构设计师：
弹性伸缩、环境一致性、灰度发布、服务治理、多集群容灾备份、中台支撑、平台融合等
【Q10】券商适合云上的容器还是需要自建容器平台？
【A1】魏新宇 红帽资深解决方案架构师：
对于大型银行来讲，一定是用在数据中心内建私有云，一方面出于数据安全，一方面是技术自主可控。
对于券商而言，可以考虑公有云和私有云混合的模式，比如互联网的接入，可以放到公有云上，但容器云核心的部分，最好自建，而且使用开源的方案，避免被锁死。
【A2】Steven99某证券公司软件架构设计师：
不同公司有不同的想法和做法，取决于你怎么看待数据价值，以及云厂商有多大程度的可信度，公有云的可靠性、可用性等能力
就我们而言，自建的容器云平台，是支撑众多业务系统的基础平台，也是devops中的重要运行时部分。
三、Openshift应用讨论
【Q11】Openshift作为一种容器技术有开源和商用，那么目前有哪些服务场景在使用？
【A1】rechen某大型银行云计算架构师：
生产环境建议采用openshift商用版本。
openshift能够承载java平台，.netcore平台的业务应用系统，包括OA办公，内部管理，在线交易系统。
【A2】ypl75金融业工程師：
我们公司目前运用在网络银行、行动银行及API管理系统。
【A3】魏新宇 红帽资深解决方案架构师：
OpenShift本身是一个开源的软件，它有还有对应的社区版本OKD。
这就和RHEL和CentOS的关系。
在金融行业，目前银行和保险行业使用OpenShift较多，应用如：
直销银行、保险公司的销售管理系统、互联网核心。
如果站在IT角度，我们主要通过那哪些应用适合上容器，哪些不适合上容器来判断。
可以参照下面标准：
1.已建立了清晰的可自动化的编译及构建流程
应用使用了如Maven、Gradle、Make或Shell等工具实现了构建编译步骤的自动化。
这将方便应用在容器平台上实现自动化的编译及构建。
2.已实现应用配置参数外部化
应用已将配置参数外部化与配置文件或环境变量中，以便于应用容器能适配不同的运行环境。
3.已提供合理可靠的健康检查接口
容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。
4.已实现状态外部化，实现应用实例无状态化
应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。
5.不涉及底层的操作系统依赖及复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。
6.部署交付件及运行平台的大小在2GB以内
轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。
7.启动时间在5分钟以内
过长的启动时间将不能发挥容器敏捷的特性。
【Q12】相比于K8S，OpenShift在帮助客户构建PaaS平台的优势在哪？
【A1】wykkx某基金公司系统架构师：
这个问题主要涉及几个点：
一是k8s属于开源产品，需要使用方完全负责生命周期的运维工作，对使用者的要求较高；openshift属于商用产品，有厂商负责生命周期的运维工作。
二是k8s由于其开源架构，社区活跃度较高，可以获取到更多的外部信息；三是k8s在paas层原生提供的功能比openshift原生提供的功能丰富一些。
如果是自研能力较强，建议使用k8s，如果是团队自身能力不足建议使用openshift来进行系统建设。
【A2】rechen某大型银行云计算架构师：
相比于社区K8S，OpenShift产品的优势在于稳定性，安全加固，以及技术支持。
【A3】魏新宇 红帽资深解决方案架构师：
优势其他专家已经说得很清楚了。
这里我补充一下OpenShift对K8S的扩展，以方便理解。
详见：
【Q13】应用容器化改造上openshift时，有那些规范和注意事项？
【A1】魏新宇 红帽资深解决方案架构师：
详见【Q11】。
其他的注意事项，内容很多，建议可以关注我那本《OpenShift在企业中的实践》书籍，里面通过2-3章进行了阐述。
就日志而言，目前还是输出json比较多，可以借助于jq工具对json文件进行格式化。
就scc而言，通常不会使用anyuid，如果个别应用需要高权限，则单独给他的ServiceAccount赋权就可以，例如
ocadmpolicyadd-scc-to-useranyuid-zapacheuser
这样虽然稍微麻烦一点，但对金融客户而言，安全性和稳定性是第一位的。
【A2】rechen某大型银行云计算架构师：
在企业进行应用容器化改造工作，建议有统一开发框架的支持。
开发框架可以提供统一公共组件以落地标准化技术规范，譬如统一日志格式，错误码格式等。
【Q14】OpenShift在帮助企业构建敏态IT、进行数字化转型的步骤是什么？
【A1】魏新宇 红帽资深解决方案架构师：
我以OpenShift举例进行说明：
图中的纵坐标为业务敏捷性，企业业务敏捷性方面的转型通常包含以下几步：
第一步：
构建PaaS平台。
PaaS平台为开发人员提供了构建应用程序的环境，旨在加快应用开发的速度，实现平台即服务，使业务敏捷且具有弹性。
近几年容器技术的崛起更是促进了PaaS的发展，红帽OpenShift就是首屈一指企业级容器PaaS平台。
第二步：
基于PaaS实现DevOps。
PaaS平台是通过提高基础设施的敏捷而加快业务的敏捷，而DevOps则是在流程交付上加快业务的敏捷。
通过DevOps可以实现应用的持续集成、持续交付，加速价值流交付，实现业务的快速迭代。
第三步：
借助于轻量级应用服务器，为现有单体应用提速。
在开启云原生应用之旅时，企业不能只关注开发新的应用。
很多传统应用都是确保企业顺利运营和不断创收的关键所在，不能简单地取而代之。
企业需将这类应用与新的云原生应用整合到一起。
但是，问题是我们如何加快现有单体式应用的运行速度。
正确的方法是：
将现有的单体式架构迁移到模块化程度更高且基于服务的架构中，并采用基于API的通信方式，从而实施快速单体式方案。
在开始实施将单体式应用重构为微服务的艰巨任务前，企业应该先为他们的单体式架构奠定坚实的基础。
虽然单体式应用的敏捷性欠佳，但其受到诟病的主要原因是自身的构建方式。
运行快速的单体式应用可以实现微服务所能带来的诸多敏捷性优势，而且不会增加相关的复杂性和成本。
通过对快速单体式方案进行评估，可以确保应用在构建时遵循严苛的设计原则，以及正确定义了域边界。
这样，企业就能在需要时以更加循序渐进、风险更低的方式过渡至微服务架构。
如能以这种方式实现快速单体式应用的转型，即可为优良的微服务架构打下扎实的基础。
借助于RedHatOpenShift和轻量级的应用服务器RedHatJBossEAP、JBossWebServer，我们可以将传统单体应用迁移到容器中，为现有单体应用提速。
此外，随着OpenShift承载的单体应用越来越多，就会涉及通过数据网格为单体应用提速。
此外，随着越来越多的业务迁移到OpenShift，这必然会牵扯到不同业务系统之间的协议转换，即分布式集成。
第四步：
选择云原生的应用开发和运行框架。
随着物联网（IoT）、机器学习、人工智能（AI）、数据挖掘、图像识别、自动驾驶汽车等新兴技术的兴起，应运而生的应用开发框架也越来越多，我们需要根据特定的业务应用需求来选择语言或框架，因此不同的云原生应用会采用不同的应用开发框架。
这就要求容器PaaS平台能够支持多种应用开发框架。
红帽OpenShift不仅支持传统JavaEE应用、SpringBoot应用，红帽也发布了基于Java的云原生开发框架：
Quarkus。
此外，随着IoT、AI的普及，实时数据流平台显得越来越重要。
在IoT平台上，如何能够实现对数据库的变化数据捕获也是我们需要考虑的。
此外，如何在OpenShift上更进一步地运行Serverless也是需要我们关注的。
通过IT自动化管理、避免手动执行IT任务，是加速交付云原生应用的重点。
IT自动化管理工具会创建可重复的流程、规则和框架，以替代或减少会延迟上市的劳动密集型人工介入。
这些工具可以进一步延伸到具体的技术（如容器）、方法（如DevOps），再到更广泛的领域（如云计算、安全性、测试、监控和警报）。
因此，自动化是IT优化和数字化转型的关键，可以缩短实现价值所需的总时长。
第五步：
实现微服务治
升级会员 