1. 场景
持续部署：业界没有统一明确地定义，简单理解为将集成结果部署到不同的环境供用户使用，并且立即反馈部署结果的实践，其中不同的环境包括：开发环境、测试环境、预发布环境、生产环境
持续部署两个核心要素：持续、自动化，自动化是持续的基础
持续部署的需求场景：
-
需要频繁的发布更新
-
部署规模较大，人工操作费时费力易出错
-
规范化上线部署流程和配置规范
注：此处只讨论应用部署，不包括系统部署
2. 实践
-
开发提交代码到Git仓库
-
自动或手动触发持续集成，执行编译、打包、单元测试、代码扫描等过程，并构建出可部署的程序文件，上传测试的SVN库
-
测试人员手动触发Jenkins调用Rundeck从测试的SVN库中获取部署文件并部署到测试环境
-
测试人员进行产品验证
-
测试人员在验证通过后，申请发布到生产环境，并手动触发Jenkins，将测试的SVN库中的部署文件上传到运维的SVN库
-
运维人员触发Rundeck，从运维的SVN库中获取部署文件并更新到生产环境
注：
-
集群的部署采用分步更新，先发布到线上集群里的某一个节点进行更新测试，测试通过后把这个节点加入集群，再更新其他节点
-
发布成果的版本采用时间戳的形式
3. 工具
3.1 工具箱
-
Jenkins：用作发布任务的触发，实现发布的持续化
-
SVN：发布成果的版本管理工具，实现发布内容的可追踪、易回滚
-
Rundeck：用Java/Grails实现的开源自动化部署工具，帮助用户在数据中心或者云环境中自动化各种操作和流程。通过命令行或者web界面，用户可以对任意数量的服务器进行远程操作，大大降低了对服务器自动化的门槛。
3.2 Rundeck功能
-
提供Web界面和命令行来执行shell命令和job
-
工作流，自定义job步骤
-
设置shell命令/job运行周期（类似cron table的功能）
-
用户权限控制，支持LDAP/ActiveDirectory
-
保存历史日志
-
提供Web API
通过以上功能，Rundeck可以在任意数量的服务器上批量执行不同的任务，降低对自动化的部署、执行、维护的工作难度。
3.3 Rundeck架构
3.4 Rundeck典型使用场景
-
标准化服务器操作过程
通过Rundeck定义日常标准的服务器操作过程，对服务器的操作通过Rundeck进行，便于权限控制、可视化与审计
-
任务调度
通过Rundeck实现任务的自动调度
-
-
自动化部署
通过持续集成系统调用Rundeck实现不同环境的自动化部署和部署验证
-
-
自助化测试环境
通过Rundeck可以为开发和测试提供自助化的测试环境，很方便基于不同版本的构件进行部署
-
-
基于Rundeck的API和插件机制构建运维平台
-
3.5 Rundeck安装配置
1. 安装
首先确认已经安装了jdk
-
<span class="s1" style="font-family: 微软雅黑; line-height: 1.5;"> rpm -Uvh http://repo.rundeck.org/latest.rpm </span>
-
<span style="font-family: 微软雅黑; line-height: 1.5;">yum install rundec</span><span style="font-family: 微软雅黑; line-height: 1.5; background-color: rgb(255, 255, 255);">k</span>
复制代码
2.配置
在mysql数据库创建数据库rundeck,和对rundeck有所有权限的用户rundeckuse/rundeckpassword
修改文件/etc/rundeck/rundeck-config.properties文件：
-
<span style="font-family: 微软雅黑; line-height: 1.5;"> grails.serverURL=http://该服务器IP地址:4440</span>
-
-
<span style="font-family: 微软雅黑; line-height: 1.5;">dataSource.dbCreate = update</span>
-
-
<span style="font-family: 微软雅黑; line-height: 1.5;">dataSource.url=jdbc:mysql://ip/rundeck?autoReconnect=true&useUnicode=yes&characterEncoding=UTF8</span>
-
-
<span style="font-family: 微软雅黑; line-height: 1.5;">dataSource.username = rundeckuser</span>
-
-
<span style="font-family: 微软雅黑; line-height: 1.5;">dataSource.password = rundeckpass</span><span style="font-family: 微软雅黑; line-height: 1.5; background-color: rgb(255, 255, 255);">word</span>
复制代码
启动rundeck
4. 效果
-
提升应用变更效率，包括速率和成功率
-
实现部署自助化，开发、测试均可完成相应环境的发布
5. 其他
5.1 自动化部署工具对比
自动化部署工具种类繁多，各有千秋，根据团队实际需求和工具特性选择适合当前阶段的工具，避免过多追求新特性导致陡峭的学习曲线，避免对当前环境造成过多的侵入，在非生产环境进行充分的验证。下面就常见的自动化部署工具进行简单比较：
|
工具
|
开发语言
|
交互方式
|
支持OS
|
有无Agent
|
发布时间
|
场景
|
备注
|
|
Puppet
|
Ruby
|
Web UI/CLI
|
Unix/Linux/Windows
|
有
|
2005年
|
基础配置文件管理
|
配套工具：foreman
|
|
Chef
|
Ruby
|
Web UI/CLI
|
Unix/Linux/Windows
|
有
|
2009年
|
基础配置文件管理
|
|
|
Rundeck
|
Java
|
Web UI/CLI
|
Unix/Linux/Windows
|
无
|
2010年
|
代码批量发布
|
|
|
SaltStack
|
Python
|
Web UI/CLI
|
Unix/Linux/Windows
|
有
|
2011年
|
基础配置文件管理
|
|
|
Ansible
|
Python
|
Web UI/CLI
|
Linux/Windows
|
无
|
2012年
|
基础配置文件管理和命令批量操作
|
|
Puppet：当前的主流工具，重量级，容易上手，扩展性强，但配置复杂，对管理员要求较高，需具备一定编程能力，
Chef：功能和成熟度稍逊于Puppet，重量级，设计原则是基础设施即代码，专注连接开发与运维
SaltStack：轻量级，有Agent但不是必须使用，采用ssh协议，Web界面功能稍弱，适合运维人员使用，支持去中心化
Ansible：轻量级，采用ssh协议，WebUI收费，支持YAML/JSON,容易上手，扩展性强，注重运维，支持推拉两种模式，擅长应用部署，任务编排
服务器规模非常大，影响文件推送或下拉效率，建议参考Twitter的部署工具Murder,其基于BitTorrent技术实现P2P下载，大大提高了文件推送或下拉效率
5.2 Ansible基本介绍
-
简介
Ansible是一款简单的自动化运维工具，重点解决自动化应用部署、自动化配置管理、自动化云服务管理。简单理解Ansible是一款批量的在远程服务器上执行命令的工具，支持Linux各个发行版和Windows系统。Ansible的两种使用方式：Ad-hoc和Playbooks。
-
工作原理
Ansible会根据命令或者playbook生成shell或者python脚本，并推送到远程服务器上执行，然后自动删除shell，和其他自动化部署工具类似，都是批量的在远程服务器上执行命令。
Ansible支持Push和Pull两种模式，Push即由Ansible管理端推送脚本到远程服务器上执行，Pull则为远程服务器主动到Ansible管理端拉取脚本执行。
-
Ansible内部使用手册
根据官文档和实战案例编写的内部使用手册，该手册会进行持续更新
5.3 其他问题
-
为何采用SVN管理上线成果，而不采用Git？
A:上线成果一般为二进制文件，使用Git存储和传输时不会压缩文件，存储资源消耗大，且SVN使用简单，适合成果的版本管理
-
Rundeck交流QQ群：339569912
-
Rundeck官方文档
-
Puppet适合部署操作系统软件，中间件等
-
使用SVN部署时，不使用svn update命令更新代码，而是使用export方式，避免引入.svn目录
同学们，欢迎大家留言讨论，陆续还有更多的湿货+干货，大家回复越多，楼主更新越快
|
