20170721

早上五点半又醒了。此时老头子已经起来了，窝发现窝是横着睡的。竖过来之后继续睡，睡到七点多起来过早。跑路去公司，今天啥事没干，上午先把aws上的ss服务器升级成ssr服务器，什么混淆啊加密算法什么全配上。本来还想上bbr的，要重新编译内核所以还是算了。中午又有个同事要走，所以聚餐饯别。天气太热，都不想出去，于是点了一大堆外卖就在公司吃。下午想想现在服务器连起来还不是很方便，aws的ec2重启之后ip会变。公有dns虽然不会变但配置改起来不方便，于是打算开个外网负载均衡，连的时候直接连负载均衡的dns，重启或者启用改了配置的新实例，直接让它配上负载均衡就好了。可是既然上了负载均衡，何不把自动扩容也配上呢？虽然实际上窝只需要一台机器，但是万一有什么故障，自动扩容配置会立刻重启一台新的，并且自动加入到负载均衡组里去，岂不美滋滋？弄好之后窝转念一想，连负载均衡的dns都不用配，窝直接在我自己私有域名上开个子域名，修改dns配置让它指向负载均衡的dns，那不管服务器怎么重启，只要ssr服务器的基本配置不变，客户端的配置几乎永远都不需要改了（服务器换区还是需要改的，这个没法统一用一个dns）。接下来继续安全改造什么的，开了几个两步验证，之后打算只要支持两步验证的全部打开。本来还想买yuakey（这个肯定拼错了）这种的，要转运所以暂时算了。晚饭继续咖喱牛腩，然后想想好像ssr服务器还能改。目前新起服务器都是用的准备好的ami镜像，分分钟就能起一个新的ssr服务器起来，但问题是上面的配置是固定的，要改密码非常麻烦。看了下自动扩容的启动配置也不能改，那就几乎只有一种办法了：利用自动扩容的用户数据（其实是一段shell脚本），让其从远程拉取配置覆盖本地配置。远程配置放在一个git仓库里（正好aws的codecommit可以用来干这个，而且是私有的，可能IAM权限配起来麻烦一点），如果需要不同的配置，那就用不同的分支区分开，完美！木有发布，七点跑路，回来打打神海，3的怪物是大群蜘蛛，好恶心啊……