清理映象庫空間的乙個思路

最近遇到乙個有趣的狀況，某映象倉庫占用了大量的磁碟空間。通常要解決這種問題，給 registry 發刪除指令，並進行 gc 就可以了。然而很多時候，所有映象都正常，在刪除多個 tag 甚至是 repository 之後，問題仍然沒能緩解，原理也很容易理解——刪除的映象雖然大，可能只是復用了一些比較大的層，刪除映象並不會真正的發出，所以還是需要對映象庫的儲存進行更多的了解，進行進一步的統計，在層一級對映象倉庫進行分析，才能獲取更有效的途徑。

首先發現了乙個有意思的專案：dockerregistryexporter，這個專案是乙個 python 編寫的 prometheus exporter，其中包含四個 gauge：

-repository_tags_total：按映象計算的 tag 數量。

-repository_revisions_total：按映象計算的版本數量。

-repository_tag_layers_total：以映象和 tag 計算的 layer 數量。

-repository_tag_size_bytes：以映象和 tag 計算的檔案尺寸。

該映象使用掛卷的方式，直接對映象庫檔案系統進行掃瞄，例如：

claimname: registry通過sidecar的部署方式和registry容器共享檔案系統，可以定時輸出監控指標，例如：

...然而這並不能滿足我的要求，關於引用的資料並沒有體現，另外前面也提到，我們需要比較精確地獲得映象版本、tag 和 layer 之間的引用關係以及各自的尺寸，用 promql 有點彆扭。

這並不是乙個很常見的需求，只能是乙個清理之前的準備動作，目前看來我需要找到的就是引用數量少、但是體量比較大的 layer，但是誰知道以後會需要什麼新的標準呢？乾脆把這些東西寫入到資料庫裡算了，把這些東西寫入資料庫之後，還掌握 sql 這樣傳統才藝的程式設計師就可以隨便搞一搞其它條件了。

映象庫根目錄中有兩個子目錄：blobs中儲存了所有的 layer，而repositories中則是以映象為單位儲存的元資料。

首先看看映象的資料

$ tree/org/repo/gameserver .├── revisions │ └── sha256 │ └── ecfb0206e8b... │ └── link └── tags └── latest ├── current │ └── link └── index └── sha256 └── ecfb020...

└── link

每個映象的 manifests 有兩個目錄，分別承載的是版本和 tag，正常來說 tag 和版本是一致的，但實際上在一些特別情況下，這兩個數量可能是不一致的，就會導致只用 tag 已經無法拉取該映象，屬於一種半孤立狀態，應該說是需要清除的。

兩個目錄中的link檔案中包含的是乙個雜湊碼，可以使用這個雜湊碼在_layers中查詢到該映象的版本/tag 對應的清單層，使用這個字串可以在根_layer中查到對應的目錄，目錄下面的data檔案中就是每個層的具體資料，對於清單層，其中會是乙個json字串：

,
"layers": [
,]}

這裡看到清單中包含兩個主節點，config和layer，至此，乙個映象是由三種不同的層構成的：清單、config 和 layer。我們關注的主要是 layer，其中的data檔案包含的就是各層的具體內容，清單和 config 中都是文字，layer 通常都是二進位制的，也是我們要關注的主要內容。

接下來的問題就順理成章了，把 repository、tag、revision 以及 layer 的關係建立起來，隨便用個 sql 語句，就能夠按照具體需求對「引用少、尺寸大」的 layer 進行過濾了。

清理映象庫空間的乙個思路

乙個保密思路

資料庫重建索引的乙個思路

貼乙個清理死鎖的語句

清理映象庫空間的乙個思路

乙個保密思路

資料庫重建索引的乙個思路

貼乙個清理死鎖的語句

相關推薦