LXD 2.0 系列(十二):調試,及給 LXD 做貢獻
如果你從一開始就關注了這個系列,你應該已經使用了 LXD 相當長的時間了,並且非常熟悉它的日常操作和功能。
但如果出現問題怎麼辦?你可以做什麼來自己跟蹤問題?如果你不能,你應該記錄什麼信息,以便上游可以跟蹤問題?
如果你想自己解決問題或通過實現你需要的功能來幫助改善LXD怎麼辦?如何構建,測試和貢獻 LXD 代碼庫?
調試 LXD 並填寫 bug 報告
LXD 日誌文件
/var/log/lxd/lxd.log
:
這是 LXD 日誌的主文件。為了避免它快速充滿你的磁碟,默認只會記錄 INFO
、WARNING
或者 ERROR
級別的日誌。你可以在 LXD 守護進程中使用 –debug
改變其行為。
/var/log/lxd/CONTAINER/lxc.conf
:
每當你啟動容器時,此文件將更新為傳遞給 LXC 的配置。
這裡會展示容器將如何配置,包括其所有的設備、綁定掛載等等。
/var/log/lxd/CONTAINER/forkexec.log
:
這個文件包含 LXC 命令執行失敗時產生的錯誤。這個情況是非常罕見的,因為 LXD 通常會在發生之前處理大多數錯誤。
/var/log/lxd/CONTAINER/forkstart.log
:
這個文件包含 LXC 在啟動容器時的錯誤信息。含 LXC 命令執行失敗時產生的錯誤。
CRIU 日誌 (對於實時遷移)
如果使用 CRIU 進行容器實時遷移或實時快照,則每次生成 CRIU 轉儲或恢復轉儲時都會記錄額外的日誌文件。
這些日誌也可以在 /var/log/lxd/CONTAINER/
中找到,並且有時間戳,以便你可以找到與你最近的操作所匹配的那些日誌。它們包含 CRIU 轉儲和恢復的所有內容的詳細記錄,並且比典型的遷移/快照錯誤消息更容器理解。
LXD 調試消息
如上所述,你可以使用 -debug
選項將守護進程切換為執行調試日誌記錄。另一種方法是連接到守護進程的事件介面,它將顯示所有日誌條目,而不管配置的日誌級別(即使是遠程工作)。
舉例說,對於 lxc init ubuntu:16.04 xen
來說,
lxd.log
會是這樣:
INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
而 lxc monitor –type=logging
會是:
metadata:
context: {}
level: dbug
message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'
timestamp: 2017-02-24T18:14:01.025989062-05:00
type: logging
metadata:
context:
ip: '@'
method: GET
url: /1.0
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.341283344-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.341536477-05:00
type: logging
metadata:
context:
ip: '@'
method: GET
url: /1.0/containers/xen
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.347709394-05:00
type: logging
metadata:
context:
ip: '@'
method: PUT
url: /1.0/containers/xen/state
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.357046302-05:00
type: logging
metadata:
context: {}
level: dbug
message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358387853-05:00
type: logging
metadata:
context: {}
level: dbug
message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358578599-05:00
type: logging
metadata:
context:
ip: '@'
method: GET
url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.366213106-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.369636451-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.369771164-05:00
type: logging
metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.424696767-05:00
type: logging
metadata:
context:
driver: storage/zfs
name: xen
level: dbug
message: ContainerUmount
timestamp: 2017-02-24T18:14:09.432723719-05:00
type: logging
metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.721067917-05:00
type: logging
metadata:
context:
action: start
created: 2017-02-24 23:11:45 +0000 UTC
ephemeral: "false"
name: xen
stateful: "false"
used: 1970-01-01 00:00:00 +0000 UTC
level: info
message: Starting container
timestamp: 2017-02-24T18:14:09.749808518-05:00
type: logging
metadata:
context:
ip: '@'
method: GET
url: /1.0
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.792551375-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.792961032-05:00
type: logging
metadata:
context:
ip: '@'
method: GET
url: /internal/containers/23/onstart
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.800803501-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.803190248-05:00
type: logging
metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.803251188-05:00
type: logging
metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.803306055-05:00
type: logging
metadata:
context: {}
level: dbug
message: 'Scheduler: container xen started: re-balancing'
timestamp: 2017-02-24T18:14:09.965080432-05:00
type: logging
metadata:
context:
action: start
created: 2017-02-24 23:11:45 +0000 UTC
ephemeral: "false"
name: xen
stateful: "false"
used: 1970-01-01 00:00:00 +0000 UTC
level: info
message: Started container
timestamp: 2017-02-24T18:14:10.162965059-05:00
type: logging
metadata:
context: {}
level: dbug
message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:10.163072893-05:00
type: logging
lxc monitor
的格式有點不同於每個條目都縮合成一行的日誌文件,但更重要的是,你可以看到所有 level:dbug
條目。
如何報告 bug
LXD 的 bug
最好報告 bug 的地方是 https://github.com/lxc/lxd/issues。確保完整填寫了 bug 報告模板中的內容,這些信息可以節省我們我們時間來複現環境。
Ubuntu 的 bug
如果你發現 Ubuntu 包本身有問題,無法安裝、升級或刪除。或者遇到 LXD init 腳本的問題。報告此類錯誤的最好是在 Launchpad 上。
在 Ubuntu 系統上,你可以使用:ubuntu-bug lxd
,它將自動包括一些日誌文件和包信息供我們查看。
CRIU 的 bug
與 CRIU 相關的 Bug,你可以通過 CRIU 的錯誤輸出發現,你應該在 Launchpad 上報告這些:ubuntu-bug criu
請注意,通過 LXD 使用 CRIU 屬於測試版功能,除非你願意通過 Canonical 的支持合同付費支持,要麼可能需要一段時間才能查看你的錯誤報告。
貢獻給 LXD
LXD 用 Go 寫成並託管在 Github。我們歡迎任外部的貢獻。為 LXD 貢獻不需要 CLA 或類似的法律協議簽署,只是通常的開發者所有權證書(Signed-off-by:
行)。
在我們的問題追蹤器工具中,我們列有許多潛在的功能需求,新的貢獻者可以以此作為良好的起點。通常最好在開始處理代碼先發出 issue,這樣每個人都知道你正在做這項工作,以便我們可以提供一些早期反饋。
從源碼源碼構建 LXD
這裡有上游的維護說明:https://github.com/lxc/lxd#building-from-source
你需要在 Github 上 fork 上游倉庫,然後將你的更改推送到你的分支。我們建議每天 rebase 上游的 LXD,因為我們傾向於定期合併更改。
運行測試套件
LXD 維護了兩套測試集,單元測試和集成測試。你可以用下面的命令測試所有:
sudo -E make check
要只運行單元測試,使用:
sudo -E go test ./...
要運行集成測試,使用:
cd test
sudo -E ./main.sh
後者支持相當多的環境變數來測試各種存儲後端、禁用網路測試、使用 ramdisk 或只是調整日誌輸出。其中一些是:
LXD_BACKEND
:btrfs
、dir
、lvm
或zfs
」 之一(默認為dir
)
運行 LXD 存儲驅動程序相關的所有測試。LXD_CONCURRENT
:true
或false
(默認為false
)
這啟用一些額外的並發測試。LXD_DEBUG
:true
或false
(默認為false
)
記錄所有 shell 命令,並在調試模式下運行所有 LXD 命令。LXD_INSPECT
:true
或false
(默認為false
)
測試程序會在故障時掛起,以便你可以檢查環境。LXD_LOGS
:將所有LXD
日誌文件轉儲到的目錄(默認為 「」)
所有生成的 LXD 守護進程的logs
目錄將被複制到此路徑。LXD_OFFLINE
:true
或false
(默認為false
)
禁用任何依賴於外部網路連接的測試。LXD_TEST_IMAGE
: unified 格式的 LXD 鏡像的路徑(默認為 「」)
可以使用自定義測試鏡像,而不是默認的最小 busybox 鏡像。LXD_TMPFS
:true
或false
(默認為false
)
在tmpfs
安裝中運行整個測試套件,這會使用相當多的內存,但會使測試速度明顯更快。LXD_VERBOSE
:true
或false
(默認為false
)
不太極端的LXD_DEBUG
版本。shell 命令仍然會記錄,但-debug
不會傳遞給 LXC 命令,LXD 守護進程只能使用-verbose
運行。
測試程序將在實際運行之前提醒你任何缺失的依賴項。在相當快的機器上運行該測試可在 10 分鐘內完成。
發送你的分支
發送拉取請求(PR)之前,你需要確認:
- 你已經 rebase 了上游分支
- 你的所有提交信息都包括
Signed-off-by: First Last <email>
這行 - 已刪除任何你的臨時調試代碼
- 你已經將相關的提交 squash 在一起,以保持你的分支容易審查
- 單元和集成測試全部通過
一切完成後,在 Github 上發起一個拉取請求。我們的 Jenkins 將驗證提交是否全部有 signed-off
,在 MacOS 和 Windows 上的測試將自動執行,如果看起來不錯,我們將觸發一個完整的 Jenkins 測試,它將在所有存儲後端、32 位和 64 位以及我們關心的所有 Go 版本上測試你的分支。
假設我們有人觸發了 Jenkins,這通常需要不到一個小時的時間。
一旦所有測試完成,我們對代碼本身感到滿意,你的分支將會被合併,你的代碼會出現在下一個 LXD 發布中。如果更改適用於 LXD stable-2.0 分支,我們將為你向後移植。
總結
我希望這個系列的博客文章有助於你了解什麼是 LXD,以及它可以做什麼!
本系列的範圍僅限於 LXD(2.0.x),但我們也為那些想要最新功能的用戶提供每月功能版本。你可以找到一些其他涵蓋了原來的 LXD 2.0系列文章中列出的功能的博客文章。
額外的信息
LXD 的主站在: https://linuxcontainers.org/lxd
LXD 的 GitHub 開發倉庫: https://github.com/lxc/lxd
LXD 的郵件列表: https://lists.linuxcontainers.org
LXD 的 IRC 頻道:#lxcontainers on irc.freenode.net
在線嘗試 LXD: https://linuxcontainers.org/lxd/try-it
作者簡介:我是 Stéphane Graber。我是 LXC 和 LXD 項目的領導者,目前在加拿大魁北克蒙特利爾的家所在的 Canonical 有限公司擔任 LXD 的技術主管。
via: https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/
作者:Stéphane Graber 譯者:geekpi 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive