4.1.3 游戏部署的自动化实践
传统IT模式的“半人肉”部署实践
游戏运维的早期开服以人肉为主，分区分服务阶拆解的最原始动作包括：游戏服 务端打包->解压游戏包->变更配置修改区服务->初始化数据库(清档)->qa测试->对 外开放入口。如果今天的服务器只有一台两台没有问题，随着服务器数量增多，实践多，实践中经常遇到游戏火爆的突发开服事件，而且在2011年后游戏联合运营模式出 现，人肉模式会涌现了很多问题，而且随着开服时间拉长，到一定生命周期后也面临 着繁复的合服工作，游戏运维对开服、合服做了脚本化工作，那也是自动化的早期雏 形，可勉强应对数千台规模的服务部署。
早期的版本部署/变更脚本示例：
自动化运维体系构成及结构关系图
基于shell半自动化工作，基本可以应对百至千服的常规工作，随着虚拟化普 及，游戏上云后ECS镜像功能。游戏运维会建立每个游戏服角色镜像：这个操作会让 你快速启动另一组服务器，例如你搭建完一组，共三台，游戏服1，游戏服2，游戏服 3，调试完毕后，为每个服做一个镜像，这样你就可以快速启动1组新服，很快就可以 完成上百组服务器的配置，在需要开新服时，你基本5分钟就可以开一组，所以为每 个不同角色的游戏服留镜像是很有必要的，同时也可以使用跨区复制功能，快速在另 一个region搭建新服，快速完成多region部署，这些工作通过api是可以做到完全自 动化的，基本实现了数千台规模的服务部署。
基于Ansible的自动化部署实践
最早我们用SSH写很多脚本，要用SSH连过去，也是在某一台机器上执行，不用 在目标机上登陆。这种做法在相当一段时间内是我们实际使用的手段， 它实际上比 Puppet有效。但是它有一些问题：管理成本高、脚本会越来越多。部署的过程有很 多的基础部件需要反复部署，几乎是没法管理。后来我们用了RunDeck，它有界 面、有一定的管理能力。我们还用过Fabric，即批量执行命令，能做到类似部署的事 情。但是，目标机规模大了之后仅有管理的能力是不够的。后来我们又调研过 Salt， 不认为有太大的差别。选择Ansible主要因为丰富的相关支持，包括很多现有的组件 和模块和开源的Ansible部署和脚本。我们的团队不喜欢纠结。我们发现Ansible没有 太本质的区别，就开始用起来。它可以配置系统，部署软件以及协调更高级的IT任 务， 例如持续部署， 滚动更新。Ansible适用于管理企业IT基础设施， 从具有少数主 机的小规模到数千个实例的企业环境。具备了简单、强大、无代理的三大优势。简单 的说底层就是pssh的批量逻辑，上层封装playbook执行，语法非常接近shell，从历 史的部署模式进行改造非常方便，基本实现了数万台规模的服务部署。
