银行行业承载关键应用的容器云平台技术选型及DevOps生产运维实践的10个典型问题

随着云计算的成熟，银行的 IT 系统发生了很大的变革，很多银行都在经历主机下移和核心应用上云的过程。在银行的数字化转型过程中，应用的快速交付、灵活调度和水平扩展能力越显重要，而容器技术以及相关 DevOps 实践成为解决上云问题的两把钥匙。容器以及容器编排技术与传统的虚拟化技术相比较，可以提供极致性能、高效调度和快速部署的优点，目前已经成为基础设施的一个主流技术体系。容器技术是继虚拟化技术后， IT 基础设施和云计算的一次技术 “ 革命 ” 。

Google 目前的所有服务和应用都是跑在容器之上 , 知名互联网企业发布云原生裸金属 + 容器的基础设施方案。万物皆可容器化，成为目前云基础设施的一个发展趋势。 DevOps 的理念很早就提出，但是随着容器的普及而快速流行起来， DevOps 解决了传统运维体系中，开发团队和运维团队目标相左的矛盾，实现了应用快速、可靠的交付。

如何在银行的关键应用中，运用容器和 DevOps 的能力，发挥其灵活高效的优点的同时，保障银行关键应用的稳定和可靠，都是需要持续探讨的问题。

1 、银行关键应用上容器云平台，应该如何进行技术平台选型？需要考虑哪些方面？

2 、容器平台上的关键应用如何实现应用的高可用？

3 、银行关键应用采用容器平台，主要关注容器平台的哪些特性？是否会开启弹性伸缩？

4 、交易类应用在上容器云的过程中，是否需要进行拆分？如果拆分，如何保障事务一致性？

5 、容器云平台的监控体系应如何建设？

为解答以上疑问，本次活动社区特邀请了大型银行专家分享容器云实践经验、红帽专家分享行业解决方案，同时会集中在线解答大家的问题。

以下是本场交流活动的典型问题：

1.银行关键应用上容器云平台，应该如何进行技术平台选型？需要考虑哪些方面？

回复 1 ： Rechen 云计算架师，某大型银行

建议从技术、流程和人员这三个维度进行问题细化。

• 技术平台选型需要遵循 “ 产品成熟、质量稳定、技术主流、生态活跃 ” 的原则，做到科学和专家决策。

• 容器云的建设，要规划先行，配套跟上，同时要注重人员技能的成长、流程建设。
• 如果确定关键应用上容器云的项目目标，作为一个较复杂的系统性工程，项目取得成功的一个最基本的条件是要有高层领导支持，参预相目的各职能科室骨干有统一共识 。

回复 2 ：聂健 资深解决方案架构师，红帽企业级开源解决方案中心

技术选型除了关注的功能点外，更需要考虑的因素包括：

• 技术走向，是否和客户的 IT 战略一致。
• 产品是否具备的开源社区的影响力，是否能引领技术的发展方向 。
• 开源产品和容器平台的整合能力，能否有整合其他开源产品的生态环境 。 完整的产品路线图，是否有清晰的 Roadmap, 并且支持 5-10 年的生命周期 。
• 产品的稳定性 ， 容器平台的稳定不仅取决于 Kubernetes 编排平台，还和底层的容器引擎 (Docker) ， OS Kernel, 分布式存储，网络 ,JVM, 中间件平台有密切关系，在发布前有没有经过测试以及全堆栈的支持能力。

2.容器云能否替代虚拟机？如能替代，替代的实施过程？？

回复 1 ：顾黄亮 技术总监，苏宁消费金融有限公司

这个问题是个伪命题，不存在容器替代虚拟机，也不存在虚拟机会消亡，双方之间也不是对立的取代与被取代的关系，而更应该是互补合作的关系。

原因有如下，首先我们不说容器的各种优点，在此我们就不再说了，听了太多了，如果大家关注虚拟化技术的话，你会发现容器的优势虚拟机基本上都有。比如说，容器赖以成名的镜像、服务发现、弹性伸缩，虚拟化都有了，而且不比容器差。

谁取代谁，关键还是看场景。并非所有应用都适合用容器：比如传统的关系型数据库应用，则不是像容器场景中宣称的那样随时都可以随便重启的，而且，数据库的高可用也不是像 Kubernetes 那样挂一个服务发现就能解决的，而是应当使用数据库本身的高可用架构来实现以确保数据的可靠性和一致性！容器是有自己十分具体的应用场景的，至少目前来看，在超出上述领域之外的其他传统应用分发、部署、运维管理中，容器并没有特别的优势，反而具备一定的劣势。场景化需求才是两种技术选择的关键。

总结一下，混合云，多技术栈的云计算场景运用，和安全稳定高可靠的架构，才是最重要的。

回复 2 ：聂健 资深解决方案架构师，红帽企业级开源解决方案中心

Openshift 上有个项目 cnv, 对应着社区版本的 kubevirt, 就是通过 Kubernetes 去管理虚拟机的，也就是会把你的虚拟机包装成一个 pod, 在 Openshift 平台上进行管理，而用户使用的模式和虚机一样，固定 IP, 任何修改给你持久化，目前这个项目是处于技术预览阶段。

使用场景是对于一些很难改造的应用或者不愿意改造的应用，如果需要纳入 OpenShift 来统一管理，可以把你之前的虚拟机做成 qcow 模板，然后导入到 openshift 平台上成为一个 virtual machine 的 crd 来运行，但这种模式下就比较适合 openshift 运行在物理机的环境上了 , 因为如果底层还是虚拟化平台，那就面临嵌套虚拟化，可能导致性能问题。

3.容器云平台的监控体系应如何建设？？

回复 1 ： rechen 云计算架师，某大型银行

• 首要是做好容器云平台监控体系的架构设计，譬如架构设计规划出应用监控、 IAAS 基础设施监控、网络流量监控、分布式链路监控、投产验证监控等子领域的建设。
• 制定统一日志数据的开发规范，建设好应用日志、运维日志数据的采集、存储、大数据加工能力。
• 整合资源元数据、管理元数据进行可视化展示。
• 提供告警规则设置、告警信息推送能力 。

回复 2 ：聂健 资深解决方案架构师，红帽企业级开源解决方案中心

涉及到需要监控的范围是包含了平台的数据，还是业务监控的数据。
另外需要考虑多集群下的统一监控环境的搭建
第三点是除了环境建设问题外，获取的数据指标体系需要慢慢的积累，可以从一些简单的开始，然后总结经验，逐步丰富，形成自己的指标体系。

4.容器平台上的关键应用如何实现应用的高可用？

回复 1 ： rechen 云计算架师，某大型银行

• 关键应用的架构需要进行良好的设计，识别出哪些模块部署在容器云，哪些部署在传统 IT 基础设施，譬如虚拟机或者物理机，数据存贮设备。对相应的领域都需要进行高可用设计。
• 在容器云领域，需要提供多集群的支持，集群搭建在不同的 AZ 可用区，分布在不同的机房，不同的网络分区上。规范关键应用的部署架构，必须同时部署了 3 个 AZ 可用区的相应集群中，且业务流量均衡在 3 个 AZ 中。
• 容器云平台的各个组件进行高可用设计，确保平台的高用可。
• 容器云平台提供统一的监控、日志和告警功能，为部署在上面的关键应用，提供快速问题定位的能力。
• 对容器平台上的关键应用，设计容灾演练方案并且进行定期演练，解决出现的问题，完善应急响应方案。

5.如何推广容器云平台？

回复 1 ： rechen 云计算架师，某大型银行

可以考虑在 DEVOPS 平台，定制出相应的 PIPELINE 流水线，屏蔽掉开发人员写 Dockerfile 的负担，兼容开发人员的编译习惯，譬如 JAVA 开发人同，只需要保证和之前一样，正常编译出 JAR/WAR ， DEVOPS 平台按标准化规范（注：包括 BASEIMAGE ， JDK 、中间件等的标准化）就能够自动生成容器镜像。

做好推广工作，譬如举办培训和考试认证。

回复 2 ：聂健 资深解决方案架构师，红帽企业级开源解决方案中心

挺好的问题，我觉得几个方面：

• 需要做一些普及性的宣传和广告，告诉他们新的平台的好处，比如你不用再申请虚拟机，物理机了，然后你的应用写个 Dockerfile 就可以一键上云了什么的。
• 需要设立项目对接组，在推广的初期是需要帮项目组去做传统环境到容器环境的切换的，大概可聂健 资深解决方案架构师，红帽企业级开源解决方案中心以做一个示范以后，其他的组件他们自己完成。
• 让他们确实感受到 CICD 和容器云的便捷性，比如他们同样的 30 多个组件要部署在功能测试， stage 以及客户验收环境，原来模式部署可能需要 3 天的时间，而容器化部署后只需要半天，这优势就体现出来了。这样才能更好的接收容器化改造。

6. 容器云平台解决方案在企业内部落地时，应该由哪个部门（数据中心运行部门、软件中心研发部门）牵头建设？

回复 1 ： 聂健 资深解决方案架构师，红帽企业级开源解决方案中心

目前看到更多的是研发部门牵头，因为上容器云更多的需求是为了实现应用的快速迭代和支持业务敏捷创新，因此开发和发布效率这块是一个比较关键的指标，而且也是容易收到立竿见影的效果的。为保障容器云的生产运维，也需要去构建容器运维和监控告警体系。
确实存在当把容器云做大以后生产环境需要移交数据中心的问题，一般来会由属于研发中心 PaaS 团队的一些人员加入到数据中心进行交接和赋能，有一个联合运维的阶段，数据中心完全能接手后研发再着力于技术和平台的创新 。

7.Docker的隔离与安全？

回复 1 ： 顾黄亮 技术总监，苏宁消费金融有限公司

这个问题老生常谈了，很多人都说过， docker 很多场景都用到了 root 用户，而且 docker 一直所标榜的沙箱和隔离是否能够保证安全。 比如很多人就说，使用 root 用户运行 Docker 容器内部的应用，是否能够做到数据和权限的安全？容器内的 root 是否可以操纵宿主机资源？

1. 一般人理解 docker 的 root 权限和宿主机的 root 权限是一样的， docker 可以操作宿主机上的任何东西，这个观点是错误的，此 root 非彼 root 。
2. docker 的 root 和宿主机的 root 不是一回事，这两种 root 在权限方面有这很大的差异，这种权限隔离的差异来源于 linux 内核的 Capabilities 技术，这东西的解释如下 : 将之前与超级用户 root （ UID=0 ）关联的特权细分为不同的功能组， Capabilites 作为线程（ Linux 并不真正区分进程和线程 ）的属性存在，每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类，具有相似功能的内核调用被分到同一组中。
3. Capabilities 在 Docker 容器的管理过程中使用非常方便。如果不需要授予 Docker 容器足够的系统权限，也就是足够的 Capabilities ，只需在运行 Docker 容器时不使用 --privileged 参数，如： docker run -it --priviledged=false ubuntu:14.04 /bin/bash 或者 docker run -it ubuntu:14.04 /bin/bash 如果需要授予 Docker 容器足够的管理权限，则直接将 --privileged 参数设为 true ，如： docker run -it --privileged=true ubuntu:14.04 /bin/bash 另外，在 docker run 命令中，添加 --cap-add 以及 --cap-drop 参数也完全可以更灵活的添加以及移除 Linux Capabilities 。
4. 虽然 Docker 容器中的 root 用户与宿主机的 root 用户同属一个 uid ，均为 0 ；并且大家也可以发现不同的 Capabilities 可以区分 root 用户的权限，那么 Docker 容器中的 root 用户的 Capabilities 该怎么处理，默认情况下， docker run 命令的 privileged 参数值为 false 。因此，毫无疑问， Docker 容器内部的 root 用户将受到严格的权限限制，很多有系统相关的操作权限都将被剥夺，只具备超级用户的一些基本权限。
5. 综上所述， docker 的 root 不是我们想象的 linux 的 root 。

回复 2 ： 聂健 资深解决方案架构师 , 红帽企业级开源解决方案中心

如果只是在 docker 环境下，在 openshift 中缺省条件下是不允许以 root 用户运行的，怕造成权限的泄露 ,openshift 为了容器运行的安全，通过 scc 结合 os 层面的 selinux 去进行限制。

如果某些场景一定要再容器内布通过 root 权限，可以打开 SCC 限制，但建议通过 sysdig 进行一些 audit, 防止 root 用户在容器内部中进行一些非法操作。

Docker 因为 docker daemon 是需要基于 root 运行的，机制上很容易造成容器内进程发生权限逃逸，拿到宿主机的权限，另外 docker 机制不好的地方是所有的运行容器都是这个进程的子进程，如果有错误产生，就会有孤儿进程 . 正因为这个原因，在新的 openshift 4 版本中基于 podman 和 crio 的容器引擎，不需要后端运行 daemon 进程，通过 cri-o 或者是 podman 直接去构建 runc 的容器，构建和运行容器都不需要 root 权限，防止权限逃逸，具备了更多的安全性特征。

8.容器网络的流量监控有无好的解决方案？

回复 1 ： 聂健 资深解决方案架构师 , 红帽企业级开源解决方案中心

目前看到更多的是在应用层面去监控，比如对于微服务架构的应用，可以通过微服务架构中的能力去做请求调用的监控，比如 istio, 但系统层面的流量监控可以通过一些专业的工具比如 Dynatrace 进行分析 .

9.我们现在用的私有云，适合在云上再部署容器吗？

回复 1 ： 聂健 资深解决方案架构师 , 红帽企业级开源解决方案中心

其实 多客户是在自己的 vmware 或者 openstack 等平台上部署 openshift, 也有一些是通过物理机直接部署容器环境。从原理和技术上说是一致的，区别是通过物理机部署性能会更好一些。在私有云上部署的好处是集群扩展性更方便一点，毕竟虚拟机比较容易申请，而物理机资源申请相对难一些，当然也有虚拟机和物理机混合部署在一个集群的客户 。

10.生产环境中容器的网络应该怎么去运维？

回复 1 ： rechen 云计算架师 , 某大型银行

生产环境中容器云平台的网络架构的设计和网段规划很重要 . 容器云平台的网络架构的设计细节，包括多 AZ 可用区、 DMZ 网络分区、安全防火墙、 NAT 、 SLB 负载均衡器的部署、容器 OVERLAY 网络、虚拟化 SDN 网络等，都会影响对网络运维难度的主观判断。

故障排查方面，这是一个团队协调的活动，除了需要熟悉上述容器云网络设计的技术骨干外，还要熟悉出故障的业务应用系统的各模块调用关系的应用运维人员，以及基础设施方面的资产监控数据、网络 TAP 流量数据的分析支持。 有这些架构资产和监控数据， 在实际出现网络故障时，排障团队能够快速从业务应用系统的故障表象， 逐次识别出网络流量在各拓朴节点的入站、出站的相关问题。

回复 2 ： 聂健 资深解决方案架构师 , 红帽企业级开源解决方案中心

需要对容器网络的调用层次有一定的了解，比如 openshift 容器网络架构可以参 https://docs.openshift.com/containerplatform/3.11/admin_guide/sdn_troubleshooting.html 。日常运维，基本是要去监控关键的网络组件的状态去确定是否工作正常，而异常情况下的问题分析就需要通过 tcpdump 进行抓包分析。

更多问题可点击链接查看