之前的帖子中曾经说过自己切切实实地被Amazon的服务恶心到了，买了一个EC2 预留实例3年，结果时不时地来个退役(Instance Retirement)，然后需要重新设置实例不说，本地存储上的所有数据都会丢失。
(图源 ：pixabay)
如果这种情况遇到一次便也罢了，结果类似情况接连给我来了三次。俺们中国有句古话咋说的来着：再一再二，不能再三再四。（ "Once, twice, but not thrice or four times."）
我实在是出离愤怒了，不想再次被AWS EC2这个糟糕的Instance Retirement折磨，于是要求Amazon退还我血汗钱。客户客服态度倒是不错，到了Service Team那端就是不能退款。
或者说想退款也行，继续购买新的预留实例，然后再评估能否给我退款，还不一定给通过。我晕，这啥意思？忍了这么久还不够，还要继续忍更久？我脑袋又没进水。
于是我据理力争，据理力争的后果就是人家完全不理我了，只要我更新Support CASE就立马给我关闭，并将状态标记为已解决！这时我心里有一万头神兽送给Amazon的Service Team，或者把这句经典送给它：我去年买了个表！
不过人家店大欺客，我却只能无能狂怒，一怒之下怒了一下，最终决定就当几万块钱打了水漂吧，不去理会这事了。
而预留实例就放在那，尽管还有一年多才到期，按照比例算，也相当于价值一万多大洋，虽然这个实例可以拿来做许多事情，但是我实在是不想再启用它了。因为我怕我一旦启用了，然后再出一次Instance Retirement事件，我真的会抓狂。
(图源 ：pixabay)
不过有时候就是事与愿违，残值上万的预留实例我都丢那几个月，一直处于“Stopped”状态，今天不得已又启用起来了。
事情的原因是一个朋友告诉我现在正在运行的某个应用有些问题，需要修改代码后重新编译部署一下，而我以前都是在这个AWS EC2实例上进行编译的。
也不是说在本地机器上就无法进行，但是本地Linux机器上一直没有弄编译环境，还有就是访问国外站点速度慢不说，部分站点还可能被墙，总之相比在EC2实例上弄，还是要麻烦很多。
更要紧的是，朋友告诉我这个需要尽快处理，否则可能会有极大的可能导致程序崩溃。而一旦程序崩溃，那处理起来可不就是一两个小时的问题了。
综合比较了一下在本地编译和在EC2上编译的优缺点，我决定还是启用AWS EC2实例来做这件事吧，唉，这大概就是所谓的事与愿违吧，明明一万+的残值都要放弃了，还得打交道。
之前说过印Instance Retirement被STOP的实例处理起来比较麻烦：一个是要恢复实例的运行，另外就是恢复或者重建本地存储上的数据。
不过因为没打算拿它做之前的用途，仅仅用来编译一下，但是省却了重建本地存储上数据的过程；但是我打算在本地存储上编译，所以还是需要挂载本地存储的。
其实这里边最大的坑就是被停掉的实例重新加载后无法连接的问题：
好在被坑的次数多了，解决起来也是轻车熟路了。简单来讲就是因为本地存储变化导致/etc/fstab中挂载设置失效，实例无法正常启动。
解决的方法是先用串行控制台（serial console）登录到实例，然后编辑/etc/fstab去掉本地存储的挂载信息，然后再重启就可以正常登录啦。
之后一个麻烦事就是重新挂载本地存储，先分区，再格式化，再挂载也是得心应手了
都弄好之后，重新创建个新用户，用户主目录选择在新分区上，接下来就可以去解决程序的问题了。
解决程序的问题也不太麻烦（主要是我朋友告诉我他做的修改，我照猫画虎地去修改代码，然后再去编译，编译好了再去替换程序，再去重启程序，就可以啦。
从朋友和我说这事开始，一大早晨折腾了大概两个多小时，总算成功地解决了需要处理的问题，可以放心的补觉了。
(图源 ：pixabay)
补觉结束啦，现在新问题来了，要怎么把这个残值一万多元的EC2 保留实例利用起来呢？毕竟已经又启动了，干放那有些浪费呀。
还有就是，要不要在本地Linux主机上也完善一下编译环境（以及爱国上网等等），不然再遇到这样的情况，还要动用这个EC2实例呢，想想就很不爽呢！