使用ansible快速部署一个主流的Web架构

ms133

　　拓扑：

　　拓扑说明：

• 　　两台服务器配置Keepalived+Nginx做双主模型的Load Balance，主机名为lb1和lb2
  
• 　　两台服务器配置lamp，用于处理动态资源请求，主机名为lamp1和lamp2
  
• 　　两台服务器配置varnish作为静态资源缓存服务器，主机名为varnish1和varnish2
  
• 　　两台服务器配置Nginx用于处理静态资源请求
  
• 　　额外需要一台服务器安装ansible，使用ansible批量管理所有服务器
  

　　关键技术点：
　　1. Keepalived配置了邮件报警脚本，当节点的状态发生改变时，会发送报警邮件（脚本中的邮箱需修改）
　　2. Load Balance部分使用Nginx进行动静分离
　　3. 调度动态资源流量时，为了绑定session会话，使用的是ip_hash算法，如果使用sticky方式调度，需要调整缓存规则，否则访问静态资源时由于拥有cookie信息，资源无法被缓
　　4. 调度静态资源流量时，为了提高缓存命中率，使用的是ip_hash算法。可以考虑使用consistent_hash算法（一致性哈希）。但经过测试，Nginx使用consistent_hash算法时，无法实现对后端服务器的健康状态监测以及故障转移。因此，如果需要使用consistent_hash算法，建议使用Tengine
　　5. 关于静态资源缓存部分，使用的是多层级缓存。前端LB上，Nginx配置了proxy_cache，用于存放少部分热点数据，后端Varnish上存放经常被访问的数据。由于测试用，前端LB上缓存的时间很短
　　6. 所有web服务每天会分割一次access_log
　　7. 在响应报文中添加自定义Hearder，可显示相应资源是从哪台服务器上获取的，便于以后排错
　　还可以进一步改进的地方：
　　1. 实验配置中的缓存策略可以进一步修改和优化
　　2. varnish的日志服务还未配置
　　3. 可以使用Tengine替代Nginx，使用consistent_hash算法提高缓存命中率的同时，分散缓存的存储位置
　　4.    关于ansible的安全隐患:
　　由于使用密钥方式进行通信，因此一旦ansible server被非法登录，其他被管理节点也存在被篡改的风险。因此，可考虑专门创建一个ansible用户用于和其他被管理节点使用密钥方式进行ssh通信，其他用户如果需要使用ansible来管理服务器，需要sudo至ansible用户来执行ansible命令，这样在日志中会有相应的记录
　　实验环境：
　　所有服务器ssh端口号: 2222
　　ansibleserver与被管理节点的通信方式:  使用密钥方式进行ssh通信，remote_user为root
　　所有服务器使用hosts来解析主机名,因此所有服务器的hosts需要保持一致
　　ansible_server   Centos7.2
　　192.168.1.200
　　lb1  Centos 7.2
　　192.168.1.202
　　llb2  Centos 7.2
　　192.168.1.203
　　varnish1  Centos 7.2
　　192.168.1.208
　　varnish2  Centos 7.2
　　192.168.1.209
　　
　　lamp1 Centos 6.5
　　192.168.1.101
　　
　　lamp2 Centos 6.5
　　192.168.1.102
　　
　　static_server1 Centos 7.2
　　192.168.1.205
　　static_server2 Centos 7.2
　　192.168.1.206
　　最终效果：

　　附件为ansible所需的所有配置文件，包含了实验中所需的所有角色，一共是两个压缩分卷。感兴趣的可以下载测试