随着互联网金融业务的兴起，各种以互联网为依托的互金企业，为与日俱增的用户提供方便快捷、稳定高效的金融类业务服务，然而这对于传统商业银行来说却造成了大量业务机会的流失。互联网金融、IT能力变革、快速应用交付……这些关键词准确地反应了当前商业银行所面临的IT现状。国内商业银行不仅要在业务层面上不断创新，对IT基础设施和应用架构也需要持续的升级改造，才能够应对这种势如破竹的互联网金融服务冲击。基于业务发展的需要和快速进步的金融科技技术，越来越多的商业银行借助云计算技术发展的东风，也开始建设适合自身的基于容器技术的云平台。希望通过容器云可以更快速地支持业务创新的落地，例如通过微服务架构，更灵活、更高效的解决业务快速上线的效率问题。
一、互金时代商业银行业务开发交付的困境
随着虚拟化技术的发展，大部分的商业银行都已经通过vsphere、KVM、Fusionsphere等虚拟化平台，实现了物理机虚拟化。的确，通过虚拟化技术在一定程度上降低了运维复杂性，提升了资源的利用率。云计算环境中Iaas模式的发展离不开虚拟化技术和openstack的支持。然而，针对银行的业务系统发展却依然有不少应用开发交付方面的问题尚未得到有效的解决：
首先，互联网金融的冲击让传统的商业银行开始重视用户体验和需求，这样才能在“互联网+”的浪潮中获得生存。因此，业务部门提出的业务需求就要求IT部门迅速做出响应，这也是商业银行生存和发展的必然过程。
其次，商业银行的大部分应用系统都是通过基础软件（包括基础系统、中间件、开发组件等等）经过二次开发“组装”而成，这些基础软件基本上都是一些功能全面而又复杂的商业化软件。然而，对于商业银行的业务应用真正可以使用的功能却只是占到极少部分。这些基础软件一般都存在系统架构复杂、安装部署繁琐等问题。此外，无论是对于开发人员还是运维人员来说都需要一个较为漫长的学习过程；
再次，商业银行应用系统规模越来越复杂，庞大的部署架构模式使得应用的安装、部署和更新也显得比较臃肿，使得业务停机时间和部署成本都有所增加。运维人员都希望能够通过以微服务的方式解决这类问题；
最后，无论是vsphere商用解决方案还是开源的KVM虚拟化技术，依然面临着硬件使用率相对较低、资源分配调度相对缓慢等问题。
基于以上原因，商业银行的IT部门需要急需缓解这些问题从而能够更好的提升开发和运维团队的生产力，更加灵活、高效、快速的满足业务系统需求，最大限度的提升业务价值。近年来，各种开源容器技术经过不断的发展和完善，建设容器云的价值也被不少商业银行逐渐发掘出来。容器技术能够从本质上更好的解决在新形势下，商业银行在敏捷开发、测试、运维上所面临的问题。
二、业务交付标准化——容器技术
在工业1.0/2.0时代，区区一颗螺丝钉的标准化，极大的提升了整个制造业的生产效率。同理，在即将到来的工业4.0时代应用交付的标准化对于IT业的未来也必将带来一次效率上的飞跃。业界不少人认为容器技术是计算的未来，其根本原因是使应用交付标准化，而标准化意味着高效。容器技术通过标准镜像的方式，屏蔽应用部署过程中针对不同环境需要的环境配置、安装步骤等复杂的过程。把原先投产交付阶段需要部署和配置的运维工作提前到了开发、测试阶段完成，并且能够在制作镜像阶段有效地解决运维上线中大部分有可能出现的部署问题。
笔者认为，商业银行业对业务应用开发和交付的变革总体来说主要体现两个方面：一方面是业务应用如何快速地进行软件交付，另一方面是交付后如何高效稳定地进行系统的管理和运维。在过去，同一个业务应用的开发、测试和运维分别由各自独立的部门负责，部门之间每个阶段的交付件都不完全相同，例如软件代码、软件测试包等。这就导致了部门之间沟通成本高，协作效率低。这样的瀑布式的开发模式已经不能适应这个追求“快感”的时代。
容器技术的应用定义了一个业务交付的标准 ——无论是开发、测试还是运维，交付的都是容器。目前，开源的容器技术包括Docker、CoreOS和Rocket等。以Docker容器技术为例，通过镜像仓库协作，无论是开发测试还是生产都是基于镜像仓库进行操作，交付出来的容器镜像放进仓库，根据业务需求不同，从中提取合适的版本进行测试、上线。开发人员可以选择在代码调整之后，自动进行用例测试、生成镜像、部署上线，极大地提升了迭代的效率。
另外，复杂系统的运维、IT资源浪费都可以说是交付后运维人员的痛点。然而，通过Docker容器方式交付的应用，企业可以根据需要对应用进行逐步容器化，就好像堆砌积木一样，一个一个地搭建起来。通过这样循序渐进的方式可以更适合商业银行在业务应用开发运维方面的转变，也可以帮助商业银行更有效的实现资产投资保护。对于复杂系统的运维问题，借助Docker容器轻量化的优势，使应用业务实现快速启动。例如当一个容器镜像宕掉，可以秒起另一个容器镜像，几乎没有不存在宕机时间，这极大地提升了系统的高可用性。
此外，Docker容器实际上是基于Linux内核的代码集，既可以运行虚拟机环境，也可以在物理机上运行，这对于目前商业银行的虚拟机和物理机共存的IT环境，进一步地保护了银行资产的前期投资。
三、容器云建设对商业银行IT发展的价值
l、有效整合现有资源，提升资源利用率
如前所述，容器技术是基于操作系统的轻量级虚拟化技术，与传统的虚拟机技术相比，通过多个容器共享操作系统的内核进程和内核资源，从而有效节省操作系统级资源开销， 通过容器密度的提升更好的利用资源。如下图所示：
因此，容器技术可以基于云计算环境的PaaS模式建立容器云，例如通过开源的openstack环境、商用的vmware环境等，有效避免厂商的绑定，可实现对商业银行已有异构基础资源的统一化管理，这种统一管理应用的模式屏蔽环境差异性，降低系统运维难度，例如招商银行的容器云平台。
2、业务应用快速部署
对于商业银行，例如工商银行通过开展基于容器技术的应用云平台规划和建设，已经在互联网金融、第三方支付、纪念币预约等应用系统实施了云化和微服务化改造，基于分布式系统框架实现资源弹性供应，快速响应业务突发增长需求，有效应对了“双十一”、“纪念币发行”、“微信红包”等互联网业务冲击【1】。
通过容器云可以快速搭建应用开发测试环境，并且结合微服务架构，可以加快应用的部署能力，进而提升持续交付的能力。另外，对于互联网接入和网关类的交易类业务，一般需要良好的故障隔离和水平扩展性能力，容器可以提供快速部署和迅速的故障转移；对于非交易类的应用，微服务也是目前容器云上最合适的应用架构，通过微服务实现内部生态系统的建设。
3、促进Devops架构的落地实施
容器所特有的build、ship、run理念及其技术特点，更好的与CI/CD技术进行融合，促进CI/CD理念的落地，可以从技术手段上保证项目管理方式和管理理念的真正有效落地；
4、企业自身软件资产的积累
镜像仓库通过对应用镜像的集中管理可实现类似应用商店的功能，有利于更好的沉淀和积累行内的企业软件资产，从而更加快速高效的提供各种运行环境。
四、容器云建设的安全管理
安全管理是满足行业监管要求必须考虑的问题，是商业银行建设容器云平台的基本要求。与传统的安全管理一样，商业银行容器云的安全管理的包括系统漏洞、病毒威胁、链路加密、攻击防御、系统访问权限控制、操作审计等等。另外，结合容器技术自身的特点，在商业银行安全管理的基础上，还需要考虑多租户隔离、角色管理、镜像安全检测等新问题。
1、容器安全的合规
考虑到安全管理的复杂性，笔者认为如果把容器云单独进行安全管理将会付出高昂的代价，而且安全管理需要经过长时间的积累，难免在一段时间内出现各种事前未考虑完善的安全问题。笔者认为，容器云在安全管理上可以直接应用银行现有的安全管理防范体系，充分利用现有的各类安全工具、手段，在现有安全管理手段的基础上，按需增加相关安全策略，应对容器云平台带来的新问题。
商业银行面对严格的行业安全监管要求，现有的安全管理防范体系，无论是技术工具设备还是安全操作流程，或者指导规范等都已经有一定的完备性，例如系统漏洞的扫描、补丁的安装、防病毒系统、统一身份认证、访问安全管理、操作日志审计等等。为了有效利用这些工具和措施，在设计容器云平台的网络设计上，就需要仔细考虑使这些工具和手段在容器云平台上可以发挥最大的作用。以漏洞扫描为例，深圳某股份制银行为能实现在容器云平台上对系统漏洞扫描，在网络方案设计初期，就已经让漏洞扫描服务能够与云平台中的容器IP路由可达。
2、多租户隔离
商业银行的容器云同样需要为不同的用户（租户）提供不同级别的安全隔离服务。笔者认为可以把不同用户的容器运行在各自不同的VLAN中，不同的VLAN之间通过防火墙策略或者路由控制，确保不同用户（租户）业务在网络上的隔离。另外，容器技术的特点就是需要共享宿主机系统内核，如果把不同用户（租户）的容器运行在同一台宿主机上，可能面临来自其他用户（租户）容器运行带来的不利影响，例如：相互资源竞争导致的宿主机性能下降；其他用户（租户）容器的应用风险导致宿主机内核运行异常，从而进一步导致自己容器的运行故障；另外，还需要考虑是否存在来自其他租户的恶意容器应用，利用共享内核进行攻击和窃密等等。
笔者认为容器云平台应该为不同的租户分配各自专用的、不同的资源池，每个用户（租户）只能在属于自己的宿主机上运行自己的容器应用。这似乎跟云环境下资源共享理念背道而驰，并最终导致了削弱了资源利用率。然而，这确是目前从根本上避免容器运行依赖共享主机系统内核而天生隔离性不如虚拟机的安全问题。这跟主要基于虚拟机的IaaS平台对多租户隔离的做法不同。
笔者曾经在深圳某银行信用卡中心交流过程当中了解到，其容器云主要是基于虚拟机的IaaS模式实现对多租户隔离，从而能够避免容器自身隔离性不足的安全风险。因此，对于这些基于IaaS模式实现的容器云，我们首先需要考虑的问题除了容器内的安全外，最重要的是需要先考虑虚拟机之间的隔离和Hypervisor自身的安全问题。
3、应用等级隔离
除了不同用户（租户）间的隔离问题外，还需要在同一用户（租户）环境下，运行不同安全等级的应用。因为容器共享系统内核的特点，应用也面临其它等级应用的资源争抢、故障影响等问题。另外，不同等级的应用，往往要求不同级别的运行环境高可用性、安全性。因此在同一用户（租户）下，也应该把不同等级的应用进行隔离，分别部署到各自专属的资源池内。
4、镜像仓库
镜像仓库主要负责存储和发布应用的镜像部署版本，在功能上看并不复杂。但是，由于监管要求和业务的特殊性，银行也应该高度关切生产环境的安全性。对于用于生产发布的镜像版本必须通过严格的测试阶段，以及严密的安全检查步骤，例如中间件的漏洞扫描、安全基线核查等。因此，笔者认为对生产环境应该运行专用的生产镜像仓库；与此同时，在持续集成越来越普遍的环境下，为了确保敏捷的开发和测试环境，我们还需要建立测试镜像仓库。因此，在建设镜像仓库的时候，生产镜像库和测试镜像库在存储物理上分离，网络上的连通性，并通过防火墙策略进行限制，以最小化开放为原则，只开放必须的端口用于镜像的同步。
另外，在镜像使用安全策略上，测试镜像仓库允许对镜像随时进行上传和更新；相反，对于生产镜像仓库，为了保证镜像来源的安全、可控，应该限制为只能从测试镜像同步。镜像仓库体系和相关工作流程如下图所示，从安全策略上规定只有在测试镜像仓库中标记为完成测试或者已经完成安全检查的镜像，并且必须由具有相应权限的用户账号，在经过必要的审批或者满足一定规则的情况下，从测试镜像仓库中把镜像同步到生产镜像仓库。这一权限审核管控的过程可以通过堡垒机的审核功能来完成。当新的镜像进入生产镜像仓库，就被当作正式的生产发布版本，接下来就可以按照商业银行现有的生产发布和变更流程，在指定的变更窗口，从生产镜像库中拉取镜像进行部署，这样做能够切实地满足了银行的安全监管要求。
结束语
本文短短的数千字并不能完整地阐述商业银行容器云建设所需要考虑的问题，然而容器云的安全建设至少还包括业务应用的服务编排、容器运行监控日志、网络方案的设计等等问题。容器云平台既要与底层基础设施交互，又要支持顶层应用，涉及面和覆盖面都非常广泛。因此，在建设过程中与企业已有设备、流程进行结合时需要进行综合考虑。上述内容笔者近期在跟银行客户交流后对容器技术的浅见，算是抛砖引玉吧！知识面有限，也可能存在理解的误区，欢迎读者给予纠正。
2018容器报告
引用【1】 http://www.sohu.com/a/150531919_466918
参考书籍：
《云计算架构技术与实践（第二版）》，清华大学出版社
《云计算关键领域安全指南v4.0》，CSA