第一次聽到這個名字應該是2016年初的時候,那是在容器技術已經興起的,各個容器管理平台正處於群雄逐鹿的時候,mesos、kubernetes、swarm等被國內外各個廠商用來作為容器的管理系統。這個時候突然冒出一個詞harbor,港灣,同事是這樣介紹的:幾個VMware中國的人搞了一個容器鏡像倉庫。於是變成為harbor的第一批用戶,后來也有幸成為contributor。說了半天,harbor是什么呢?簡單來說,容器是集裝箱,集裝箱放哪里呢?對,港灣!官方的說法是:Harbor是一個用於存儲和分發Docker鏡像的企業級Registry服務器。
我對Harbor的誤解
1.Harbor是負責存儲容器鏡像的
Harbor是鏡像倉庫,那么就應當是存儲鏡像的,這個可能是大多數接觸harbor的人的一個誤區,當深入了解以后才發現,鏡像的存儲harbor使用的是官方的docker registry服務去完成,至於registry是用本地存儲或者s3都是可以的,harbor的功能是在此之上提供用戶權限管理、鏡像復制等功能,提高使用的registry的效率。
2.Harbor鏡像復制是存儲直接復制
這個是我對harbor的第二個誤解,鏡像的復制,我第一反應應該是鏡像分層文件的直接拷貝,當時我還在思考怎么保證復制時鏡像分層文件的拷貝沖突、不同存儲直接如何轉化,如:aufs和devicemapper以及分層文件索引創建等問題,當查看harbor源代碼時候才發現,harbor采用了一個更加通用、高屋建瓴的做法,通過docker registry 的API去拷貝,這不是省事,這種做法屏蔽了繁瑣的底層文件操作、不僅可以利用現有docker registry功能不必重復造輪子,而且可以解決沖突和一致性的問題。
Harbor的架構
harbor的整體架構還是很清晰的,下面簡單介紹一下,下圖展示harbor主要的功能組件和信息流向。
主要組件包括proxy,他是一個nginx前端代理,主要是分發前端頁面ui訪問和鏡像上傳和下載流量,上圖中通過深藍色先標識;ui提供了一個web管理頁面,當然還包括了一個前端頁面和后端API,底層使用mysql數據庫;registry是鏡像倉庫,負責存儲鏡像文件,當鏡像上傳完畢后通過hook通知ui創建repository,上圖通過紅色線標識,當然registry的token認證也是通過ui組件完成;adminserver是系統的配置管理中心附帶檢查存儲用量,ui和jobserver啟動時候回需要加載adminserver的配置,通過灰色線標識;jobsevice是負責鏡像復制工作的,他和registry通信,從一個registry pull鏡像然后push到另一個registry,並記錄job_log,上圖通過紫色線標識;log是日志匯總組件,通過docker的log-driver把日志匯總到一起,通過淺藍色線條標識。
Harbor使用
我們當前升級的版本是harbor 1.1.1,是從0.5版本升級過來,下面簡單從頁面角度講解一下harbor的使用.
1.用戶管理
基於角色的訪問控制,RBAC,這個是k8s 1.6以后才加入的功能,harbor在設計的開始就考慮進去,用戶分為三種角色:項目管理員(MDRWS)、開發人員(RWS)和訪客(RS),當然還有一個最高管理員權限admin系統管理員。
上面的簡稱大概說一下,M:管理、D:刪除、R:讀取、W:寫入、S:查詢,非常細致的權限管理體系。當然一個用戶可以在不同的項目里面扮演不同角色,這個和現實的用戶管理體系非常吻合。
2.項目管理
項目管理是系統最主要的一個功能模塊,項目是一組鏡像倉庫的邏輯集合,是權限管理和資源管理的單元划分。一個項目下面有多個鏡像倉庫,並且關聯多個不同角色的成員,鏡像復制也是基於項目的,通過添加復制規則,可以將項目下面的鏡像從一個harbor遷移到另一個harbor,並且可以通過日志查看復制過程,並有retry機制。
3.配置管理和日志查詢
配置管理主要是配置harbor的認證模式,企業內部使用,通常都是對接到公司LDAP上面,當然harbor也支持數據庫認證;還可以設置token的有效時間。用戶對鏡像的pull和push操作都可以被harbor記錄下來,這樣為排查文件提供了重要手段。
當然harbor功能不止我上面說的,譬如harbor集成了clair鏡像掃描功能,它是cereos開發的一款漏洞掃描工具,可以檢查鏡像操作系統以及上面安裝包是否與已知不安全的包版本相匹配,從而提高鏡像安全性。
4.Harbor高可用部署
通過三個harbor完成高可用部署,前面通過負載均衡器對外提供服務。共享數據庫與緩存。結構如下
Harbor和kubernetes結合
kubernetes是什么我就不在此贅述了,簡單一句話,它是一個用於自動部署,擴展和管理容器化應用程序的開源系統。它的詳細內容參考請參考官網。kubernetes中的kubelet組件負責容器的生命周期管理,通過CRI對接到不同的容器實現如:rkt、Docker等,目前默認是Docker,kubelet啟動Docker容器的時候,會根據策略IfNotPresent是如果本地不存在則拉取,打上latest標簽或者設置Always策略則是一直拉取最新鏡像。我們在當前的企業中,Docker的鏡像倉庫配置成harbor,在容器啟動是會拉取harbor中的鏡像。這里又幾個問題需要注意
第一,imagePullSecrets
鏡像拉取需要先登錄,在kubernetes多用戶使用場景中,鏡像的安全必須要保證,一個用戶是沒有權限拉取另一個用戶下面的鏡像。kubernetes提供了imagePullSecrets負責管理鏡像拉取時的安全認證。其實kubelet就是模擬了一次用戶登錄,並且會在~/.docker/config.json下面生成auth認證信息。當然如果是絕對單個用戶的場景,為了避免麻煩,你也是使用admin到每台機器上面登錄(docker login)一下,這樣鏡像拉取就都是通過admin來完成。
第二,https
為了安全建議使用https,我們在生成環境中使用的是自簽名的證書,如果是設置成https,需要在設置非安全倉庫–insecure-registry,並重啟Docker服務。
反過來,harbor本身的部署也可以通過kubernetes來完成,通過kubernetes的rc和svc以及pv的配合完成harbor的創建。目前我們的生成環境還是沿用docker-compose的方式部署。
Harbor的未來和改進
Harbor的使用有一年多的時間了,也根據自己企業內的需求定制了一些功能,如:直接從公網上面拉取鏡像,鏡像在不同的項目之間拷貝等功能。這里再給Harbor提幾個新能點希望以后能添加:1.鏡像同步可以不僅限於harbor之間,只要是實現docker registry API接口鏡像倉庫都可以同步,2.鏡像資源可以有策略的自動回收,避免的資源浪費和撐爆磁盤的問題,作為一個harbor的長期使用者,希望harbor能走的更遠,但對Harbor的未來多少有點擔憂,主要是因為,Harbor的其實本質還是圍繞Docker Registry來做業務擴展,很容易被復制,並且和Docker捆綁。
Harbor源碼分析
Harbor的源代碼主體采用的是beego框架,之前寫了一些harbor部署和源碼分析的文章這里就不再重復贅述了。
但是這里主要講解一些Harbor設計比較好的地方:
1.鏡像復制過程中狀態機的使用,由於鏡像的復制是個比較繁瑣的過程,涉及到很多方面,如:網絡中斷、權限不足、服務重啟等為止因素,都有可能會失敗,通過狀態機的方式,很好的控制了鏡像拷貝過程,從初始化到項目校驗,到Manifest拉取,然后比較blob確定需要復制的blob,等blob復制完畢最后還要上傳Manifest文件。整個過程通過狀態機串聯在一起,並且失敗情況能夠retry。
2.整體架構,結構簡單分工明確,這個系統的設計每個模塊都可以打包成獨立的Docker鏡像,方便部署和升級,adminserver作為整體配置中心,jobservice作為鏡像同步服務分工明確。並且編譯打包工具完善,方便用戶使用。
3.LDAP企業集成,這個對於我們企業用戶非常實用,免去很多用戶對接的繁瑣工作。