Hackpad 封存器 - hackingthursday

暫存內容

最後編輯：2014-12-04 建立：2014-12-04 歷史紀錄

MAT Lgolang 心得分享

 

docker 心得分享

  • Engine 跟 Engine.Job 是 docker 核心類別
    • 特別注意 Engine.Register(<cmd>, <handler>) 跟 Engine.Job(<cmd>).Run() 的用法
    • 可參考 engine/job_test.go 的 sample code

 

API daemon 的運作概要

  • api server daemon 如何產生
    • docker/docker.go 的 main() 執行 mainDaemon()
    • docker/daemon.go 的 mainDaemon() ，用 eng.Job("serveapi",...) 呼叫 serveapi 指令，並用 job.Run() 執行之
    • "serveapi" 指令，會對應執行 ServeApi() 函式
    • api/server/server.go 的 ServeApi() 接著執行 ListenAndServe()
    • api/server/server.go 的 ListenAndServe() 執行
      • httpSrv := http.Server{Addr: addr, Handler: r} 指定 request 的 hander , 其中 handler 由 createRouter() 產生
      • httpSrv.Serve() 進入 http server daemon 的運行迴圈
  • server 處理 client 發的 request 並回傳 response 的過程
    • request 會被配發給 http server daemon 所註冊的 handler 處理
    • 這個 handler 由 api/server/server.go 中 createRouter() 所產生
  • server 端，如何分派 request 來的 command 並對應 handler
    • api/server/server.go 的 createRouter() 所產生 handler ，內有 command 與 registed handler 的對應表( GET/POST/...)
    • 對應的 registed handler 定義在 api/server/server.go 中
      • 大部份 registed handler 會進一步執行 Engine 定義的功能指令
        • Engine 定義的功能指令，主要位於 daemon/*.go 的目錄檔案中
        • 這些功能指令經由 daemon/daemon.go 的 Install() 中的對應表來註冊成功能指令

 

sysd 開發生存手冊

  • 生存法則1: 先不要管 golang 怎麼寫，矇著眼睛都先 build 過了再說
  • 生存法則2: 看不懂主程式，也不會寫 golang, 還是可以新增一個 hello world 模組
  • 生存法則3: 有樣學樣，看其他模組怎麼活下來的，我就照著作

 

    如何 build

  • 安裝 go ( 請至 http://golang.org/doc/install 直接安裝軟體, osx, windows, 都有 binary 版本, 不用自己 build )
  • 下載 sysd 程式碼 ( 請至本 github 自行找到 git clone 連結 )
  • 承2. 下載後，請執行 git checkout -b devel 下載目前的開發版本
  • 執行 make.sh 指令 ( 若有安裝 make 工具，也可以直接打 make )
  • done ( 若有 build fail 的話, 歡迎 FB 戳一下目前 active 的開發者 )

 

註1: 執行 ./sysd/sysd ，然後打開 "http://127.0.0.1:8080/ifconfig" 就可以看到輸出的結果.

註2: 目前主版本在 linux/osx/windows 上都可以 pass build, 歡迎大家下載測試

 

    如何新增模組

假設模組名稱為 xyz

  • 複製 /mods/sample/ 目錄至 /mods/xyz/
  • 將 /mods/syz/ 的檔案名都改為 xyz ( ex: sample.go => xyz.go )
  • 編輯 /mods/xyz/xyz.go ，將 "sample" 所有字串都替換為 "xyz"
  • 編輯 /mods/loader/mods.go ，比照前幾行，新增一行 xyz 的 => _ "github.com/hacking-thursday/sysd/mods/sample"
  • 重複跑一次 make.sh
  • 執行 ./sysd/sysd ，然後用瀏覽器打開 "http://127.0.0.1:8080/sample" 就可以看到新增的 xyz 模組的輸出了.

 

 

目標指令集

 

 

實際遇到過的問題

 

History:

2014-10-02 於 H4 下課後，Mat 和 Carl Su, yan 聊天提出構想, 由 Carl Su 建議命名為 sysd.

2014-10-03 於 github.com 作 init commit.

版本號碼我先初步編上去了, 主要變更如下:

0.0.1 => pass build

0.0.3 => 可執行的概念驗證

0.1.0 => 新增模組的架構

0.2.0 => kd, mat 兩分支成果整合

0.3.0 => 新增 embed web UI

0.4.0 => 取得著作授權合作

0.5.0 => 新增套件發佈流程

 

專案構想起源 , 2014-10-03

( todo: 取精要內容進 "what is sysd" 的介紹內容 )

補充一下,

這個是昨天下課後聊到的專案，"sysd" 的命名由 Carl.Su 建議

目標是提供一個 api daemon for linux, 可以讓應用程式，透過 Restful API 的方式，來取得系統面的資訊跟操作.

具體一點，就是我們遇到應用程式要取用 ip 資訊時，通常都是透過像是 system() 的函式操作 ifconfig 的方式來取得. (ex: http://stackoverflow.com/questions/6147193/output-from-subprocess-popen ) ，所以不管是 php/python/c/javascript... 都會有相同的困擾 => 1. 必須要有 ifconfig (相依性) 2. 要 "parsing" ifconfig 的輸出訊息 ( F**K!! )

但細看 ifconfig / route /.. 的實作，其實就只是一些 ioctl 呼叫 kernel API , 跟 cli 的 cmdline 操作的搭配而已. 所以我所想的就是:

如 果今天把一系列類似 output = os.system("ifconfig eth0") 都換成通用的 API => rest_api.get( "/sysd/ifconfig/eth0" ) ，並回傳 json/xml 容易處理的格式，那會帶來什麼樣的改變呢!?

上述的這個想法，就是 sysd 這個專案的源始動機.

實作面上，預計比照 docker 的架構，只是將對象從 vm 的操作換成 Linux 系統資訊 ( ex: uname, arp, route, /sys/* )

有興趣的人，可以先 checkout docker 的 source code, 建議可先看 /api/server.go 的 createRouter() 跟 /api/client.go 的 CmdInfo() 開頭.

另外提供之前的讀碼筆記作參考, http://www.hackingthursday.org/2014-03-13#toc4

目前什麼成果都還沒有，所以我想前期 3~4 週, 可能會像 3~5 人的興趣小組讀書會 ( linux + api + go ) , 等到開始有可 demo 的 prototype 時，再更公開 promote 給大家一起參與~

any question? welcome feedback

 

 

Linux /proc, /sys 研究心得

( todo: 取精要內容進 "Developer Guide" 的架構介紹內容 )

跟大家分享一下最近的 survey 心得.

1. 我發現 /proc/ 跟 /sys/ 下的資料，主要有幾種大類別 A => 像 /proc/cpuinfo , 左欄 Key + 右欄 value B => 像 /proc/net/route, 第一行是 key columns, 第二行之後是 values C => 像 /proc/loadavg , 一行資料，以空白分隔 D => 像 /proc/softirqs , 屬於 table 式的 若針對上述 4 種類別寫出通用的函式，parse 成 2維陣列，應該能快速支援不少資料

2. 另外 我發現 /sys/ 目錄有一些規則, 只有 /sys/devices/ 目錄有龐大的樹狀結構。剩下的 /sys/*/ 其他目錄，大都只有 1~2 層的結構. 所以我猜測, /sys/*/ 的其他目錄，應該是屬於分類class性質的，而 /sys/devices/ 底下，則是真正的 object tree.

3. 承上, 我發現每個 object node 都有 "uevent" 的檔案，所以似乎可以用 ` find /sys/devices/ -type f -name 'uevent'` 來列舉所有的 device object.

4. 承上，我注意到有些目錄會有 subsystem 或 driver 的 symbolic link. 我認為用這個連結關係來回溯分析，應該可以分析並繪出 device object tree 跟 driver / subsystem 的關連圖.

具體一點來說，大概就可以產出像是 http://i.stack.imgur.com/LMa7A.pnghttp://www.dannytsang.co.uk/wp-content/uploads/2010/02/Device-Manager.png 的成果圖表. ( HTML UI? )

5. 以 cpufreq-info 為例

一 開始找的 /sys/devices/system/cpu/cpu0/cpufreq/* 並沒有 uevent, 所以不是 device object. 是上一層 => /sys/devices/system/cpu/cpu0/ 有 "subsystem" 的 link 到 /sys/bus/cpu/ => /sys/bus/cpu/ 有 devices/ 跟 drivers/ 目錄，分別列出 device object 跟 driver 的項目. 不過此例因為 cpu 是 kernel built-in 的功能，所以沒有 drivers/* 的內容.

6. /sys/ 下的資料，比較多是 device based 的資料集比較多，所以這部份要一個一個去查每個 subsystem 的特性，才會轉譯整合成 API.

BTW, 不知道有沒有人知道那裡可以查到 driver 相關的 kernel API 資訊??