社群投稿|小團隊如何妙用 JuiceFS

語言: CN / TW / HK

早些年還在 ENJOY 的時候, 就已經在用 JuiceFS, 並且一路伴隨著我工作過的四家小公司, 這玩意對我來說, 已經成了理所應當不可或缺的基礎設施, 對於我服務過的小團隊而言, 更是實實在在的好幫手. 趁著最近的徵文活動, 繼續拓展一下我的小團隊系列, 介紹下多年來我們團隊都在如何使用 JuiceFS .

不過這裡講到的用途, 恐怕都不算什麼"妙用", JuiceFS 是一個大社群了, 這些用法恐怕早被玩的滾瓜爛熟, 不過無妨, 本文其實是內部專案文件的拓展, 主要記錄一些維護過程的心得體會.

妙用: 容器共享儲存

雖然已經有了 CSI 支援 [1] , 但我們一直以來都將 JuiceFS 掛載到所有 Kubernetes 節點的  /jfs , 這樣一來, 所有容器應用都能輕鬆以  hostPath 方式來掛載宿主機目錄, 然後就有了共享儲存了. 此法的一些需要注意的地方:

  • jfs.mount 必須先於容器服務啟動, 畢竟二者建立依賴關係了. 以 docker 為例, 可以這麼寫:

# /etc/systemd/system/docker.service.d/12-after-jfs.conf
[Unit]
After=jfs.mount
  • • 要掛載的目錄必須先手動創建出來, 設定好許可權(使之與容器程序 uid 匹配), 這點其實不太方便, 如果你的團隊受不了這番折騰, 就直接用 CSI 吧.

  • • 叢集擴容存在一定不便之處, 畢竟此法要求所有節點都掛載好 JuiceFS . 萬一 Kubernetes 叢集冗餘不夠了, 需要加入新節點, 還需要多做一步掛載 JuiceFS , 才能加入叢集. 在極限情況下, 這樣的設計還挺耽誤時間的, 又多了一個直接用 CSI 的理由.

講了這麼多問題, 那看上去確實應該首選 CSI 而不是 hostPath 了, 不過  hostPath 就勝在管理更簡單, 推理更加直白, 因為依照我們的使用慣例, 都會採用類似  /jfs/[appname]-[cluster] 的命名, 比較一目瞭然, 對於不熟悉 Kubernetes PV 那一套的同事而言, 做事情也更加方便一些.

妙用: 網盤

有了一個隨心所欲存檔案的地方, 自然而然的念頭就是如何方便地把檔案分享出去. 大家都知道 JuiceFS 是可以在各個平臺掛載的 (甚至 Windows 上也很好用了), 但這並不是我要介紹的, 因為讓使用者各自在本地掛載 jfs, 操作難度很大(何況還有安全問題). 我的意思是你可以簡單搭建一個 web 服務, 掛載 JuiceFS , 然後將檔案暴露出下載入口.

做這件事真的特別簡單, 我當時從萌生想法到搭建完畢不過 5 分鐘, 多虧了 lain [2] , 只需要這樣一份簡短的  values.yaml , 就能用 Python 拉起來  http.server :

appname: jfs-http-server



volumes:

- name: jfs-data

hostPath:

path: "/jfs"

type: Directory



volumeMounts:

- name: jfs-data

mountPath: /jfs



deployments:

web:

replicaCount: 1

image: python:latest

podSecurityContext: {}

resources:

limits:

cpu: 1000m

memory: 80M

requests:

cpu: 10m

memory: 80M

command: ["python", '-m', 'http.server']

workingDir: /jfs

containerPort: 8000



ingresses:

- host: jfs

deployName: web

paths:

- /

稍有開發經驗的人就能看明白, 這是用社群的 python:latest 映象, 執行  http.server , 然後掛載了宿主機的  /jfs 目錄. 服務上線以後, 訪問  jfs.example.com 就能瀏覽和下載 jfs 下的所有檔案了.

相比 jfs, 這一節似乎更是在給 lain 做廣告, 不過在 DevOps 的世界裡, 好用的東西總會互相吸引, 如果各位的團隊也實行 DevOps, 歡迎參考 lain [3] .

妙用: 在 JupyterLab 進行 ad hoc 程式設計

我們團隊經常要和資料打交道, 不僅是做資料報表, 視覺化分析, 有時也希望在能摸到資料的地方驗證一些開發思路. 總不能讓大家都本地連線線上資料庫吧, 既不方便也不安全, 大夥也不一定都擅長在本地折騰這方面的工具. 因此我部署了 JupyterLab [4] , 在裡邊做了大量易用性改善, 也就是內建了很多公司內部資料庫的快捷方式, 讓所有開發者/資料工程師都能便捷地使用封裝好的 Python 庫來做資料分析, 甚至直接利用  bokeh [5] 來交付資料視覺化的工作.

顯而易見, 在 Jupyter 裡寫的程式碼也是要進入版本管理的, 辛苦寫的程式碼可千萬不能丟了. 因此我直接將 JupyterLab 的工作目錄設定為 JuiceFS , 所有的 notebook 就都存放於 JuiceFS 下了. 用 lain 部署 JupyterLab 十分簡單, 下面就是用到的  values.yaml :

appname: lab



env:

SHELL: zsh

IPYTHONDIR: /lain/app



volumes:

- name: jfs

hostPath:

path: "/jfs/lab"

type: Directory



volumeMounts:

- name: jfs

mountPath: /jfs/lab



deployments:

web:

replicaCount: 1

podSecurityContext: {'runAsUser': 0}

terminationGracePeriodSeconds: 70

resources:

limits:

cpu: 2

memory: 4Gi

requests:

cpu: 100m

memory: 1Gi

command: ['jupyter', 'lab', '--allow-root', '--collaborative', '--no-browser', '--config=/lain/app/jupyter_notebook_config.py']

containerPort: 8888

workingDir: /jfs/lab/notebooks



ingresses:

- host: lab

deployName: web

paths:

- /



build:

base: lain:latest

prepare:

script:

- apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E0C56BD4

- echo "deb https://repo.clickhouse.tech/deb/stable/ main/" | tee /etc/apt/sources.list.d/clickhouse.list

- apt-get update

- apt-get install -y apt-transport-https ca-certificates dirmngr clickhouse-client=20.12.8.5 clickhouse-common-static=20.12.8.5

- apt-get clean

- pip3 install -r requirements.txt

script:

- pip3 install -r requirements.txt

光有 Jupyter 其實用途不大, 所以我上邊提到, 要做好易用性建設, 比方說封裝好各種 database client:

from os import environ



import pandas as pd
import pymysql
from IPython.core.display import display





class MySQLClient:



def __init__(self, config):
config.update({
'charset': 'utf8mb4',
'cursorclass': pymysql.cursors.DictCursor,
'autocommit': True,
})
self.config = config



def use(self, db):
self.config['database'] = db
# just to make sure this db exists
return self.execute(f'use {db}')



def fetch(self, sql, *args, **kwargs):
return self.execute(sql, *args, **kwargs)



def fetchone(self, sql, *args, **kwargs):
kwargs.update({'fetchone': True})
return self.execute(sql, *args, **kwargs)



def executemany(self, sql, *args, **kwargs):
con = pymysql.connect(**self.config)
with con.cursor() as cur:
cur.executemany(sql, *args, **kwargs)
res = cur.fetchall()



con.close()
return res



def execute(self, sql, *args, **kwargs):
con = pymysql.connect(**self.config)
with con.cursor() as cur:
fetchone = kwargs.pop('fetchone', None)
as_pandas = kwargs.pop('as_pandas', None)
cur.execute(sql, *args, **kwargs)
if fetchone:
res = cur.fetchone()
else:
res = cur.fetchall()



con.close()
if as_pandas:
return pd.DataFrame(res)
return res



x = execute



def preview(self, table_name=None, n=2):
"""
# first, use a database
mysql_client.use('configcenter')
# show tables
mysql_client.preview()
# select example data from one table
mysql_client.preview('post')
# study one single column
mysql_client.preview('post.visibility')
"""
if not table_name:
return self.execute('show tables', as_pandas=True)
if '.' in table_name:
n = max([n, 20])
table_name, column_name = table_name.split('.')
part = self.execute(
f'''
SELECT DISTINCT {column_name}, count(*) AS count
FROM {table_name}
GROUP BY {column_name}
ORDER BY count DESC
LIMIT {n}
''', as_pandas=True
)
return part



part1 = self.execute(f'''
SELECT `column_name`,
`column_type`,
`column_comment`
FROM `information_schema`.`COLUMNS`
WHERE `table_name` = "{table_name}"
''', as_pandas=True)
display(part1)
part2 = self.execute(
f'''
SELECT *
FROM {table_name}
ORDER BY RAND()
LIMIT {n}
''', as_pandas=True
)
return part2





MYSQL_CONFIG = jalo(environ['MYSQL_CONFIG'])
mysql_client = mysql = my = MySQLClient(MYSQL_CONFIG)
mysql_client.use('mydatabase')

經過了這麼一堆封裝, 有多好用你都不敢想:

就靠著類似的快捷呼叫, 在我任職過的團隊裡, 從後端工程師, 資料分析師, 乃至於產品經理, 都能直接用 JupyterLab 進行工作.

好像主要都在介紹 Jupyter 了, 挺不好意思的. 但實際上這個專案和 JuiceFS 關係也很緊密:

  • • 產生的資料報表, 或者別的 ad hoc 流程的產物, 都放在 JuiceFS 上, 直接就能方便地分享給他人(見上方"網盤"一節)

  • • 所有的程式碼(在 Jupyter 的世界裡, 叫 notebook) 都存放在 JuiceFS , 用  juicefs snapshot 來做定期備份

妙用: GitLab, ClickHouse, Elasticsearch, etc.

理論上, 所有應用需要資料落盤的時候, 你都可以放到 JuiceFS 裡, 只要合適的效能區間匹配就行. 在這一節裡介紹一下我們探索過的一些用法:

  • • GitLab 對磁碟 IO 的要求還是挺高的, 尤其 MR 的時候, 如果程式碼庫很大, 最好還是視情況遷到 SSD. 但如果你是個小團隊, 專案不多也不大, 那放在 jfs 上就能享受到一系列額外的好處, 比如用 juicefs grep 全域性搜尋程式碼倉庫(找垃圾程式碼), 方便地用  juicefs snapshot 全量備份所有 repo data, 等等

  • • 我用 ClickHouse 配合 JuiceFS CSI, 方便地拉起 CH 叢集, 這點在 小團隊如何維護 Sentry [6] 有更詳細介紹, 不重複

妙用: CI

就以 GitLab CI 為例吧, 給 Runner 設定好掛載目錄:

  [runners.docker]
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/jfs:/jfs:rw", "/cache"]

沒想到僅僅是把 JuiceFS 掛載到 CI Runner 裡, 能開啟這麼多可能性, 下邊的這些案例每一個都沒有多"神", 但都是因為有了 JuiceFS , 事情變得特別方便和易維護:

釋出構建產物 (Artifacts)

本來 JuiceFS 就是用來存檔案的, 將構建產物(比方說安卓打包)扔到 jfs, 再配合上文"網盤"一節介紹的檔案分享, 就能輕鬆做出下載連結了. 如果你團隊內部需要把構建產物釋出給非技術人員, JuiceFS + Python http.server 會是一個很好的配合.

持續部署

不是所有服務上線, 都是要更新容器的, 比方說不少前端應用的更新, 其實只是打包釋出靜態檔案, 而這一步往往也是在 CI 裡完成的, 這樣一來, 前端應用的釋出和 JuiceFS 就能做一個很好的配合:

  • • CI Job 將前端應用的靜態檔案編譯好, 釋出到 jfs 下帶有版本號的路徑

  • • 更新 Nginx 配置, 將網站指向最新版的路徑, 這樣就算髮布出去了, 需要的話還可以觸發一下 CDN 預熱

  • • 如果要回滾的話, 也可以戳一下對應版本的 CI Job, 舊版就又部署回去了

又比方說, 我們有一些專案是放到特定的伺服器上執行的, 這些伺服器或許在機房, 或許在辦公室, 我當然可以給這些機器都做好公司內網 VPN, 然後挨個地配置出定期 git clone 更新, 但有了 JuiceFS , 誰還用這種費力的方式來交換資料呢? 於是我們是這樣做的:

  • • 所有伺服器都掛載了 JuiceFS , 我們的機器初始化流程裡就做好了

  • • 專案程式碼隨著 CI 釋出到 JuiceFS , 比方說每次更新程式碼, 都會對  /jfs/[appname] 下的內容做覆蓋

  • • 伺服器上監聽 /jfs/[appname] 的檔案變動, 或者做出每天深夜定時重啟之類的, 都方便

全域性快取

GitLab CI, 或者別的各類 CI 系統, 都有各式各樣的快取機制吧, 但有些 CI 工具可以直接做成 Global, 而不需要 Per Project, 這種時候就直接拿 JuiceFS 存一份就好, 比方說:

Trivy

我們用 Trivy 來做容器映象安全掃描, Trivy 需要的就是各類安全漏洞的特徵資料, 掃誰都用的同一個 db, 因此我做了個 CI Job, 定期往 JuiceFS 下更新資料:

refresh_trivy_db:

stage: schedule

variables:

TRIVY_CACHE_DIR: /jfs/trivycache

rules:

- if: '$CI_PIPELINE_SOURCE == "schedule"'

script:

- trivy --cache-dir $TRIVY_CACHE_DIR image --download-db-only

然後所有專案都可以共用這一份 JuiceFS 下的資料, 來進行映象漏掃了, 還不錯吧:

container_scanning:

stage: release

rules:

- if: '$CI_PIPELINE_SOURCE != "schedule"'

variables:

GIT_STRATEGY: none

TRIVY_CACHE_DIR: /jfs/trivycache

script:

- trivy --cache-dir $TRIVY_CACHE_DIR image --skip-db-update=true --exit-code 0 --no-progress --severity HIGH "${IMAGE}:latest"

- trivy --cache-dir $TRIVY_CACHE_DIR image --skip-db-update=true --exit-code 1 --severity CRITICAL --no-progress "${IMAGE}:latest"

Semgrep

Trivy 是掃映象, Semgrep 則是掃程式碼的, 需要定期更新用於掃描的規則檔案. 通常的姿勢是現場下載規則檔案, 不過由於網路問題, 國內大概更願意預先下載好這些檔案, 然後直接引用. 所以輪到 JuiceFS 出場了:

# ref: https://semgrep.dev/docs/semgrep-ci/sample-ci-configs/#gitlab-ci

semgrep:

image: semgrep-agent:v1

script:

- semgrep-agent

variables:

SEMGREP_RULES: >- # more at semgrep.dev/explore

/jfs/semgrep/security-audit.yaml

/jfs/semgrep/secrets.yaml

/jfs/semgrep/ci.yaml

/jfs/semgrep/python.yaml

/jfs/semgrep/bandit.yaml

rules:

- if: $CI_MERGE_REQUEST_IID

至於更新規則檔案的流程, 沒啥難度, 所以這裡就不贅述了.

引用連結

[1] CSI 支援:  https://juicefs.com/docs/zh/cloud/use_juicefs_in_kubernetes/#csi

[2] lain:  https://timfeirg.github.io/2022/02/10/introduce-lain.html

[3] lain:  https://timfeirg.github.io/2022/02/10/introduce-lain.html

[4] JupyterLab:  https://jupyter.org/

[5] bokeh:  https://docs.bokeh.org/en/latest/docs/user_guide/jupyter.html

[6] 小團隊如何維護 Sentry:  https://timfeirg.github.io/2022/03/04/sentry.html

JuiceFS 社群故事徵集ing!

首屆 JuiceFS 社群徵文活動正在進行中 。希望通過本次活動彙集更多優質內容,幫助各位開發者、使用者更加便捷、高效地使用 JuiceFS,更好地融入開源社群, 點此快來投稿吧! FILCO 鍵盤、冰墩墩、社群周邊等你拿~

:point_down: 掃碼加群 :point_down:

:point_down: 關注「 Juicedata 」,獲取更多技術乾貨   :point_down: