【悲催】机房跑路，服务迁移之路
起因
最近总是遇到悲催的事情，这次的事情更悲催，某机房提供服务供应商跑路了，早上10点多通知 晚上6点断电，我X你的仙人板板。抱怨归抱怨，但是烂屁股的事情还得擦。 没办法只能换机房了，幸好早都勾搭上了一家高防供应商。但是迁移也是一个麻烦事情。
窘境
需要备份的文件过大
目前这边公司的主要提供广告服务，所有各种图片，静态页面比较多，图片总共差不多80G（分别是30G、50G 两个文件夹）
待迁移的服务器过多
大概负责3个公司，高防机器总共5台。在相对差不多8个小时（其实不到6个小时，因为整理好这些机器的业务之后差不多12点了）要处理好这些迁移事情，时间总体来说肯定是不够的。
Nginx配置太混乱
nginx的配置完全是没有章法，没有规范能操作能看就行，这就是以前的毫无规范的带来的技术债。有很多用泛解析，用default_server导致不知道有哪些域名解析上来了
服务器环境不一致
服务器软件的安装手法应该是经历了好几位前任的规划，导致手法完全不一致
特定业务域名过多
有的业务域名加起来估计都得有6000多个，其实本身多没什么事情。但是 高防机房都要对域名加百名单，这么多域名就是加完估计都得一个星期（也许大家觉得很简单，但是这里面的事情比较复杂，我觉得机房没把事情服务做好导致慢的原因）
针对方案
需要备份的文件过大
这个实在没办法，只能备份，担心同步不及时，丢数据，全部都在本地备份一份，以防万一。技巧：对于大文件、大文件夹 要使用分卷压缩（例如一个卷一个G）尽量同步更多文件回来进行备份，降低损失
待迁移的服务器过多
这个没什么好办法，一个人不够，就加人，我比较尴尬的场面是组内熟悉linux的并不多，所以只能让熟悉业务的整理nginx配置和代码，我进行环境初始化
Nginx配置太混乱
这个就没什么好办法，加人过来整理成我规范好的nginx配置就好了。在规定的文件夹放规定的东西就行了，加人安排做就行了
服务器环境不一致
这个我只能自夸我习惯好，我个人非常不喜欢重复性劳动，所以用fabric写了脚本。这样就可以快速执行服务器的软件环境初始化 并达到一致性的结果。好处：5台服务器，从12点20拿到服务器，整体安装完不到30分钟就搞定了
特定业务域名过多
这个主要是机房加白非常耗时间，从我们整理出来到机房添加成功时间是完全不够的，所以当时我们的想法是先将重要业务线加白，加白一个业务就迁移一个业务。其中有2个业务 域名比较少，业务相对来说也简单很多，所以规划先迁移。这里面的诟病就是 机房加白名单有几个烦人的地方（我不知道其他家，我说的是我这家的情况）
1：重复的提交过去在家会非常慢
2：要在工信部网站查看是否备案过，工信部的网站估计做的查询很慢大家应该用过的都知道
基于如上情况，当下午4点左右才把2个简单的业务迁移完成。然后这个时候50G的图片备份还没有完成，30G的图片已经完成了，看样子预计到6点都不太可能备份完成。只能继续其他3个业务的迁移。遇到如下图的问题
域名太多，加白肯定来不及了，我赶紧给新的供应商打电话，看看有没有什么新的方案可以先保证业务可以访问。简单电话之后，发现可以用如下方案解决
如上图，由于 proxy 不需要加白，只要域名备案了都可以，这样我们就可以先保证业务线使用， 这里其实大家也明白，上面规划的nginx目录有 vhosts_proxy 就可以解释了
零碎问题解决方案
域名怎么解析好维护
我们是按照业务区分，每个业务有一个单独的cname域名，所有需要绑定这个业务的全部都cname到 改域名，然后改域名在解析对应IP，这是我们整理之后部分这样修改了（还有一部分下周还要继续整理）。这样以后在换服务器，只用改cname域名的解析ip就好了
Nginx：could not build optimal server_names_hash
这次错误就是有的服务域名过多导致的，所以要在http 段增加两个参数
server_names_hash_max_size 4000; server_names_hash_bucket_size 128;
这个数字大家情况设置，我就是慢慢试，1000不行，设置2000，2000不行就3000 ，直到行了就可以
发布系统遇到的问题
proxy服务器不知道为什么发布就是不成功，有一个报错 如下，其实解决很简单，就是讲 /etc/sudoers 中的 “Default requiretty” 注释掉
sudo 问题：sorry, you must have a tty to run sudo
我们的发布系统很简单，但是作用对我们来说还是很大的替我们减负，提高了效率，给大家看看截图 ，可以发布代码。可以对nginx等服务进行重启操作
感谢团队
为了保证服务的正常提供，整个技术团队通宵了，感谢有他们的支持，让我们越战越成熟
