Nebula Graph 的 Ansible 實踐

本文首發於 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 的 Ansible 實踐

背景

Ansible 介紹

特點

部署邏輯

任務邏輯

模塊定製

自定義 filter

自定義 module

Nebula Graph 的 Ansible 實踐

使用通用的 role

使用 vars_prompt 結束 playbook

推薦閱讀

apisix~helm方式的部署到k8s

firmeye - IoT固件漏洞挖掘工具

讓服務器用ssh客戶端的網絡上網

Linux系統中的文件和目錄權限

dolphinscheduler 之變量篇

數倉安全：數據脫敏技術深度解析

dump 內存溢出分析

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結