Container讲师专访容器化技术在长安汽车中的实践

Posted 2022-12-03 sisiy2015

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Container讲师专访容器化技术在长安汽车中的实践相关的知识，希望对你有一定的参考价值。

为期三天在北京召开的CSDN大会刚刚落下帷幕，经CSDN云计算公众平台授权，希云为大家转载以下“CSDN采访长安汽车分布式技术架构师主任黄俊精彩的对话内容”，目的是为了让大家了解车联网在生产环境中是如何成功使用Docker容器技术的!

CSDN：您们是什么时候开始使用Docker的？能介绍下目前的一些应用情况么?

黄俊：长安汽车最早是从2014年开始探索和逐步实践Docker技术。目前已经在办公OA系统、车联网、电商等大小平台中运用。

整体上有几百个容器在运行，基本属于中等规模。系统涉及到所有中间件（zk,cache,db,mq，lb等）都使用Docker部署，我们自己开发的程序也全部Docker化。

CSDN：贵公司的业务为什么选择Docker？Docker在这样的业务中有什么优势，发挥什么样的价值？

黄俊：首先是看中了它能简化流程，降低运维成本，易于推进技术相关的标准化，对企业IT基础设施具有建设性地变革。

流程这块主要还是指贯穿开发/测试/部署各个阶段，在敏捷开发或迭代式开发时，Docker简化了配置，降低因配置而导致故障的概率。整个流程的发起只需要CI工具略作调整，还是很便捷。

运维这块Docker应用场景就很广泛了，有两点体会很深。其一，服务编排，再此之前集群部署时，我们得自己写脚本（小项目就手工部署），不同的项目脚本没法通用，再者对运维人员技能要求也相对较高，现在借助Docker服务编排功能后，功能测试/性能测试/生产环境部署等阶段，只需要调整节点数量就能发布，这就向“一键发布”迈进了一大步；其二，减少故障处理时间，理想情况下，某节点出问题后，运维人员只需要在管理界面控制部署一个新节点，并停用原有容器待开发人员故障分析，当然，在存储/网络这样系统级故障面前依然很无奈，但是对应用级故障很有帮助。

长安汽车没法像互联网企业那样拥有大量高级人才，而且还要面对水平能力参差不齐的供应商（乙方），统一技术标准对我们而言难度较大，目前正在依靠Docker容易部署的特性，逐步推广标准化技术（大部分中间件的应用场景是类似的）。

不论采用什么技术措施，技术都服务于业务，我们的目标就四个字“降本增效”，而Docker是我们改进计划中很重要的环节！

CSDN：Docker在你们公司的应用场景有哪些，能否介绍一些关键的技术栈？

黄俊：在长安汽车Docker大量使用在开发/测试中，就如前面提到的，通过CI工具打包发布镜像，测试人员直接pull并配合配置中心进行测试环境的发布。

另外一个场景就是自动化运维，这个结合配置中心，管理平台面实现部署自动化，一定程度的故障恢复，后面会详细说下这个问题。

技术栈

缓存使用的是redis + sentinel，没有使用keepalived这样的HA方
zookeeper作为服务注册与发现
数据库采用mysql，根据情况使用主从或双主方案
消息中间件使用的是activemq
负载均衡使用的是haproxy，其优点是配置足够简单
页面缓存使用的是varnish
存储这块稍微复杂些SAN，NAS(NFS，Glusterfs)等分情况使用
RPC这块我们采用了Dubbox，并将http服务与haproxy联动，使得扩展/收缩集群时能自动动态调整
名字服务，采用skydns，通过容器里的dns search来实现域名查询，例如mysql.cluster1，在集群cluster1内的
容器要访问数据库服务，可以直接使用域名mysql，而 cluster1之外的容器访问服务时加上后缀mysql.cluster1来访问
etcd作为网络的管理，负载IP地址分配，以及skydns的后端数据库，服务注册发现用了zk，就没再使用etcd了
mongodb存储Docker管理平台的配置，监控与策略信息
最后使用coreos作为容器的操作系统替换Docker machine，负责容器运行的环境（网络，存储）预配置和优化，其双根分区设定便于升级/回滚

CSDN：企业在应用Docker技术时，需要做哪些改变吗？

黄俊：我们首先做出的改变就是去掉VM层，虽然不会完全摒弃VM。推广Docker时，基本都是物理机+Docker的节奏，但同时也失去了VM自带的存储解决方案。

其次调整CI工具使其支持Docker，这个相对简单，主要工作还是在于Dockerfile的编写，不论是否财大气粗，还是建议尽量减少image的大小减少pull时间，像长安汽车这样不算大的集群都能节省开销。

在基于Docker做自动化时，还需对应用有一定改动，例如配置文件的统一管理，我们自己定制了一套配置管理中心，尽量将image里容易变化的部分独立出来，尽量保证immutable image，测试/运维的人员拿到手都是同一个image，并通过配置中心来审查“变量”的改变；再如服务注册与发现，可以提高扩展性，容灾性，同时也是为了immutable image，在实践中主要采用了zk来完成应用API级别注册，使用skydns以及etcd来完成基础中间件的注册与发现。

最后就是调整测试/运维流程，这块调整关键点不在于docker技能培训，而是需要和测试/运维团队做好沟通，改变固有的工作方式。例如通过上述措施会减少部署时的人工操作，结合服务编排甚至对一些应用系统都不需要运维人员对业务有多了解，但这反而可能会让运维团队感觉心里没底，建议除了多沟通，还需让运维团队在正式发布前多次反复预发布，降低疑虑。

CSDN：您所在的企业在应用Container/Docker技术时遇到了哪些问题？后来为何选择了希云cSphere，希云cSphere又是如何解决这些问题的？

黄俊：使用Docker过程中，在网络管理、资源调度、应用一键发布、服务自恢复、配置文件等方面，都遇到很多困惑，可能mesos拥有服务自恢复，资源调度也很强大，但对其它问题又无能为力；k8s有网络管理，但在服务编排一键发布方面能力有欠缺，而且也无法满足我们复杂的配置文件管理需求。

希云吸引我们的地方在于：

首先他们团队以前在PaaS和自动化运维管理方面经验非常丰富，运营过过万台规模的PaaS平台；

其次是试用cSphere后，发现在企业需要的每个点上都做得比较细致，可能粗看和其他平台很像，但实际使用后，会发现很能契合企业的诉求，我印象比较深的是，应用升级，新容器能默认继承过去的所有参数，包括IP地址，还有像配置批量分发等，这对于我们拥有大量遗留应用的企业而言，迁移遗留系统会比较容易；

最后，也是最重要的，我们在使用过程中的需求他们会积极采纳并纳入到产品中。

希云cSphere在网络、编排、服务自恢复、配置管理等方面的方案：

其一，网络组网，依然是bridge(非nat)方式，但将实际的业务IP绑定到容器，并且结合etcd，ipam固定容器的IP。在VMware环境中cSphere支持的其它网络模式。

其二，服务编排，没有采用compose，实现了优先级，类似linux服务优先级，数字越小优先级越高；通过优先级+服务健康检查解决服务时序精确依赖问题；服务参数模板化，例如在编排时日志目录包含可以容器名称，类似于/u01/.Container.Name/logs:/logs。

其三，服务恢复，检查宿主机上所有容器，出现不健康的节点，会按照管理员设定的策略进行恢复，noop，restart，删除重建（容器名称及参数，IP等都继承）。

其四，配置文件分发，在容器级别实现了puppet类似的功能，主要服务于中间件的基础配置，replication或cluster。特别是对于各种分布式系统，可以自动发现并生成需要的配置文件，并批量下发。

其五，Swarm替换解决方案，cSphere的调度策略：支持CPU调度，内存调度，RR调度，容器数量调度，label调度以及管理员手工微调，解决容器在部署和扩容的时候选择哪台主机的问题。

其六，Docker存储，采用device-mapper时尽量不使用loop，需要将Data file和Metadata file指向LVM挂载分区，以此提高稳定性；device-mapper在COW时是block级别，overlay是文件级别，两者需要区分使用，大量数据需要放在容器内部时推荐使用device-mapper。

CSDN：作为当前最流行的Container技术，您认为Docker还有哪些方面需要改进？

黄俊：首先，原生的网络策略不符合业务需求，在组网方面难度大，我们更希望Docker获取的IP就是业务IP，其他非Docker应用也能直接通过业务IP访问系统。

其次，存储访问与限制，从三个方面来讲，其一，即便在Dockerfile里声明了那些目录/文件需要被挂载，但对测试/运维人员而言还是然并卵；其二，针对遗留系统或特定需求的新建系统，数据容器的方案不适用；其三，在资源限制方面还得更多的人工干预cgroups，希望Docker能更多地整合cgroups的资源限制能力。

最后，服务编排，主要矛盾点在于服务的启动顺序，虽然可以指定容器启动的优先级，但无法做到“B容器必须在A容器正常启动完毕后才能开始启动”此类时序精确依赖的情况，这就对集群发布时，要么人工干预发布过程，要么就得将集群编排拆分成多个小编排，即便如此，还是在对运行了十几二十年的项目改造无能。