Open abbshr opened 6 years ago
在去年的一个 PO 里曾简要介绍了使用 Ansible 做应用部署的做法: https://github.com/abbshr/abbshr.github.io/issues/57, 但是随着对 ansible 的了解, 一些灵活而简单的管理思路才逐渐被揭示, 比如说我们要谈的版本控制机制. 最初使用 ansible 时, 由于缺乏了解和使用经验, 完全凭借自己的推测和 shell 脚本以一种丑陋的方式去实现我们需要的功能, 显然我们达到了目的, 但是其流程之复杂, 代码结构之混乱, 导致我们每次更新或者应用到新的项目时很难做到一键化完成, 并且每次手动修改往往会导致出现莫名其妙的诡异问题. 因此这套系统常常被组内成员(包括自己在内..)所诟病. 借此重构机会, 我们将发挥 ansible 的优势: flexible, simple. 以 ansible 的设计哲学重新实现我们的应用发布的管理体系.
出于历史和某些其它原因, 有些服务的发布基本流程是不变的, 比如我们仍然使用代理机到目标机的同步方式.
在实践过程中我们发现, 除了从 git repository 同步代码之外, 代理机仅仅做了模拟 container 的标准化目录结构搭建, 并且每个项目都是基本相同的, 为了实现通用化的部署方式, 这里将对代理机的操作剥离出来, 形成一个共享的 roles: upyun-dev.node_app_deployment, 其中完成了如下任务:
upyun-dev.node_app_deployment
npm i
npm i -S @upyun/pm2
npm prune
接下来就把流程交给另外的一个 roles: upyun-dev.deploy. 它的过程这里不细说了就是用 rsync 同步代码并发布新版本, 整个流程经过简化详见 github 上的源码. 至于回滚, 仍然使用之前的 roles: upyun-dev.rollback, 但是也经过了重构精简化. 这次的重构解决了部署流程的混乱问题, 防止了发版过程以及回滚过程的不确定问题产生, 同时解决了依赖安装速度的问题.
upyun-dev.deploy
upyun-dev.rollback
那么如何使用这三个 roles 呢? 考虑到有些过程可能涉及到项目相关的对象, 因此将 upyun-dev.node_app_deployment 放到了公司内网的 gitlab 仓库, 另外的两个是可以公开使用的, 因此开放到了 github 上, 他们都是可以通过 ansible-galaxy 工具安装获取的.
deploy/requirements.yml
requirements.yml 文件类似 package.json, 是 ansible-galaxy 的依赖配置, 其中描述了playbook 依赖哪些 roles:
# requirements.yml - src: upyun-dev.deploy - src: upyun-dev.rollback - src: git+ssh://gitlab@gitlab.com/upyun-dev/node_app_deployment.git version: master name: upyun-dev.node_app_deployment
定义好 requirements.yml 之后我们可以通过 ansible-galaxy 安装其中的依赖 roles:
ansible-galaxy -r install requirements.yml
为了尽量减少对现有 roles 的修改, roles/proxy 可以保留, 但是需要至少增加 meta 目录, 并且在确定没有额外操作流程时删除 tasks 目录.
meta
# meta/main.yml dependencies: - role: upyun-dev.node_app_deployment
proxy role 的 meta 中可以定义它的依赖 roles, 像上面那样. 在主 playbook 中, node role 可以不用做任何更改(除了修改一下依赖的 role name):
# site.yml ...... roles: - node - upyun-dev.deploy ......
重构缘由
在去年的一个 PO 里曾简要介绍了使用 Ansible 做应用部署的做法: https://github.com/abbshr/abbshr.github.io/issues/57, 但是随着对 ansible 的了解, 一些灵活而简单的管理思路才逐渐被揭示, 比如说我们要谈的版本控制机制. 最初使用 ansible 时, 由于缺乏了解和使用经验, 完全凭借自己的推测和 shell 脚本以一种丑陋的方式去实现我们需要的功能, 显然我们达到了目的, 但是其流程之复杂, 代码结构之混乱, 导致我们每次更新或者应用到新的项目时很难做到一键化完成, 并且每次手动修改往往会导致出现莫名其妙的诡异问题. 因此这套系统常常被组内成员(包括自己在内..)所诟病. 借此重构机会, 我们将发挥 ansible 的优势: flexible, simple. 以 ansible 的设计哲学重新实现我们的应用发布的管理体系.
出于历史和某些其它原因, 有些服务的发布基本流程是不变的, 比如我们仍然使用代理机到目标机的同步方式.
Roles 化
在实践过程中我们发现, 除了从 git repository 同步代码之外, 代理机仅仅做了模拟 container 的标准化目录结构搭建, 并且每个项目都是基本相同的, 为了实现通用化的部署方式, 这里将对代理机的操作剥离出来, 形成一个共享的 roles:
upyun-dev.node_app_deployment
, 其中完成了如下任务:npm i
; 否则创建 package.json, 并执行npm i -S @upyun/pm2
.npm prune
npm i
接下来就把流程交给另外的一个 roles:
upyun-dev.deploy
. 它的过程这里不细说了就是用 rsync 同步代码并发布新版本, 整个流程经过简化详见 github 上的源码. 至于回滚, 仍然使用之前的 roles:upyun-dev.rollback
, 但是也经过了重构精简化. 这次的重构解决了部署流程的混乱问题, 防止了发版过程以及回滚过程的不确定问题产生, 同时解决了依赖安装速度的问题.那么如何使用这三个 roles 呢?
考虑到有些过程可能涉及到项目相关的对象, 因此将
upyun-dev.node_app_deployment
放到了公司内网的 gitlab 仓库, 另外的两个是可以公开使用的, 因此开放到了 github 上, 他们都是可以通过 ansible-galaxy 工具安装获取的.在项目中如何使用
创建
deploy/requirements.yml
文件requirements.yml 文件类似 package.json, 是 ansible-galaxy 的依赖配置, 其中描述了playbook 依赖哪些 roles:
安装依赖
定义好 requirements.yml 之后我们可以通过 ansible-galaxy 安装其中的依赖 roles:
playbook 中使用
为了尽量减少对现有 roles 的修改, roles/proxy 可以保留, 但是需要至少增加
meta
目录, 并且在确定没有额外操作流程时删除 tasks 目录.proxy role 的 meta 中可以定义它的依赖 roles, 像上面那样. 在主 playbook 中, node role 可以不用做任何更改(除了修改一下依赖的 role name):