We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在去年的一个 PO 里曾简要介绍了使用 Ansible 做应用部署的做法: #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 ......
The text was updated successfully, but these errors were encountered:
No branches or pull requests
重构缘由
在去年的一个 PO 里曾简要介绍了使用 Ansible 做应用部署的做法: #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):
The text was updated successfully, but these errors were encountered: