运维与自动化
运维与自动化概述
一：运维工作内容分类：
1).机房运维（负责服务器上下架、IP配置与划分、服务器打标签、机房定期巡检、服务器故障报修、服务器硬件监控)
2).基础设施运维（系统安装及初始化、网络维护）
3).监控运维（7×24运维值班、简单故障处理、通知相关业务负责人）
4).基础服务运维（包含运维开发）（内部DNS管理、负载均衡配置、系统监控报警、硬件资产管理平台、监控平台搭建、代码发布平台）
5).应用运维（精通公司业务、各种服务系统部署、业务系统部署、版本管理、灰度发布、应用监控）
6).系统运维（架构层面的分布式缓存、分布式文件系统、日志收集与分析、业务环境规划（测试、开发、生产）、业务架构设计与规划实施、服务器系统性能调优）
7).安全运维（整体的安全方案、规范、漏洞监测、DDOS防护、病毒防护及处理、关键程序包更新、漏洞扫描与修补等）
二：运维的发展线路：
1).搭建服务–可以安装服务并运行，由于是参加工作没有相关服务安装和部署经验，所以此阶段的主要目的是可以把服务安装并可以运行起来。
2).用好服务–适当对服务优化，工作一两年后可以根据业务的实际需求对服务做适当的优化，比如可以对nginx做调优和监控。
3).自动化–自动化服务的部署或监控，工作三到五年后可以结合自动化部署工具或编写脚本实现业务的自动化部署。
4).产品设计（如何设计一个监控系统），可以根据需要设计和部署大型业务系统，现在很多公司都在用云服务，比如阿里云、Amazon的AWS，微软的Azure，以及腾讯云、青云等等各种云计算，云计算的核心竞争力是运维，其始终离不开运维对业务的技术支撑，比如搭建云服务时的服务器选型、网络规划、物理机系统部署与优化、监控系统的安装配置等等。
三：自动化运维之运维标准化
1.物理设备层面：
1).服务器标签化（IP地址/与交换机接口/当前服务/）、设备负责人（管理人）、设备采购详情（保修日期）、设备摆放标准（服务器之间间隔1U通风）。
2).网络划分、远程控制卡、网卡端口。
3).服务器厂商机型号同一、硬盘大小转速同一、内存统型号大小频率一、服务器课根据业务分类，有的要求IO高（存储服务器），有的要求内存大（缓存服务器），有的要求CPU块（代理服务器），有 的对CPU和IO要求CPU和内存都高（数据库服务器）。
4).资产命名规范、编号规范、类型规范。
5).监控标准（统一阈值和监控类型）。
2.操作系统层面：
1).操作系统版本（不要混合使用linux和windows,linux发行版尽量统一）
2).系统初始化（IP、网关、掩码、DNS、NTP、内核参数调优、rsyslog、主机名规范、任务计划）
3).基础Agent配备（Zabbix Agent、Logstash Agent、Saltstack minion）
4).系统监控标准（CPU使用率、内存使用率、硬盘使用率、IO延时、网络状况、进程数与僵尸进程、运行时间等）
3.应用服务层面：
1).Web服务器选型（LNMP/LAMP/Tomcat/MySQL）
2).进程启动用户身份及目录、端口监听规范、日志收集规范（访问日志、错误日志、运行日志、系统日志）
3).配置管理（配置文件规范、脚本规范）
4).架构规范（Nginx+Keepalived、LVS+Keepalived、Haproxy+Keepalived、阿里云SLB、Ucloud ULB等等）
5).部署规范（位置、包命名等）
4.运维操作层面：
1).机房巡检流程（巡检周期、巡检内容、硬件报修流程）
2).业务部署流程（先在开发环境和测试环境测试、最后后在生产环境部署、如出现问题立即回滚、出现问题先回滚再修复）
3).故障处理流程（紧急故障处理、故障升级流程及时间、重大故障管理、责任分配）
4).工作日志标准（如何编写工作日志周报、月报）
5).业务上线流程（1.项目发起人 2.系统安装部署优化 3.部署Nginx及相关访问 4.备案及解析域名 5.上线测试 6.对服务和主机加监控 7.数据定期备份）
6).业务下线流程（谁发起，下线时间，服务器和数据如何处理。）
7).运维安全规范（密码复杂度、更改周期、VPN使用规范、服务登录规范、命令使用规范、备份还原规范）
运维标准化实现业务规范化，最终达到文档化的目的，即所有和业务相关的都有文档可查，包括技术文档、升级文档、故障文档等，也不会导致因为某员工离职而导致业务中断。
四：自动化运维之工具化：通过相关运维工具，替代需要人工需要多次执行单一的工作内容，如：
1).Shell或Python脚本（简单功能配置或修改的脚本，如自动修改配置文件、流程执行的脚本，如需要先修改完配置文件才能重启服务、检查性，如检查配置文件是否修改，日志是否生成、报表性的脚本，如生成自定义数据的文本文档并自动发送到邮箱）
2).开源监控工具：Zabbix ELKStack SaltStack Cobbler
3).开源部署工具：cobbler、walle、jenkins等
4).开源跳板工具：jumperserver等
运维工具化带来的好处：
1).促进标准化的实施
2).将重复的操作，简单化
3).将多次操作，流程化
4).减少人为操作的低效和降低故障率
运维工具化遇到的问题：
1).你至少要ssh到服务器执行。可能犯错
2).多个脚本有执行顺序的时候，可能犯错。
3).权限不好管理，日志没法统计。
4).无法避免手工操作。
例子：比如某天某台Web服务器磁盘可能发生问题，要在访问量较低的凌晨要将服务器的数据导出来放在其他服务器替代，那么需要考虑的是：
1).是否有由其他服务器连接此服务器取数据或此服务器是否到其他服务器取数据。
2).此服务器是否有定时任务计划到其他服务器执行或有其他服务器连接到此服务器执行。
3).任务计划索要涉及的内容，以及停服务是否影响其他服务器。
4).后续的代码更新问题。
五：自动化运维之web化
公司基于php等语言自己开发的可以在web通过鼠标点击就能实现代码发布和回滚等功能的web界面的操作平台。
1).招聘开发运维做成Web界面。
2).web界面的登录权限控制。
3).操作日志记录。
4).一键部署所有指定服务器，弱化操作流程。
5).不用ssh到每台后端服务器，减少人为误操作的故障率。
例如：
1).DNS Web管理 bind-DLZ
2).负载均衡Web管理
3).Job管理平台
4).监控平台 Zabbix
5).操作系统安装平台
六：自动化运维之服务化（API化）
1).DNS Web管理 ———->bind-DLZ dns-api（bind）
2).负载均衡Web管理——>slb-api（haproxy、LVS、Nginx）
3).Job管理平台————->job-api（php自主开发）
4).监控平台 Zabbix ——->zabbix-api（zabbix、nagios、cacti）
5).操作系统安装平台——>cobbler-api（cobbler、kickstack）
6).部署平台——————>deploy-api（安装服务软件nginx+php）
7).配置管理平台————>saltstack-api（saltstack、ansible）
8).自动化测试平台———>test-api（自主开发测试）
通过调用相关api实现服务器从系统安装到上线完全自动化：
1).调用cobbler-api自动安装指定的操作系统
2).调用saltstack-api进行系统初始化和配置
3).调用dns-api 解析域名和主机名
4).调用zabbix-api 讲该新上线机器加上监控
5).再次调用saltstack-api 部署访问软件（安装Nginx+PHP,Tomcat,Mysql）
6).调用deploy-api 将当前最新稳定版本的代码部署到服务器上的指定目录。
7).调用test-api 测试当前服务运行十分正常，如有异常，则执行报警等操作
8).调用slb-api 将该节点加入集群
七：自动化运维之智能化：
能根据一定的策略或条件，智能化的自动化扩容、缩容、（服务降级、故障自修复），包括自动发布代码加进负载集群等一些列操作
触发:指的是触发事先定义的一个阈值，可能是CPU使用率80%，也可能是并发超过100000，也可能是web访问响应时间超过5s，这是一个触发机制，然后要定义要做的决策，如：
1).当某个集群的访问量超过最大支撑量，比如10000
1.1 CPU使用率达到xx% 内存使用率达到xx% 响应时间> x秒
2).此状态已经持续5分钟。
3).判断不是攻击
4).扩张资源池有可用资源
4.1).当前网络带宽使用率
4.2).如果是公有云(钱够不够)
5).当前后端服务支撑量是否超过阈值 如果超过应该后端先扩容
6).数据库是否可以支撑当前并发
7).当前自动化扩展队列，是否有正在扩容的节点
8).其它业务相关的。
自动化扩容机制：
1).扩容之前：先判断Buffer区域是否有最近x小时，已经移除的之前创建的虚拟机，并查询软件版本是否和当前一致，如果一致，跳过 2 3 4步骤，如果不一致，跳过2 3。
2). OpenStack 创建虚拟机
3). Saltstack 配置环境—-监控
4). 部署系统部署当前代码
5). 测试服务是否可用（注意间隔和次数）
6). 加入集群
7). 通知（短信、邮件）
自动化缩容机制：
1).触发条件和决策
2).从集群中移除节点-关闭监控-移除
3).通知
4).移除的节点存放于Buffer里面。
5).Buffer里面超过1天的虚拟机，自动关闭，存放于xx区
6).Buffer区的虚拟机，每7天清理删除。
##################################################################################
自动化安装和部署概述
一、自动化安装
1.采购–>验货–>签字，验货单，盖公章。
2.资产管理：资产录入–>机房、区域、排、机柜、位置、配置（资产管理，验收单）（自动化获取）
3.RAID-（验货的时候）RAID,自动化进行配置
4.CMDB：资产录入–>机房、区域、排、机柜、位置、配置。MAC地址清单。+（后期收集） 资产收集、录入，管理和AP，并且展示。
5. 开机 关机 重启（IPMI）
6. 详细配置 IP地址 掩码 网关 主机名 DNS （DNS解析）-> 开始安装–>使用cobbler
7、安装完毕。角色(API Nginx PHP(memcache redis pdo) 启动，代码部署)
8.SaltStack-salt-key 执行状态，配置完毕。
9.自动进行检查（测试系统）+（etcd）加入集群。
10.加入监控
二、自动化部署
1、部署环境
开发环境
测试环境（功能测试、性能测试）
预生产环境即灰度环境（生产环境的一个不对外的节点，和生产环境公用一套数据库、redis等资源）
生产环境
2、代码部署的几种情况
第一种 git pull
svn update
rsync 缺点：不能做到及时回滚，适合代码更新非常不频繁的情况
第二种 rz sz 缺点：毫无任何优点
3、实现真正的自动化部署
下文的前提是针对运维来说：代码已经在发布分支，进行发布。
1）获取代码 git pull
a、最新的 b、commit id c、做好tag
2）编译（可选）build (ant maven)
3）配置文件。
a、分环境（配置单独进行存放，config.example ）
b、统一的.集群有10个节点。Job节点 crontab.xml
4）打包 包名的设计 项目名称 环境名称 版本 时间
5）文件分发（SCP salt-cp rsync） 校验 md5
6）将待部署节点，从集群中摘除
7）解压软件包
8）创建软连接
软连接是关键是关键，速度快，准确。同时存在缺点，一定要重启php（清除opcache），tomcat等服务
9）同步差异配置文件
10）重启Web服务
11）测试，验证，如果不通过则停止升级
12）加入集群
3、自动化部署的优势
1.快速回滚
2.部署统计（使用nginx，禁止访问.svn）
3.配置文件管理
三、回退（回滚）
1、紧急回退
1）列出版本
2）回退
2、正常回退
正常回退到上一个版本，此次bug影响面波及不大，不涉及钱财的订单交易，不建议使用紧急回退方式，
建议使用重新发布上一个的方式。
四、拓展
并行：由于上述上线方案默认是串行方式，在这里可以可以分组部署，达到一个并行的效果，同时可以让测试人员分组测试，已满足上线要求。当然，这是node很多的情况，具体情况依照公司情况分析。
日志记录：日志当然是必要的，这里不再强调。
部署服务器双机：从携程的事情上，得到教训，双机部署的重要性，如果不是携程的人员及时在一个机器上找回了代码，后果就不堪设想啦。
回滚的必要性：这里提到了回滚的必要性，这是必须要执行的，遇到问题及时回滚，尤其是在业务高峰阶段，谨记不要上线代码！切记不能让开发人员在关键时刻修复bug，这样只会越拖越久，最终挨批的一定是运维人员。这是运维背黑锅的最大痛点之一，CEO绝不会把责任归属于开发，反而会问运维人员，为什么不执行回滚。
###############################################################################
自动化部署基础与shell脚本实现
关于自动化的基础知识：
1.1：当前代码部署的实现方式：
运维纯手工scp到web服务器
纯手工登录git服务器执行git pull或svn服务器执行svn update更新代码
通过xftp上传代码
开发打压缩包上传到服务器然后解压
缺点：
1.需要运维全程参与，占用大量的工作时间
2.上线时间比较慢
3.人为造成的失误较多，管理比较混乱
4.回滚复杂而且慢，还不及时
1.2：运行环境规划：
开发环境：开发者本地有自己的环境，然后运维需要设置开发环境的公用服务，例如开发数据库、redis、memcached等
测试环境：功能测试环境和性能测试环境
预生产环境：由生产环境集群中的某一个节点担任测试，此节点只做测试不对外提供服务
生产环境：直接对外提供服务的环境
为什么有预生产环境？
可能是生产环境预测试环境的数据库或数据库版本不一样导致语句出现问题
或者是生产环境调用的接口不一样，例如支付接口在测试环境无法调用
1.3:设计一套生产环境的代码自动化部署系统：
开发环境 --> 功能测试/性能测试 --> 预生产环境 --> 生产环境
1.4：总体规划流程：
一个服务的集群节点数量，是一次部署还是分次部署
一键回滚到上个版本
一键回滚到任意版本
代码保存在SVN还是Git
获取指定分支或master的指定版本号的代码，svn指定版本号，git指定tag标签，或直接拉取某个分支
配置文件差异化，即测试环境和生产环境的配置文件不一样，如IP不一样或主机名不一样或数据库连接不一样等等
代码仓库和实际的差异，即配置文件是否放在代码仓库中，如果保存在git则所有人都可以从配置文件看到数据库用户密码等信息，可以使用单独分支保存配置文件，或配置文件只在部署服务器的某个项目的目录，比如是config.example
如何更新代码，java tomcat需要重启
测试部署后的web页面是否可以正常访问是否是想要的页面
并行(saltstack)或并行(shell)的问题，涉及到分组部署重启服务
如何执行，shell执行还是web执行
1.5：总体规划如下：
获取代码(git pull拉取) --> 是否编译(java需要编译) --> 配置文件(统一和差异) --> 打包 --> scp到目标服务器(或者用saltstack) --> 将服务器移除集群 --> 解压代码包 --> 放置到目标目录(如webroot) --> scp差异文件 --> 重启服务(可选) --> 测试服务(访问web或者post请求) --> 将节点重新加入集群
二：实现代码自动化部署
2.1:通过shell脚本实现，shell脚本规划如下：
2.1.1：各web服务器添加一个uid相同的普通用户，而且所有的web服务都以此普通用户启动，默认情况下所有的wenb服务除了负载均衡之外都不能监听80端口，比如可以监听8008端口
2.1.2：部署服务器的用户登录其他服务器免密码登录，因此需要做秘钥认证，在各主机执行以下命令：
# useradd www -u 1010
# su – www
$ ssh-keygen
#将部署机www用户的公钥复制到各web服务器的 /home/www/.ssh/authorized_keys或执行ssh-copy-id www@192.168.3.13
$ chmod 600 /home/www/.ssh/authorized_keys
2.1.3:测试部署服务器是否可以免秘钥用www用户登录各个web服务器
2.2：编写shell脚本：
2.2.1：完成框架编写：
#!/bin/bash #shell env SHELL_NAME="deploy.sh" SHELL_DIR="/home/www/" # 脚本路径 SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log" # 脚本执行日志 # code env 代码变量 CODE_DIR="/deploy/code/deploy" # 代码目录 CONFIG_DIR="/deploy/config" # 配置文件目录 TMP_DIR="/deploy/tmp" # 临时目录 TAR_DIR="/deploy/tar" # 打包目录 LOCK_FILE="/tmp/deploy.lock" # 锁文件标示 # 使用帮助函数 usage(){ echo $"Usage: $0 [ deploy | rollback ]" } shell_lock(){ touch ${LOCK_FILE} } shell_unlock(){ rm -f ${LOCK_FILE} } code_get(){ echo "code_get" sleep 60 } code_build(){ echo "code_build" } code_config(){ echo "code_config" } code_tar(){ echo "code_tar" } code_scp(){ echo "code_scp" } cluster_node_remove(){ echo "cluster_node_remove" } code_deploy(){ echo "code_deploy" } config_diff(){ echo "config_diff" } code_test(){ echo "code_test" } cluster_node_in(){ echo "cluste_node_in" } rollback(){ echo "rollback" } # 主函数 main(){ if [ -f $LOCK_FILE ];then # 先判断锁文件在不在 echo "Deploy is running" && exit 10; # 如果有锁文件直接退出 fi DEPLOY_METHOD=$1 # 避免出错误将脚本的第一个参数作为变量 case $DEPLOY_METHOD in deploy) # 如果第一个参数是deploy就执行以下操作 shell_lock; # 执行部署之前创建锁，如果同时有其他人执行则提示锁文件存在避免冲突 code_get; code_build; code_config; code_tar; code_scp; cluster_node_remove; code_deploy; config_diff; code_test; cluster_node_in; shell_unlock; ;; rollback) # 如果第一个参数是rollback就执行以下操作 shell_lock; # 回滚之前也是先创建锁文件 rollback; # 执行完成删除锁文件 shell_unlock; ;; *) # 其他输入执行以下操作 usage; esac } # 执行主函数并把第一个变量当参数 main $1
2.2.2：完成脚本：实现代码部署、测试、回滚等操作：
代码回滚设计：
正常回滚是回滚已经在web服务器部署过的版本，因此就不需要获取代码打包和部署的过程了
列出回滚版本
将模板服务器移除集群
执行回滚
重启和测试
将模板服务器加入集群
#!/bin/bash #Dir List 部署节点(即部署节点需要做的操作) # mkdir -p /deploy/code/web-demo # mkdir -p /deploy/config/web-demo/base # mkdir -p /deploy/config/web-demo/other # mkdir /deploy/tmp # mkdir /deploy/tar # chown -R www.www /deploy # chown -R www.www /webroot # chown -R www.www /opt/webroot/ # chown -R www.www /webroot # 需要在客户端节点做的操作 # mkdir /opt/webroot # mkdir /webroot # chown -R www.www /webroot # chown -R www.www /opt/webroot/ # chown -R www.www /webroot # [www@ ~]$ touch /webroot/web-dem # Node List 服务器节点 PRE_LIST="192.168.3.12" # 预生产节点 GROUP1_LIST="192.168.3.12 192.168.3.13" GROUP2_LIST="192.168.3.13" ROLLBACK_LIST="192.168.3.12 192.168.3.13" # 日志日期和时间变量 LOG_DATE='date "+%Y-%m-%d"' # 如果执行的话后面执行的时间，此时间是不固定的，这是记录日志使用的时间 LOG_TIME='date "+%H-%M-%S"' # 代码打包时间变量 CDATE=$(date "+%Y-%m-%d") # 脚本一旦执行就会取一个固定时间赋值给变量，此时间是固定的 CTIME=$(date +"%H-%M-%S") # shell env 脚本位置等变量 SHELL_NAME="deploy.sh" # 脚本名称 SHELL_DIR="/home/www/" # 脚本路径 SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log" # 脚本执行日志文件路径 # code env 代码变量 PRO_NAME="web-demo" # 项目名称的函数 CODE_DIR="/deploy/code/web-demo" # 从版本管理系统更新的代码目录 CONFIG_DIR="/deploy/config/web-demo" # 保存不同项目的配置文件，一个目录里面就是一个项目的一个配置文件或多个配置文件 TMP_DIR="/deploy/tmp" # 临时目录 TAR_DIR="/deploy/tar" # 打包目录 LOCK_FILE="/tmp/deploy.lock" # 锁文件路径 usage(){ # 使用帮助函数 echo $"Usage: $0 [ deploy | rollback [ list | version ]" } writelog(){ # 写入日志的函数 LOGINFO=$1 # 将参数作为日志输入 echo "${CDATE} ${CTIME} : ${SEHLL_NAME} : ${LOGINFO}" >> ${SHELL_LOG} } # 锁函数 shell_lock(){ touch ${LOCK_FILE} } # 解锁函数 shell_unlock(){ rm -f ${LOCK_FILE} } # 获取代码的函数 code_get(){ echo "code_get" writelog code_get cd $CODE_DIR && echo "git pull" # 进入到代码目录更新代码，此处必须免密码更新，此目录仅用于代码更新不能放其他任何文件 cp -rf ${CODE_DIR} ${TMP_DIR}/ # 临时保存代码并重命名，包名为时间+版本号，准备复制到web服务器 API_VER="123" # 版本号 } code_build(){ # 代码编译函数 echo code_build } code_config(){ # 配置文件函数 writelog code_config /bin/cp -rf ${CONFIG_DIR}/base/* ${TMP_DIR}/"${PRO_NAME}" # 将配置文件放在本机保存配置文件的临时目录，用于暂时保存代码项目 PKG_NAME="${PRO_NAME}"_"$API_VER"_"${CDATE}-${CTIME}" # 定义代码目录名称 cd ${TMP_DIR} && mv ${PRO_NAME} ${PKG_NAME} # 重命名代码文件为web-demo_123-20170629-11-19-10格式 } code_tar(){ # 对代码打包函数 writelog code_tar cd ${TMP_DIR} && tar czf ${PKG_NAME}.tar.gz ${PKG_NAME} writelog "${PKG_NAME}.tar.gz" } code_scp(){ # 代码压缩包scp到客户端的函数 writelog "code_scp" for node in $PRE_LIST;do # 循环服务器节点列表 scp ${TMP_DIR}/${PKG_NAME}.tar.gz $node:/opt/webroot/ # 将压缩后的代码包复制到web服务器的/opt/webroot done for node in $GROUP1_LIST;do # 循环服务器节点列表 scp ${TMP_DIR}/${PKG_NAME}.tar.gz $node:/opt/webroot/ # 将压缩后的代码包复制到web服务器的/opt/webroot done } url_test(){ URL=$1 curl -s --head $URL |grep '200 OK' if [ $? -ne 0 ];then shell_unlock; writelog "test error" && exit; fi } cluster_node_add(){ #将web服务器添加至前端负载 echo cluster_node_add } cluster_node_remove(){ # 将web服务器从集群移除函数(正在部署的时候应该不处理业务) writelog "cluster_node_remove" } pre_deploy(){ writelog "pre_deploy" for node in ${PRE_LIST};do # 循环预生产服务器节点列表 cluster_node_remove ${node} # 部署之前将节点从前端负载删除 echo "pre_deploy, cluster_node_remove ${node}" ssh ${node} "cd /opt/webroot && tar zxf ${PKG_NAME}.tar.gz" #分别到web服务器执行压缩包解压命令 ssh ${node} "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo" # 整个自动化的核心，创建软连接 done } pre_test(){ # 预生产主机测试函数 for node in ${PRE_LIST};do # 循环预生产主机列表 curl -s --head http://${node}:9999/index.html | grep "200 OK" # 测试web界面访问 if [ $? -eq 0 ];then # 如果访问成功 writelog " ${node} Web Test OK!" # 记录日志 echo " ${node} Web Test OK!" cluster_node_add ${node} # 测试成功之后调用添加函数把服务器添加至节点, writelog "pre,${node} add to cluster OK!" # 记录添加服务器到集群的日志 else # 如果访问失败 writelog "${node} test no OK" # 记录日志 echo "${node} test not OK" shell_unlock # 调用删除锁文件函数 break # 结束部署 fi done } group1_deploy(){ # 代码解压部署函数 writelog "group1_code_deploy" for node in ${GROUP1_LIST};do # 循环生产服务器节点列表 cluster_node_remove $node echo "group1, cluster_node_remove $node" ssh ${node} "cd /opt/webroot && tar zxf ${PKG_NAME}.tar.gz" # 分别到各web服务器节点执行压缩包解压命令 ssh ${node} "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo" # 整个自动化的核心，创建软连接 done scp ${CONFIG_DIR}/other/192.168.3.13.server.xml 192.168.3.13:/webroot/web-demo/server.xml # 将差异项目的配置文件scp到此web服务器并以项目结尾 } group1_test(){ # 生产主机测试函数 for node in ${PRE_LIST};do # 循环生产主机列表 curl -s --head http://${node}:9999/index.html | grep "200 OK" #测试web界面访问 if [ $? -eq 0 ];then #如果访问成功 writelog " ${node} Web Test OK!" #记录日志 echo "group1_test,${node} Web Test OK!" cluster_node_add writelog " ${node} add to cluster OK!" #记录将服务器 添加至集群的日志 else #如果访问失败 writelog "${node} test no OK" #记录日志 echo "${node} test no OK" shell_unlock # 调用删除锁文件函数 break # 结束部署 fi done } rollback_fun(){ for node in $ROLLBACK_LIST;do # 循环服务器节点列表 # 注意一定要加"号，否则无法在远程执行命令 ssh $node "rm -f /webroot/web-demo && ln -s /opt/webroot/$1 /webroot/web-demo" # 立即回滚到指定的版本，$1即指定的版本参数 echo "${node} rollback success!" done } rollback(){ # 代码回滚主函数 if [ -z $1 ];then shell_unlock # 删除锁文件 echo "Please input rollback version" && exit 3; fi case $1 in # 把第二个参数做当自己的第一个参数 list) ls -l /opt/webroot/*.tar.gz ;; *) rollback_fun $1 esac } main(){ if [ -f $LOCK_FILE ] ;then # 先判断锁文件在不在,如果有锁文件直接退出 echo "Deploy is running" && exit 10 fi DEPLOY_METHOD=$1 # 避免出错误将脚本的第一个参数作为变量 ROLLBACK_VER=$2 case $DEPLOY_METHOD in deploy) # 如果第一个参数是deploy就执行以下操作 shell_lock; # 执行部署之前创建锁。如果同时有其他人执行则提示锁文件存在 code_get; # 获取代码 code_build; # 如果要编译执行编译函数 code_config; # cp配置文件 code_tar; # 打包 code_scp; # scp到服务器 pre_deploy; # 预生产环境部署 pre_test; # 预生产环境测试 group1_deploy; # 生产环境部署 group1_test; # 生产环境测试 shell_unlock; # 执行完成后删除锁文件 ;; rollback) # 如果第一个参数是rollback就执行以下操作 shell_lock; # 回滚之前也是先创建锁文件 rollback $ROLLBACK_VER; shell_unlock; # 执行完成删除锁文件 ;; *) usage; esac } main $1 $2
3.通过刚才编写的shell脚本将html官网页面部署到nginx中
①将代码上传到部署节点的/deploy/code/web-demo目录中
[www@master web-demo]$ pwd /deploy/code/web-demo [www@master web-demo]$ ll total 20 drwxr-xr-x 6 www www 4096 Jun 6 13:46 assets -rw-r--r-- 1 www www 1150 Jun 6 17:59 favicon.ico drwxr-xr-x 2 www www 4096 Jun 6 15:32 images -rw-r--r-- 1 www www 4323 Jun 6 16:19 index.html
部署节点执行以下操作：
# mkdir -p /deploy/code/web-demo # mkdir -p /deploy/config/web-demo/base # mkdir -p /deploy/config/web-demo/other # mkdir /deploy/tmp # mkdir /deploy/tar # chown -R www.www /deploy # chown -R www.www /webroot # chown -R www.www /opt/webroot/
②需要在客户端做的操作
# 安装nginx
# yum install -y nginx
编辑nginx
vim /etc/nginx/conf.d/cloudeye.conf server { listen 9999; server_name 192.168.3.13; # 实际生产环境中需要填写域名 location / { alias /webroot/web-demo/; # 这个web-demo目录不需要创建，有软链接指向/webroot/web-demo目录 index index.html; } }
创建相关目录并修改权限
mkdir /opt/webroot mkdir /webroot chown -R www.www /webroot chown -R www.www /opt/webroot/ [www@ ~]$ touch /webroot/web-demo
③执行脚本
测试部署：
[www@master ~]$ ./deploy.sh deploy code_get git pull code_build web-demo_123_2017-06-26-12-18-09.tar.gz 100% 1214KB 1.2MB/s 00:00 web-demo_123_2017-06-26-12-18-09.tar.gz 100% 1214KB 1.2MB/s 00:00 web-demo_123_2017-06-26-12-18-09.tar.gz 100% 1214KB 1.2MB/s 00:00 pre_deploy, cluster_node_remove 192.168.3.12 HTTP/1.1 200 OK 192.168.3.12 Web Test OK! cluster_node_add group1, cluster_node_remove 192.168.3.12 group1, cluster_node_remove 192.168.3.13 /deploy/config/web-demo/other/192.168.3.13.server.xml: No such file or directory HTTP/1.1 200 OK group1_test,192.168.3.12 Web Test OK! cluster_node_add
访问客户端，可以看到能够正常访问，说明部署成功
http://192.168.3.13:9999
修改代码，测试回滚效果
[www@master ~]$ vim /deploy/code/web-demo/index.html [www@master ~]$ ./deploy.sh deploy code_get git pull code_build web-demo_123_2017-06-26-12-18-57.tar.gz 100% 1214KB 1.2MB/s 00:00 web-demo_123_2017-06-26-12-18-57.tar.gz 100% 1214KB 1.2MB/s 00:00 web-demo_123_2017-06-26-12-18-57.tar.gz 100% 1214KB 1.2MB/s 00:00 pre_deploy, cluster_node_remove 192.168.3.12 HTTP/1.1 200 OK 192.168.3.12 Web Test OK! cluster_node_add group1, cluster_node_remove 192.168.3.12 group1, cluster_node_remove 192.168.3.13 /deploy/config/web-demo/other/192.168.3.13.server.xml: No such file or directory HTTP/1.1 200 OK group1_test,192.168.3.12 Web Test OK! cluster_node_add [www@master ~]$ ./deploy.sh rollback list -rw-rw-r-- 1 www www 1243347 Jun 26 11:36 /opt/webroot/web-demo_123_2017-06-26-11-36-44.tar.gz -rw-rw-r-- 1 www www 1243347 Jun 26 11:39 /opt/webroot/web-demo_123_2017-06-26-11-39-02.tar.gz -rw-rw-r-- 1 www www 1243351 Jun 26 12:04 /opt/webroot/web-demo_123_2017-06-26-12-04-19.tar.gz -rw-rw-r-- 1 www www 1243347 Jun 26 12:16 /opt/webroot/web-demo_123_2017-06-26-12-16-49.tar.gz -rw-rw-r-- 1 www www 1243347 Jun 26 12:18 /opt/webroot/web-demo_123_2017-06-26-12-18-09.tar.gz -rw-rw-r-- 1 www www 1243369 Jun 26 12:18 /opt/webroot/web-demo_123_2017-06-26-12-18-57.tar.gz
修改部署成功页面
测试回滚，页面再次回到修改前，说明回滚成功
[www@master ~]$ ./deploy.sh rollback web-demo_123_2017-06-26-12-18-09 192.168.3.12 rollback success! 192.168.3.13 rollback success!
###############################################################################
运维与自动化系列④自动化部署基础与git
自动化部署基础与git
一：上一篇的代码是保存在本地，但是在生产环境当中是由版本控制进行代码管理，以便于发布代码和回滚，一般是使用gitlib比较多，另外还有用svn的公司，趋势是git为主，因此本文以git为使用对象
1.1：在git服务器新建一个web组和项目web-demo：
准备web页面并提交至git服务器(此处我用一个简单的html项目，大家如果没有现成的项目可以自己建一个简单的index.html页面即可)：
#准备提交代码目录
# mkdir /source/web/web-demo -p
# 准备一个项目然后提交至git服务器
将项目上传到/source/web/web-demo目录
[www@master web-demo]$ pwd /source/web/web-demo [www@master web-demo]$ ll total 20 drwxr-xr-x 6 www www 4096 Jun 6 13:46 assets -rw-r--r-- 1 www www 1150 Jun 6 17:59 favicon.ico drwxr-xr-x 2 www www 4096 Jun 6 15:32 images -rw-r--r-- 1 www www 4323 Jun 6 16:19 index.html # chown -R www.www /source # su - www cd /source/web git config --global user.name "reblue520" git config --global user.email "reblue520@163.com" git config --global color.ui true cd /source/web/web-demo git init git add * git commit -m 'web-demo all' git remote add origin git@192.168.3.198:web/web-demo.git git push -u origin master # 确认代码提交成功
1.2：使用ssh key授权www用户可以更新和提交代码：
#在admin area–web-demo-profile settings-ssh keys将www用户的公钥放在gitlab的web界面： [www@master ~]$ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArALvWj9fYnDtZxOue7OXvznI02QAyQgeR1SkjnlE3YwZIfjOJU1x2n7jPUxRuPR+wQPRZ9/AQUD5mNzYGLGxXY0Tpjw7zRQ8HFEmZSm4NgMNfYedyHpWbbJLrYTR4vg5pNFtJm7vmZdaV6JP6WLtyDkC83pKK8oOOha8PhNwXKcMMUMjS9NGhbaR0I8cDsgOOo0wAZl8oNGD/6FWc4XsDAfvWLac4a9BUtisn14YZcTqjEwkEv0DxnXZ2yVtGwPNmiPEhdfvyDM6kPtBL0BptWEVWvqD0bBS31Ro8FH3BPWunrgDQA/XAkjhHChF+A0mU+lVYncqjtSG9HsKvMUU1Q== www@master
1.3在部署机准备目录环境：
mkdir -p /deploy/code/web-demo -p mkdir -p /deploy/config/web-demo/base mkdir -p /deploy/config/web-demo/other mkdir -p /deploy/tar mkdir -p /deploy/tmp mkdir -p /opt/webroot mkdir /webroot chown -R www:www /deploy chown -R www:www /opt/webroot chown -R www:www /webroot
# su - www # 切换到www用户 $ rm -rf /deploy/code/web-demo # 删除原目录，改用git仓库管理代码 $ cd /deploy/code/ $ git clone git@192.168.3.198:web/web-demo.git # 克隆后会生成deb-demo目录，里面的代码即我们在1.1中准备的代码
1.4：编辑部署脚本并准备相关目录：
1.4.1：或git提交的代码版本号，用户记录提交的版本，做部署或代码回滚使用：
[www@master web-demo]$ pwd /source/web/web-demo $ git show #获取最近更新的版本信息 [www@master web-demo]$ git show |grep commit | cut -d ' ' -f2 # 只获取版本号 91d09cc28f48803d8795f62d925de70f192daeda [www@master web-demo]$ VERSION_L=$(git show |grep commit | cut -d ' ' -f2) [www@master web-demo]$ echo ${VERSION_L:0:8} # 切片取固定长度 91d09cc2
1.4.3：在各web服务器准备以下目录：
#web服务器操作
# mkdir /opt/webroot #保存代码的目录 # chown www.www /opt/webroot/ -R # mkdir /webroot #生成配置文件的web主目录，下面是项目的工作目录，比如/webroot/web-demo # chown www.www /webroot/ -R $ touch /webroot/web-demo
1.4.4：脚本改造如下，主要实现从git拉取代码再部署至服务器：
#!/bin/bash #Dir List 部署节点(即部署节点需要做的操作) # mkdir -p /deploy/code/web-demo # mkdir -p /deploy/config/web-demo/base # mkdir -p /deploy/config/web-demo/other # mkdir /deploy/tmp # mkdir /deploy/tar # chown -R www.www /deploy # chown -R www.www /webroot # chown -R www.www /opt/webroot/ # chown -R www.www /webroot # 需要在客户端节点做的操作 # mkdir /opt/webroot # mkdir /webroot # chown -R www.www /webroot # chown -R www.www /opt/webroot/ # chown -R www.www /webroot # [www@ ~]$ touch /webroot/web-dem # Node List 服务器节点 PRE_LIST="192.168.3.12" # 预生产节点 GROUP1_LIST="192.168.3.12 192.168.3.13" GROUP2_LIST="192.168.3.13" ROLLBACK_LIST="192.168.3.12 192.168.3.13" # 日志日期和时间变量 LOG_DATE='date "+%Y-%m-%d"' # 如果执行的话后面执行的时间，此时间是不固定的，这是记录日志使用的时间 LOG_TIME='date "+%H-%M-%S"' # 代码打包时间变量 CDATE=$(date "+%Y-%m-%d") # 脚本一旦执行就会取一个固定时间赋值给变量，此时间是固定的 CTIME=$(date +"%H-%M-%S") # shell env 脚本位置等变量 SHELL_NAME="deploy.sh" # 脚本名称 SHELL_DIR="/home/www/" # 脚本路径 SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log" # 脚本执行日志文件路径 # code env 代码变量 PRO_NAME="web-demo" # 项目名称的函数 CODE_DIR="/deploy/code/web-demo" # 从版本管理系统更新的代码目录 CONFIG_DIR="/deploy/config/web-demo" # 保存不同项目的配置文件，一个目录里面就是一个项目的一个配置文件或多个配置文件 TMP_DIR="/deploy/tmp" # 临时目录 TAR_DIR="/deploy/tar" # 打包目录 LOCK_FILE="/tmp/deploy.lock" # 锁文件路径 usage(){ # 使用帮助函数 echo $"Usage: $0 [ deploy | rollback [ list | version ]" } writelog(){ # 写入日志的函数 LOGINFO=$1 # 将参数作为日志输入 echo "${CDATE} ${CTIME} : ${SEHLL_NAME} : ${LOGINFO}" >> ${SHELL_LOG} } # 锁函数 shell_lock(){ touch ${LOCK_FILE} } # 解锁函数 shell_unlock(){ rm -f ${LOCK_FILE} } # 获取代码的函数 code_get(){ echo "code_get" writelog code_get cd $CODE_DIR && git pull # 进入到代码目录更新代码，此处必须免密码更新，此目录仅用于代码更新不能放其他任何文件 cp -rf ${CODE_DIR} ${TMP_DIR}/ # 临时保存代码并重命名，包名为时间+版本号，准备复制到web服务器 API_VERL=$(git show | grep commit | cut -d ' ' -f2) API_VER=$(echo ${API_VERL:0:8}) # 版本号 } code_build(){ # 代码编译函数 echo code_build } code_config(){ # 配置文件函数 writelog "code_config" /bin/cp -rf ${CONFIG_DIR}/base/* ${TMP_DIR}/"${PRO_NAME}" # 将配置文件放在本机保存配置文件的临时目录，用于暂时保存代码项目 PKG_NAME="${PRO_NAME}"_"$API_VER"_"${CDATE}-${CTIME}" # 定义代码目录名称 cd ${TMP_DIR} && mv ${PRO_NAME} ${PKG_NAME} # 重命名代码文件为web-demo_123-20170629-11-19-10格式 } code_tar(){ # 对代码打包函数 writelog code_tar cd ${TMP_DIR} && tar czf ${PKG_NAME}.tar.gz ${PKG_NAME} --exclude=".git" # 将目录打包成压缩文件，便于网络传输 writelog "${PKG_NAME}.tar.gz packaged success" # 记录打包成功的日志 } code_scp(){ # 代码压缩包scp到客户端的函数 writelog "code_scp" for node in $PRE_LIST;do # 循环服务器节点列表 scp ${TMP_DIR}/${PKG_NAME}.tar.gz $node:/opt/webroot/ # 将压缩后的代码包复制到web服务器的/opt/webroot done for node in $GROUP1_LIST;do # 循环服务器节点列表 scp ${TMP_DIR}/${PKG_NAME}.tar.gz $node:/opt/webroot/ # 将压缩后的代码包复制到web服务器的/opt/webroot done } cluster_node_add(){ #将web服务器添加至前端负载 echo cluster_node_add } cluster_node_remove(){ # 将web服务器从集群移除函数(正在部署的时候应该不处理业务) writelog "cluster_node_remove" } url_test(){ URL=$1 curl -s --head $URL |grep '200 OK' if [ $? -ne 0 ];then shell_unlock; writelog "test error" && exit; fi } pre_deploy(){ # 代码解压部署函数,预生产节点 writelog "pre_deploy" for node in ${PRE_LIST};do # 循环预生产服务器节点列表 cluster_node_remove ${node} # 部署之前将节点从前端负载删除 echo "pre_deploy, cluster_node_remove ${node}" ssh ${node} "cd /opt/webroot && tar zxf ${PKG_NAME}.tar.gz" #分别到web服务器执行压缩包解压命令 ssh ${node} "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo" # 整个自动化的核心，创建软连接 done } pre_test(){ # 预生产主机测试函数 for node in ${PRE_LIST};do # 循环预生产主机列表 curl -s --head http://${node}:9999/index.html | grep "200 OK" # 测试web界面访问 if [ $? -eq 0 ];then # 如果访问成功 writelog " ${node} Web Test OK!" # 记录日志 echo " ${node} Web Test OK!" cluster_node_add ${node} # 测试成功之后调用添加函数把服务器添加至节点, writelog "pre,${node} add to cluster OK!" # 记录添加服务器到集群的日志 else # 如果访问失败 writelog "${node} test no OK" # 记录日志 echo "${node} test not OK" shell_unlock # 调用删除锁文件函数 break # 结束部署 fi done } group1_deploy(){ # 代码解压部署函数 writelog "group1_code_deploy" for node in ${GROUP1_LIST};do # 循环生产服务器节点列表 cluster_node_remove $node echo "group1, cluster_node_remove $node" ssh ${node} "cd /opt/webroot && tar zxf ${PKG_NAME}.tar.gz" # 分别到各web服务器节点执行压缩包解压命令 ssh ${node} "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo" # 整个自动化的核心，创建软连接 done scp ${CONFIG_DIR}/other/192.168.3.13.server.xml 192.168.3.13:/webroot/web-demo/server.xml # 将差异项目的配置文件scp到此web服务器并以项目结尾 } group1_test(){ # 生产主机测试函数 for node in ${PRE_LIST};do # 循环生产主机列表 curl -s --head http://${node}:9999/index.html | grep "200 OK" #测试web界面访问 if [ $? -eq 0 ];then #如果访问成功 writelog " ${node} Web Test OK!" #记录日志 echo "group1_test,${node} Web Test OK!" cluster_node_add writelog " ${node} add to cluster OK!" #记录将服务器 添加至集群的日志 else #如果访问失败 writelog "${node} test no OK" #记录日志 echo "${node} test no OK" shell_unlock # 调用删除锁文件函数 break # 结束部署 fi done } rollback_fun(){ for node in $ROLLBACK_LIST;do # 循环服务器节点列表 # 注意一定要加"号，否则无法在远程执行命令 ssh $node "rm -f /webroot/web-demo && ln -s /opt/webroot/$1 /webroot/web-demo" # 立即回滚到指定的版本，$1即指定的版本参数 echo "${node} rollback success!" done } rollback(){ # 代码回滚主函数 if [ -z $1 ];then shell_unlock # 删除锁文件 echo "Please input rollback version" && exit 3; fi case $1 in # 把第二个参数做当自己的第一个参数 list) ls -l /opt/webroot/*.tar.gz ;; *) rollback_fun $1 esac } main(){ if [ -f $LOCK_FILE ] ;then # 先判断锁文件在不在,如果有锁文件直接退出 echo "Deploy is running" && exit 10 fi DEPLOY_METHOD=$1 # 避免出错误将脚本的第一个参数作为变量 ROLLBACK_VER=$2 case $DEPLOY_METHOD in deploy) # 如果第一个参数是deploy就执行以下操作 shell_lock; # 执行部署之前创建锁。如果同时有其他人执行则提示锁文件存在 code_get; # 获取代码 code_build; # 如果要编译执行编译函数 code_config; # cp配置文件 code_tar; # 打包 code_scp; # scp到服务器 pre_deploy; # 预生产环境部署 pre_test; # 预生产环境测试 group1_deploy; # 生产环境部署 group1_test; # 生产环境测试 shell_unlock; # 执行完成后删除锁文件 ;; rollback) # 如果第一个参数是rollback就执行以下操作 shell_lock; # 回滚之前也是先创建锁文件 rollback $ROLLBACK_VER; shell_unlock; # 执行完成删除锁文件 ;; *) usage; esac } main $1 $2
1.5 运行部署脚本：
[www@master ~]$ ./deploy.sh deploy code_get Already up-to-date. code_build web-demo_75463f1b_2017-06-30-15-05-57.tar.gz 100% 1207KB 1.2MB/s 00:00 web-demo_75463f1b_2017-06-30-15-05-57.tar.gz 100% 1207KB 1.2MB/s 00:00 web-demo_75463f1b_2017-06-30-15-05-57.tar.gz 100% 1207KB 1.2MB/s 00:00 pre_deploy, cluster_node_remove 192.168.3.12 HTTP/1.1 200 OK 192.168.3.12 Web Test OK! cluster_node_add group1, cluster_node_remove 192.168.3.12 group1, cluster_node_remove 192.168.3.13 /deploy/config/web-demo/other/192.168.3.13.server.xml: No such file or directory HTTP/1.1 200 OK group1_test,192.168.3.12 Web Test OK! cluster_node_add
1.5.2测试修改代码后能否正常获取最新代码，并部署成功
# 在自己的项目里面修改代码然后提交至git服务器
[www@master web-demo]$ pwd /source/web/web-demo [www@master web-demo]$ vim index.html [www@master web-demo]$ git add "index.html" [www@master web-demo]$ git commit -m "edit index.html add www.chinasoft.com" [master 7886914] edit index.html add www.chinasoft.com 1 file changed, 2 insertions(+), 2 deletions(-) [www@master web-demo]$ git push origin master Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 324 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) To git@192.168.3.198:web/web-demo.git 75463f1..7886914 master -> master
# 再次部署
[www@master ~]$ ./deploy.sh deploy
可以看到客户端已经更新了
http://192.168.3.13:9999/
