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目录
同学们，欢迎大家留言讨论，陆续还有更多的湿货+干货，大家回复越多，楼主更新越快
| 
