共计 4629 个字符,预计需要花费 12 分钟才能阅读完成。
本文首发于 Nebula Graph 公众号 NebulaGraphCommunity,Follow & 看大厂图数据库技术实际
背景
在 Nebula-Graph 的日常测试中,咱们会常常在服务器上部署 Nebula-Graph。为了提高效率,咱们须要一种工具,能帮咱们做到疾速部署,次要的需要:
- 能够应用非 root 账户部署 Nebula Graph,这样咱们能够针对这个用户设置 cgroup 做资源限度。
- 能够在操作机上更改配置文件,而后散发到部署的集群上,不便咱们做各种调参的测试。
- 能够应用脚本调用,不便当前咱们继承在测试的平台或工具上。
工具抉择上,晚期有 Fabric 和 Puppet,比拟新的工具有 Ansible 和 SaltStack。
Ansible 在 GitHub 上有 40K+ star,而且在 2015 年被 Red Hat 收买,社区比拟沉闷。很多开源我的项目都提供了 Ansible 的部署形式,比方 Kubernetes 中的 kubespray 和 TiDB 中的 tidb-ansible。
综合下来,咱们应用 Ansible 来部署 Nebula Graph。
Ansible 介绍
特点
Ansible 是开源的,自动化部署工具(Ansible Tower 是商业的)。具备以下的几个特点:
- 默认协定是基于 SSH,相比于 SaltStack 不 须要额定部署 agent。
- 应用 playbook, role, module 来定义部署过程,比拟灵便。
- 操作行为幂等。
- 模块化开发,模块比拟丰盛。
优缺点比拟显著
- 应用 SSH 协定,长处是大多数机器默认只有有账号密码就能够通过 Ansible 实现部署,而毛病性能上会差一些。
- 应用 playbook 来定义部署过程,Python 的 Jinja2 作为模板渲染引擎,对于相熟的人来说会比拟不便,而对于没有应用过的人,会减少学习老本。
综上,实用于小批量机器的批量部署,不须要关怀额定部署 agent 的场景,和咱们的需要比拟匹配。
部署逻辑
通常为了离线部署,能够把机器分为 3 种角色。
- Ansible 执行机 :运行 Ansible 的机器,须要能通过 SSH 连到所有机器。
- 有外网的资源机 :运行须要连贯外网的工作,比方下载 RPM 包。
- 服务器 :即运行服务的服务器,能够网络隔离,通过执行机来部署
工作逻辑
Ansible 中,次要有三种档次的工作:
- Module
- Role
- Playbook
Module 分为 CoreModule 和 CustomerModule,是 Ansible 工作的根本单元。
在运行工作的时候,首先 Ansible 会依据 module 的代码,将参数代入,生成一个新的 Python 文件,通过 SSH 放到近程的 tmp 文件夹,而后通过 SSH 近程执行 Python 将输入后果返回,最初把近程目录删除。
# 设置不删除 tmp 文件
export ANSIBLE_KEEP_REMOTE_FILES=1
# -vvv 查看 debug 信息
ansible -m ping all -vvv
<192.168.8.147> SSH: EXEC ssh -o ControlMaster=auto -o ControlPersist=30m -o ConnectionAttempts=100 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="nebula"'-o ConnectTimeout=10 -o ControlPath=/home/vesoft/.ansible/cp/d94660cf0d -tt 192.168.8.147'/bin/sh -c '"'"'/usr/bin/python /home/nebula/.ansible/tmp/ansible-tmp-1618982672.9659252-5332-61577192045877/AnsiballZ_ping.py && sleep 0'"'"''
能够看到有这样的日志输入,AnsiballZ_ping.py 就是依据 module 生成的 Python 文件,能够登录到那台机器,执行 Python 语句看一下后果。
python3 AnsiballZ_ping.py
#{"ping": "pong", "invocation": {"module_args": {"data": "pong"}}}
返回了运行 Python 文件的规范输入,而后 Ansible 再对返回的后果做额定解决。
Role 是串联 module 的一系列工作,能够通过 register 来传递上下文参数。
典型例子:
- 创立目录
- 如果创立目录胜利,持续装置,否则退出整个部署工程。
Playbook 是组织部署机器和 role 之间的关联。
通过在 inventory 对不同机器进行分组,对不同分组应用不同的 role 来部署,实现非常灵活的装置部署工作。
当 playbook 定义好之后,不同的环境,只有变更 inventory 中的机器配置,就能够实现一样的部署过程。
模块定制
自定义 filter
Ansible 应用 Jinja2 作为模板渲染引擎,能够用 Jinja2 自带的 filter,比方
# 应用 default filter,默认输入 5
ansible -m debug -a 'msg={{hello | default(5) }}' all
有时候,咱们会须要自定义的 filter 来操作变量,典型的场景就是 nebula-metad 的 地址 --meta_server_addrs
。
- 当只有 1 个 metad 的时候,格局是
metad1:9559
, - 当有 3 个 metad 的时候,格局是
metad1:9559,metad2:9559,metad3:9559
在 ansible playbook 的工程下,新建 filter_plugins 目录,创立一个 map_fomat.py Python 文件,文件内容:
# -*- encoding: utf-8 -*-
from jinja2.utils import soft_unicode
def map_format(value, pattern):
"""e.g."{{groups['metad']|map('map_format', '%s:9559')|join(',') }}""""
return soft_unicode(pattern) % (value)
class FilterModule(object):
"""jinja2 filters"""
def filters(self):
return {'map_format': map_format,}
{{groups['metad']|map('map_format', '%s:9559')|join(',') }}
即为咱们想要的值。
自定义 module
自定义 module 须要合乎 Ansible 框架的格局,包含获取参数,规范返回,谬误返回等。
写好的自定义 module,须要在 ansible.cfg 中配置 ANSIBLE_LIBRARY,让 ansible 可能获取到。
具体参考官网:https://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html
Nebula Graph 的 Ansible 实际
因为 Nebula Graph 自身启动并不简单,应用 Ansible 来实现 Nebula-Graph 的部署非常简略。
- 下载 RPM 包。
- 复制 RPM 包到部署机,解压后,放到目标文件夹。
- 更新配置文件。
- 通过 shell 启动。
应用通用的 role
Nebula Graph 有三个组件,graphd、metad、storaged,三个组件的命名和启动应用一样的格局,能够应用通用的 role,graphd、metad、storaged 别离援用通用的 role。
一方面更容易保护,另一方面部署的服务更有细粒度。比方 A B C 机器部署 storaged, 只有 C 机器部署 graphd,那 A B 机器上,就不会有 graphd 的配置文件。
# 通用的 role, 应用变量 install/task/main.yml
- name: config {{module}}.conf
template:
src: "{{playbook_dir}}/templates/{{module}}.conf.j2"
dest: "{{deploy_dir}}/etc/{{module}}.conf"
# graphd role,将变量传进来 nebula-graphd/task/main.yml
- name: install graphd
include_role:
name: install
vars:
module: nebula-graphd
在 playbook 中,graphd 的机器组来运行 graphd 的 role,如果 A B 不在 graphd 的机器组,就不会将 graphd 的配置文件上传。
这样部署后,就不能应用 Nebula-Graph 的 nebula.service start all 来全副启动,因为有的机器上会没有 nebula-graphd.conf 的配置文件。相似的,能够在 playbook 中,通过参数,来指定不同的机器组,传不同的参数。
# playbook start.yml
- hosts: metad
roles:
- op
vars:
- module: metad
- op: start
- hosts: storaged
roles:
- op
vars:
- module: storaged
- op: start
- hosts: graphd
roles:
- op
vars:
- module: graphd
- op: start
这样会相当于屡次 ssh 去执行启动脚本,尽管执行效率没有 start all 更好,然而服务的启停会更为灵便。
应用 vars_prompt 完结 playbook
当只想更新二进制,不想删除数据目录的时候,
能够在 remove 的 playbook 中,增加 vars_prompt 二次确认,如果二次确认了,才会删除数据,否则会退出 playbook。
# playbook remove.yml
- hosts: all
vars_prompt:
- name: confirmed
prompt: "Are you sure you want to remove the Nebula-Graph? Will delete binary only (yes/no)"
roles:
- remove
而在 role 里,会校验二次确认的值
# remove/task/main.yml
---
- name: Information
debug:
msg: "Must input'yes', abort the playbook"
when:
- confirmed != 'yes'
- meta: end_play
when:
- confirmed != 'yes
成果如图,删除时能够二次确认,如果不为 yes,就会勾销执行这次的 playbook,这样能够只删除二进制,而不删除 nebula 集群的数据。
交换图数据库技术?退出 Nebula 交换群请先填写下你的 Nebulae 名片,Nebula 小助手会拉你进群~~
举荐浏览
- 【百亿级图数据在快手平安情报的利用与挑战】
- 【美团图数据库平台建设及业务实际】
- 【Nebula Graph 在微众银行数据治理的实际】
- 【图数据库选型 | 360 数科的图数据库迁徙史】