好玩的服务器
最近接触到两个网站的重建，过程十分有趣，文字记录一下吧，虽然没有图片，但如果以后你也碰到类似的，应该能理解。
说明
- 两个网站是一起的，依赖的基本项目是一样的。
- java项目，采用docker，多服务器，主从。
- 有连接rds等
- 网站采用验证码登录
- 重构环境要求断网环境
网站一
记录所有服务器的内网IP，根据对应的网段，为所有服务器添加对应ip的虚拟网卡，确保在IP地址不变的基础上，大家可以互联互通。
还原rds备份，并修改各个服务器的hosts，将rds地址重定向到还原好的数据库中，确保可以正常连接。
redis同理，按照配置文件启动一个即可，有密码就配置密码，一样要修改hosts。
网站一启动主要是需要先启动几个基本项目，docker直接启动即可。
其中存在一个config项目，此项目会从git仓库中拉取对应项目的yml配置文件，config没有正常启动的话，其他项目都无法启动。
- 其余项目启动时会找config要配置文件，此时config会从git仓库拉取
- docker中虽有编译好的config，但它每次还是要从仓库中拉取文件，而不是返回自身jar包中的文件
- config的配置文件中已有仓库地址及账号密码
config正常启动方式
- 本地部署gitlab，配置好对应的域名、账号与密码
- 按照请求的项目路径分别创建组和项目
- 反编译config的jar包，将文件上传至gitlab的config项目
- 启动config的docker容器
- 通过调试/日志中请求的地址尝试请求一次yml配置文件，成功即可
启动前端，一般都是用的nginx，注意观察配置文件，以便修改本机的hosts。
后台登录只能验证码登录，但是看后台接口发现，有一个type值，值为1走密码登录，其余走验证码登录，这估计是从前可以使用不同的方式登录，后面就去掉了账号密码登录，但是服务端还没有改。
通过抓包发现前端发送请求，值固定为2。
bp拦截，修改type值为1后，可以正常触发账号密码登录， 而不是手机验证码登录。
浏览器查看源码，得知type值被写死为2，在服务端修改源码，将值写死为1，然后清除浏览器对这个文件的缓存，即可正常账号密码登录。
java网站的密码加密方式，有多种解决方法。
- 直接抽出加密代码，本地运行，得到想要的密文。
- 分析加密逻辑，模拟加密行为。
- 通过项目日志或者mysql的general_log，有时会以目前输入的密码的密文为查询条件或者日志给出。
网站二
大致逻辑与网站一相同，不过在服务端有专供账号密码登录的接口，直接访问就可以绕过手机号验证码登录。
不同的是，在登录验证密码后，会向一个地址请求token，该地址不在掌握的资产当中，也没有固定下来。
通过分析代码， 知道其请求返回的内容大致如下
{
"code":代码值,
"user":{
"token":token值
}
}解决方式：
- 使用tcpdump进行抓包，分析出发送的请求的结构
- 使用Django进行接口开发， 对上述请求进行接收，并返回一个合理的数据，使项目可以正常获取token，暂时不去关心token如何生成，有一个值即可
- 在gitlab中修改这个项目的配置文件，将请求的地址改到django项目所在的地址
- 本地模拟一下请求，能够正常返回后，再尝试登录
