Docker 在游戏业务中的应用介绍

Docker简介

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上。
简单说，Docker让整个运维环境标准化，真正实现build（构建）、ship（部署）、run any app，Anywhere（无差异的在任何环境中运行应用）。

Docker在游戏领域的应用模式

Docker通过与母机共享内核，具有轻量级、启动速度快、支持在线升降配（cpu+内存）等特点，并且基于镜像可以非常快速的构建一致性环境用于业务的集成发布、扩缩容、故障处理等场景中。我们看到很多业务已经开始体验Docker给业务带来的优势，从整体架构上来说，目前在游戏上的应用主要分为两种形式：

1. 虚拟机模式

虚拟机模式是Docker应用上最基础、最简单的模式，也是应用最多的模式。不管是新业务，还是老业务都能够通过快速的替换实现对Docker的利用，基本上可以无门槛接入。业务也只是把Docker容器作为一台虚拟机使用，像在虚拟机上一样部署自己的业务，包括cron，监控，周边系统，业务进程等等。

那么这里的优势主要体现在，可以在业务无感知的情况下进行在线升降配。比如：对于分区分服的游戏来说，往往大区的在线分布很不均衡，为了减少日常维护的复杂度，业务基本上都会维护一致的区服架构，这样对于在线比较低的大区，低负载就会比较严重。而如果业务使用的Docker话，就可以在业务无感知的情况下快速的在线降配，及时的释放资源，降低业务的运营成本，甚至可以进一步结合业务的在线数据直接做到自动升降配，无需人为的干预。但这里需要注意的是，如果大区在线比较稳定的话，单纯降配是没有问题的，但如果只是波动，就需要考虑到业务在升配的时候，资源申请问题（因为有可能释放的资源已经被其他业务给使用了）。

tips：这里我们也看到在虚拟机的应用模式下，业务的运维模式其实变化不大，这其中既有业务运维本身对Docker的理解有限，同时也被业务现有的架构流程所局限难以施展。

2. 集群模式

Docker集群模式在对Docker更深的理解之上构建的业务形态，推崇在一个容器上只部署一个进程，通过mesos、k8s等来管理整个容器集群。业务在Docker集群模式下，已经没有了机器的概念，可以充分利用镜像、容器、仓库所带来的持续集成发布、故障处理、以及扩缩容上的巨大优势。比如发布流程：通过持续集成，开发可以直接交付镜像给到运维，镜像按照模块区分，通过tag标识不同的版本，提交发布后系统可以直接拉取最新的镜像重启容器，也可以依赖k8s做滚动的升级。通过镜像的方式，业务大部分的配置也可以直接打包到镜像，不再需要依赖复杂的配置管理工具。

tips：类似这种颠覆式的改变，需要运维从业务立项就开始介入，与开发、SA同事一同搭建整个集群生态系统。当然也会有一些新的挑战，比如：在集群模式下的网络架构、业务监控、容器日志集中处理、风险控制等等。

docker Image的应用

从上面我们也看到集群模式是可以更好的发挥Docker的优势，但是接入改造是一个漫长的系统过程，也有待于周边平台的完善。在虚拟机模式下，利用Docker image其实也可以在弹性扩缩容、容量管理、故障处理方面给业务带来很大的优势。但我们也知道在游戏业务中，不管是扩缩容，还是故障处理都有很高的时效要求，运维是不可能手动一步步去处理的。所以这里在环境一致性和交付效率上也遇到一些新的挑战，比如：

1. 标准化问题

为了让业务申请的容器环境尽量跟外网保持一致，减少后续的配置变更，通过对业务指定的镜像机进行clone，实现包括：iptables策略，cron策略，卷目录大小的一致，针对data目录还可以进一步指定相关的exclude目录，并且优化了Ladp和周边系统的同步刷新。而镜像版本的一致性由运维通过独立的接口进行配置维护。默认业务申请容器的时候是拉取最新的镜像，特殊情况下业务也可以通过指定tag来拉取特定的镜像。

2. 交付效率

通过分析发现，在容器的交付过程中最耗时的两步是：

1) 创建容器时从镜像仓库拉取镜像

2) 容器创建完成后，还经过CMDB流转到业务自己的配置管理模块下

为了提高交付的效率，通过联合资源同事搭建了独立的Docker集群，通过镜像预先部署的方式来避免每次从镜像仓库拉取，配置管理系统目前也在跟周边同事一起优化，目前已实现秒级的容器创建，可在1分钟内完成资源交付使用。

3. 周边系统同步效率

业务扩缩容或者故障处理，运维在拿到交付的容器后，往往还需要同步周边系统的权限，比如：tgw、vasky、安全等。现阶段来看在镜像资源交付已经秒级的情况下，相比而言周边平台处理还是比较耗时的，通过分析把部分步骤并行，部分步骤前置可以一定程度上解决这个问题，但也还需要进一步推动相关的系统平台进行优化改造。

所以在解决了这些问题之后，即便是虚拟机模式下，业务也能在下列场景上发挥出Docker Image带来的优势：

• 弹性扩缩容
  

业务扩容一方面可以通过已预部署镜像的集群快速申请容器资源，申请到的环境跟外网的基本一致，运维只需要更新周边权限和拉起进程就可以快速的上线提供服务，也可以通过在线升配来快速满足业务紧急扩容的需求。同样业务缩容一方面可以走正常的容器回收下线流程，也可以直接在线降配。需要强调的是，在线升降配作为弹性伸缩的一种，操作起来固然很简单，但游戏有时需要考虑同屏人数、游戏活跃度，从运营策略上考虑可能并不是很适合。

• 容量管理
  

根据以往的经验，业务为了应对在线的波动，实际的建设容量都会偏高一些。在利用Docker镜像以后，业务可以在秒级获取到跟外网版本一致的容器，通过简单的配置更新拉起，即可给业务快速的扩容，再加上Docker在线的升降配能力可以使业务具备极强的伸缩能力，运维也可以根据实际情况来降低业务建设容量，降低运营成本。

但需要注意的是：为了提升整个资源的规模利用效率，集群容量是共享的，业务需要提前根据实际情况申请配额，然后由资源交付同事进行集群的建设维护。比如：为满足业务故障替换、快速扩容等紧急情况而搭建的特定集群，一般不支持业务的常规替换、搬迁等时效比较低，并且资源流转也比较慢的需求。

• 故障处理
  

利用Docker Image做故障恢复，主要优势体现在：

流程优化：过去机器故障，一般是优先重启机器恢复，如果机器重启失败，则再走机器替换流程。可以看到不管 是机器重启还是机器替换都比较耗时。而拥有镜像容器之后，业务在机器故障时，则可以直接走镜像容器的创建和替换，直接在新容器上进行业务恢复，不再等待故障机器的重启和恢复。流程相对简单，也比较容易实现自动化，或者跟现有的故障自愈流程结合。

效率提升： 通过Image恢复故障，除了流程上的简单高效外，还存在并发优势，因为容器或者虚拟机都依赖母机硬件，所以会出现多台机器同时异常的情况。而Docker Image在申请容器方便，并发优势明显，经测目前不到2分钟即可交付上百台容器资源，大幅提高了处理效率。

成本节约： 走快速Docker Image替换，业务不再需要维护bak机器，有利于资源盘活，降低成本。

简单总结下业务使用Image前后的优势对比：

四，总结

在基础运维工作已经自动化的今天，容器技术进一步颠覆了传统的资源管理和业务运维方式。从镜像的构建到容器的编排管理，容器作为计算资源的提供者，使得运维不再关心具体的机器，甚至也不再需要额外的配置管理，一个个镜像就是一个个独立的业务模块，可随时根据需要调度生成指定数量的容器来提供服务。并且通过跟周边系统的打通，运维日常的发布、扩缩容、故障处理也都可以自动实现。

在容器化运维的新时代，尽管一切还在摸索中，但我们已经可以看到新趋势下容器技术给业务运维带来了前所未有的优势和挑战。这一阶段，运维作为连接用户和业务的纽带，也更加需要深入到基础平台的构建和业务的发展规划中去，只有这样才能不被时代所抛弃，也才能不断的给业务创造更大的价值。

来源：腾讯云