自动化运维之应用发布---应用下线
2018-09-04 17:48
543 查看
应用发布简单的流程:
1.集群节点应用下线(下面会介绍为什么将这个放在第一位.)
2.获取最新代码
3.编译打包
4.推送到应用机器
5.差异复制
6.重启
7.测试
8.加入集群
我公司都是使用nginx完成负载均衡的...当我们后端应用python,java,nodejs需要升级上线新的功能的时候,就会涉及到nginx的upstream的变动。之所以将应用下线放在的第一位,是因为nginx在去掉upstream节点的时候正在处理的应用连接是不会中断还能正常的服务,我们需要预留更长的时间来等待应用结束。。所以将下线放在第一位(当然如是单节点肯定不能放第一位)。
以前上线的时候,都是人工修改之后reload然后等待应用处理释放。。再去更新代码的。。等一切都是人工的去完成的,几乎每天都需要重复性的工作。后来开始借助jenkins完成发布过程。前期的时候都是直接不下线应用直接部署,后来出现过几次问题,决定在升级应用之前先将nginx负载节点下。为此编写了一个nginx online offline脚本。现在分享给大家。
使用方法 sh scrips.sh online webapp1:8833 脚本内容很简单的。其中需要修改的好似 web_upstream的位置。
然后在自动化发布之前执行此脚本的,然后发布应用,进行测试,测试通过之后上线。
1.集群节点应用下线(下面会介绍为什么将这个放在第一位.)
2.获取最新代码
3.编译打包
4.推送到应用机器
5.差异复制
6.重启
7.测试
8.加入集群
我公司都是使用nginx完成负载均衡的...当我们后端应用python,java,nodejs需要升级上线新的功能的时候,就会涉及到nginx的upstream的变动。之所以将应用下线放在的第一位,是因为nginx在去掉upstream节点的时候正在处理的应用连接是不会中断还能正常的服务,我们需要预留更长的时间来等待应用结束。。所以将下线放在第一位(当然如是单节点肯定不能放第一位)。
以前上线的时候,都是人工修改之后reload然后等待应用处理释放。。再去更新代码的。。等一切都是人工的去完成的,几乎每天都需要重复性的工作。后来开始借助jenkins完成发布过程。前期的时候都是直接不下线应用直接部署,后来出现过几次问题,决定在升级应用之前先将nginx负载节点下。为此编写了一个nginx online offline脚本。现在分享给大家。
#!/bin/sh #================================================================ # Copyright (C) 2018 Sangfor Ltd. All rights reserved. # # 文件名称:reload_upstream.sh # 创 建 者:YouShumin # 创建日期:2018年09月04日 # 描 述: # #================================================================ CONFIG=/data/etc/nginx/conf/web_upstream.conf CHANGE_HOST="$2" Coler_Text(){ echo -e "\e[0;$2m$1\e[0m" } Echo_Red(){ echo $(Coler_Text "$1" "31") } #### 检测修改前的状态 #### ChangeNum(){ online_num=$(grpe -rn ${CHANGE_HOST} ${CONFIG} | grep -v "#" | wc -l) offline_num=$(grep -rn ${CHANGE_HOST} ${CONFIG} | grep "#" |wc -l) } OnLine(){ sed -i "/${CHANGE_HOST}/s/^#//g" ${CONFIG} now_online_num=$(grep -rn ${CHANGE_HOST} ${CONFIG} | grep -v "#" | wc -l) if [ ${OnLine} != ${now_online_num} ];then Echo_Red "Online ${CHANGE_HOST} ok..." else Echo_Red "Online ${CHANGE_HOST} error!!!" fi } OffLine(){ sed -i "/${CHANGE_HOST}/s/^/#/g" ${CONFIG} now_offline_num=$(grep -rn ${CHANGE_HOST} ${CONFIG} | grep "#" |wc -l) if [ ${OffLine} != ${now_offline_num} ];then Echo_Red "OffLine ${CHANGE_HOST} ok..." else Echo_Red "OffLine ${CHANGE_HOST} error!!!!" fi } __init__(){ case $1 in online) ChangeNum OnLine ;; offline) ChangeNum OffLine ;; *) echo "Usage: $0 {[ online|offline ] [server:port]}" exit 1 ;; esac } __init__ $1
使用方法 sh scrips.sh online webapp1:8833 脚本内容很简单的。其中需要修改的好似 web_upstream的位置。
然后在自动化发布之前执行此脚本的,然后发布应用,进行测试,测试通过之后上线。
相关文章推荐
- linux运维自动化之puppet简单应用(二)
- 自动化运维神器之saltstack (五)salt-ssh的应用场景
- linux运维自动化之puppet简单应用(一)
- 自动化运维平台puppet的高级应用
- 运维自动化发布系统
- 自动化运维之Ansible应用基础模块(超详细)
- 容易的linux自动化运维工具之安装部署和应用实例(四)
- Linux下Docker对Web应用的自动化打包和发布,以及.tar文件的导出,常用操作命令大全(收藏)!!!
- 运维自动化--代码发布平台
- 自动化运维工具Ansible架构部署应用及playbooks简单应用
- 自动化运维实践技巧:简单4步完成自动化构建发布
- 远程服务器部署应用(一)--传统部署方式还是自动化运维工具部署?
- 自动化运维工具ansible基础应用
- 运维之系统服务篇------2.linux扩展应用 、 vim编辑技巧 、 发布网络YUM源 、 源码编译安装
- 自动化运维工具之Zabbix服务器监控基本应用详解(一)
- 手游公司运维之利用Rundeck自动化运维工具和Shell脚本构建测试环境代码发布平台和生产环境代码发布平台
- “运维厨房”把应用运维自动化,想要做服务器版的App Store
- 企业级自动化运维工具应用实战-ansible
- 自动化运维工具之Zabbix分布式监控应用(五)