大中型企业传统生产应用容器化迁移方法路径和基础架构技术难点交流探讨

大中型企业的业务系统，对性能和可靠性都有着严苛的要求，过去只能依赖于主机系统本身的高可靠性和高性能来支持。随着云计算技术特别是容器技术的成熟，使得大中型企业的基础设施发生了根本的变化。以容器为核心的云计算技术，实现了以通用的服务器作为底层基础实施的高可用，低成本和性能弹性扩展问题，同时结合微服务和DevOps，满足应用快速交付的需求。目前很多的企业意识到容器平台的优势，都开始容器平台的建设。但是，目前企业内部大量的应用仍然是旧的主机体系架构，基于原来传统的中间件和技术框架开发。这些应用想要获得云原生应用的优势，需要进行迁移。由于容器平台的应用和传统应用的设计和开发规范存在差异，所以整个迁移过程是一个复杂和容易出错的过程。
以下交流内容就是本次交流活动探讨问题汇总，希望给同行朋友带来帮助和借鉴。更多精彩分享内容可以点击阅读： https://www.talkwithtrend.com/Activity/?id=1607

1、虚拟化上的应用迁移到容器云有哪些难点，有什么解决的方法？

要把应用迁移到容器云上，心里发虚。虚拟化上的应用迁移到容器云有哪些难点，有什么解决的方法？

回复：顾黄亮 技术总监 , 苏宁消费金融有限公司
这个问题其实非常体系，涉及的点非常多，我从框架层面简单的总结一下。
第一，是所有平台化产品都会面临的问题。平台化要定标准。目前来说，容器的标准相对统一，但是容器管理平台的标准好几家在做，k8s只是其中一个，谁能占上风，目前也没有一个绝对的，新的产品和技术可能也会冒出来。标准不统一，导致大家在使用过程当中，技术选型的时候会有挑战。
第二，容器的技术涉及到资源，涉及到应用内部结构，所以它具有一定的侵入性。不像是虚拟机，交付完成后，在虚所机内部怎么搞平台就不管了。容器要关心这个问题，否则就没有办法做模式化了，不做模式化的话，平台的很多东西都没有办法构建了。
第三，大量传统应用需要改造。运营商市场有几百，上千个应用。这些应用估计都是几百上千亿的投资，不可能这批应用都不用了，全部改成容器。而且容器也不是银弹可以解决所有的问题。传统应用的改造适合什么样的技术，怎么改变，这就是我们非常大的挑战。这些挑战在我们产品技术选型时，能多多少少都会涉及一些。

回复：nameless 技术总监
涉及内容较多，我简单说明几点：
1、应用中间件选型，看要迁移应用中间件是否支持容器化；
2、应用无状态还是有状态；
3、数据库连接池设置；
4、服务间接口调用使用TCP还是HTTP协议；
5、应用配置；
6、应用日志；
7、应用数据缓存；
8、应用是否使用固定的服务监听端口；

2、容器云平台适用哪些业务场景？传统应用有必要改造吗？

1.传统制造业，传统应用有必要进行容器改造吗？有哪些注意事项呢？
2.容器真正适用的业务场景有哪些呢？除了数据库类的，有哪些还是不适用呢？

回复：yeefone 云计算架构资深专家 , 某大型保险公司
传统制造业很有必须进行容器化改造，产业互联网坐上云计算的快车，容器化是最好的助力之一。注意事项方面要拜托传统系统集成的思路，采用云解决方案的思路去推进，注意相应人才的引进，自动化和弱电集成以及信息化梳理清楚。
应该说自动化+IOT是很好的应用场景。

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
容器云适应的业务场景很多，它带来了开发和运维体系的变革，这种模式能够更及时地响应快速变化的业务需求，提高效率。具体到场景，互联网应用、AI/ML，车联网，IoT，好多场景都可以用得到。
1）传统制造业，业务诉求不一定传统，比如要做大规模的仿真测试，要做车联网，或者要提高效率、降低成本，都可能采用容器技术。
2）但传统应用有必要么？坦白讲，很多时候也是没必要的：如果你的业务需求没有变化，人员、预算、成本、硬件资源都没有变化，没有必要改造传统应用。不是为了上容器而上容器。
3）其实数据库的场景也不是完全不适合。现状是：很多传统应用，是基于传统的商用数据库、中间件开发的，业务逻辑都在里面了。如果这个商用数据库不支持上容器，那么迁移到容器环境就是徒劳的。我们好考虑到之前的业务是不是可以完好无损的跑在新环境里，是不是曾经做过那些业务变更，这些都是迁移中要考虑的，自然给迁移带来困难和风险，最终得到的结论便是某些业务不适合迁移。
4）单机大型应用，不是分布式，无需横向扩展，对性能要求极高，也许可以容器化，但跑在k8s上也意义不大。

3、容器云环境中，存储选型是怎样的，在k8s上跑数据库，对于存储的性能要求较高，市场上有合适的分布式存储吗？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
选型的要点首先是基于业务场景，需要什么样的存储：块、文件、对象以及考虑工作负载的特点（大IO，小IO，顺序，随机）选择合适的存储；其次，要考虑该存储与容器平台的结合程度，是不是可以和容器平台很好的联动。k8s上跑数据库，比如portworx, 可以试试。

回复：yeefone 云计算架构资深专家 , 某大型保险公司
现在市面上成熟的分布式存储有很多， 适应不同的存储场景，选哪种要考虑数据库的要求。随着k8s对local Storage的支持逐渐成熟，现在很多数据库(比如TiDB)直接使用lv，性能上没有损耗，然后在db层做高可用。

回复：顾黄亮 技术总监 , 苏宁消费金融有限公司
据我所知，很多公司已经把非核心业务的数据库容器化，同时也把大数据平台的组件容器化了，因此，从技术层面看，不成问题，但是要考虑一点，存储选型很重要，节点可以转移，数据是唯一的，不管存储具备多少个副本，数据的唯一性一定要保证，而且性能要高。
举一个实际的例子，通过nfs做持久化数据存储,熟悉docker的朋友都知道docker适合无状态的服务,而其实MySQL是需要持久化数据的,所以这里使用了nfs，自己搭建也是可以的,或者是用hostpath也是可以的,为什么推荐这俩,因为简单,新手很容易上手,而越是简单的东西越是好维护。数据库实例是会自己根据mysql的逻辑备份文件.sql后缀的备份文件自己恢复进实例里面的,yaml里面有注释,hubdocke上也有说明是把这个文件挂载到/docker-entrypoint-initdb.d 容器的这个目录下面即可。

4、为了能够顺利地将传统生产应用容器化，在容器化前，应用系统责任人应该提前储备哪些知识？

为了能够顺利地将传统生产应用容器化，在容器化前，应用系统责任人应该提前储备哪些知识？以便在迁移前做好准备工作及迁移过程中打好配合。

回复：mtming333 系统运维工程师 , 甜橙金融翼支付
为了能够顺利地将传统生产应用容器化，太保容器平台的设计理念是：让应用负责人不用储备知识。
总结一下几点：
1、平台功能防呆，高级功能默认折叠
2、撰写部署需求模板，要求应用负责人填写
3、组织专门小团队（3-5人），从开发第一环节介入部署
4、实现应用整体导出，实现傻瓜导入式部署

回复：顾黄亮 技术总监 , 苏宁消费金融有限公司
在现有的回复基础上做一些补充
1、一定要注意组织协作能力，容器化后，支撑层前置，已经不仅仅是基础架构的事情了，研发、测试、运维的知识体系必须要包括容器云平台的知识。
2、怎么管理容器云，手动肯定不行的。 因为容器生命周期的高度短暂性，手动管理容器是不现实的;因此，部署容器应用，往往都是通过CLI(命令行)或API(应用程序编程接口)进行的，以实现应用的自动化部署和管理。
3、要有目标价值，必须通过容器化来达到既有的目标，比如，解决现有业务的主要痛点，创造可量化的成本节约机会。
4、 应用程序的改造，要适配容器化，从简单的开始再到复杂的，监控和保障同时要跟上。

5、传统生产应用容器化后，应用系统责任人在日常维护中需要关注的维护点有哪些？

回复：mtming333 系统运维工程师 , 甜橙金融翼支付
关注自愈记录，协同开发增强鲁棒性，建议以周为单位统计。
1、自愈成功次数
2、自愈失败，应用陷入不可用状态的次数
3、掌握全链路监控排摸手段

回复：顾黄亮 技术总监 , 苏宁消费金融有限公司
除了日常需要关注的意外，个人建议还需要关注以下内容。
1、数据是否会因为上云后导致新的风险而发生数据泄露，建议匹配相对于的安全措施。
2、业务连续性依赖容器云平台，尤其组件级和容器级，需要有新的学习成本
3、企业内部和云上的应用的数据交互方式存在了变化，要提前介入适配
4、上云业务是否会因监管条例出现问题，这个格外要关注
以上4点作为补充。

6、openshift如何实现两地三中心的双活和容灾？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
应用上OpenShift现在已经可以支持多集群管理，我们通过一个叫ACM的产品来实现。数据上，OpenShift本身是不碰数据的，OpenShift可以对接不同的存储产品，备份/容灾产品，上面也可以跑不同的数据库。所以要看双活、容灾要从哪个层面上实现，然后OpenShift需要与不同的产品和解决方案整合。

7、 在开源k8s平台上的应用迁移到openshift平台是否可以提供较快捷的迁移方案？

对于采用docker的已经容器化的应用和一些部署在开源k8s平台上的应用迁移到openshift平台是否可以提供较快捷的迁移方案，在迁移过程中开发和运维主要的重点和难点在哪里？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
红帽服务支持团队往往会根据客户的现状提供适合的、快捷的迁移方案。总的来说：
1）OpenShift是基于k8s的，与k8s是兼容的，已经容器化的应用是可以很好地运行在上面的；
2）OpenShift是k8s的超集，在k8s的基础上增加了s2i, CI/CD等，有预集成的监控、日志等方案，那么你原来跑在k8s上的应用，可能有自己集成的CI/CD，监控，日志等，那么，到了OpenShift平台上，这些不用自己做了，当然，这个迁移过程要涉及到一些改动。
3）原来在开源的k8s上，为实现某些业务需求，如果自己在不同层面改了开源代码，而这些代码是没有回馈到社区的，而这些，要考虑一下在OpenShift上如何实现。如前所述，OpenShift相当于超集，有些改动对应的功能在OpenShift上可能已经实现了，因此，要对相关的业务需求再好好地梳理一下。
4）OpenShift涉及到一些新的命令与功能，初次使用者还是要熟悉一下。OpenShift跟k8s社区跟的也比较紧，有些新功能新实现，比如operator，如果在之前的环境中没接触过，也是要熟悉一下。

回复：yeefone 云计算架构资深专家 , 某大型保险公司
开发上：具体看你原有k8s的使用方式了，如果应用交付采取了helm，那基本上不用做什么改动，可以直接部署到openshift上。
运维端的化：Openshift4已经和k8s有了一定区别，比如coreos和cri-o等技术堆栈都不同，coreos作为不可变基础设施对原有的操作系统运维是个挑战，运维团队需要做出一定改变，这一方面我们也在做尝试，还没有很多经验贡献出来。

8、OpenShift迁移解决方案能解决哪些问题？相比VMware pks的迁移方案如何？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
红帽的迁移方案可以解决的问题包括：从VMware虚拟化到红帽虚拟化、应用的现代化、传统应用容器化等。迁移是在方法论的指导下从规划到实施的一个服务交付过程。

9、应用带数据库要从虚拟机迁移入openshift保证数据不丢失？

**
回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心**
OpenShift里面也可以有持久化的数据存储，PV，容器重启，数据还在。但迁移过程中，数据丢不丢失，就要看之前是不是做好分析、规划、以及很好的备份方案了，还有就是这个应用本身适不适合迁移。迁移本质上是个实施问题。

10、openshift中可以部署oracle database、db2、weblogic、websphere、MQ等软件吗？

在很多金融行业中会用到oracle database、db2、weblogic、websphere、MQ，请问这些软件是建议在openshift上运行，如果不建议是否有可替代的方案？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
技术上只要可以被容器化都可以在OpenShift上运行，问题是有些软件并没有做运行在容器环境上的认证，而它又是个闭源的商用软件，企业来用只能在它认可的平台上运行才有保障。OpenShift上是有很多开源替代方案的，比如上面提到的 weblogic/websphere -> JBOSS EAP。当然，任何迁移，都要充分分析好现有系统及应用的特点，做好规划，找有经验的实施团队。

11、老旧系统如何迁移上云，尤其是那种重新部署难度较大的，有没有专用的迁移工具？

老旧系统如何迁移上云，尤其是那种重新部署难度较大的，有没有专用的迁移工具？

回复：mtming333 系统运维工程师 , 甜橙金融翼支付
没用迁移工具。改造了几百套系统，无关乎老旧，但有几条经验：
1、tomcat、weblogic、nginx、apache的老旧系统可以直接上，获益明显
2、关注容器云的网络规范，主要是IP规则与port规则
3、投产前需压力测试

回复：nameless 技术总监
先说结论，挺难的，建议先看业务使用的中间件以及中间件版本做评估：
1、一般Java类业务(tomcat、jboss、weblogic、jar等)都可以上，注意业务对操作系统版本要求，一般建议centos/redhat7以上(虽然centos/redhat6.8也支持)；
2、 weblogic可以上容器，但对版本有要求，一般建议weblogic10以上；
3、was不建议上容器，太重；
4、Nginx、 apache 类业务一般都可以上容器；
5、对内核版本有要求的业务慎重选择上容器；

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
我们所说的迁移，是综合评估利弊得失，结合企业数字化转型发展阶段，迁移上云。不是为了迁移而迁移，不是一刀切地将老旧系统迁移上云。红帽针对一些典型的企业级应用，有指导迁移的方法论以及实施步骤，也有一些案例。

12、openshift和开源的k8s的区别，优势在哪？

回复：张家驹 软件架构设计师 , 红帽企业级开源解决方案中心
最主要的区别，k8s更多的是面向运维的，OpenShift提供了从开放到运维一体化的解决方案，原生集成了s2i, CI/CD等。另外，从OpenShift 4开始，OpenShift和底层操作系统结合更紧密，如master节点引入RHEL CoreOS, 以及从操作系统到应用的全栈式的安全加固等，总体上可以理解为在原生k8s基础上集成了更多的企业级特性并经过红帽的工程化验证以及红帽可以提供企业级服务。

13、传统生产应用容器化迁移，如何做微服务改造？

回复：顾黄亮 技术总监 , 苏宁消费金融有限公司
这个问题其实非常体系，涉及的点非常多，我从框架层面简单的总结一下。
第一，是所有平台化产品都会面临的问题。平台化要定标准。目前来说，容器的标准相对统一，但是容器管理平台的标准好几家在做，k8s只是其中一个，谁能占上风，目前也没有一个绝对的，新的产品和技术可能也会冒出来。标准不统一，导致大家在使用过程当中，技术选型的时候会有挑战。
第二，容器的技术涉及到资源，涉及到应用内部结构，所以它具有一定的侵入性。不像是虚拟机，交付完成后，在虚所机内部怎么搞平台就不管了。容器要关心这个问题，否则就没有办法做模式化了，不做模式化的话，平台的很多东西都没有办法构建了。
第三，大量传统应用需要改造。运营商市场有几百，上千个应用。这些应用估计都是几百上千亿的投资，不可能这批应用都不用了，全部改成容器。而且容器也不是银弹可以解决所有的问题。传统应用的改造适合什么样的技术，怎么改变，这就是我们非常大的挑战。这些挑战在我们产品技术选型时，能多多少少都会涉及一些。