容器系統資料庫為什麼讓人又愛又恨？

在容器之前，開發人員在實體機或虛拟機中運作代碼，為作業系統和電腦建立獨特版本的安裝包（通常與所安裝的其他軟體有共同的依賴關系和互動）。容器改變了這一點，允許開發人員生成小型的可移動的單元（容器鏡像）——這些單元可以捆綁所有必需的依賴關系，在任何地方運作并使用自動化進行部署。

在舊模式中，出現問題時，要求開發人員一個一個地分析和修補系統。在新模式中，開發人員不斷生成新的容器化版本來修複問題并添加功能。這些流入管道并駐留在專門的編目好的存儲（容器鏡像系統資料庫）中，等待處理（例如品質保證測試），然後在生産中進行部署。

這是系統資料庫發揮作用的地方：在整個過程中，系統資料庫仍然是你要運作的鏡像的真實來源。第一個優點是你可以在任何地方運作相同的代碼；第二個優點是在IT控制的存儲庫中保護這一段代碼，是以你可以輕松地恢複到幹淨的環境。結果是生産中不再有“配置漂移”。

現在，自動化系統不再需要勞動密集型且容易出錯的手動修補，而是持續監控正在運作的系統，并詢問“是否正在運作所需（修補過）的版本？”如果沒有，系統會自動觸發更新。

就像一個倉庫

與實體倉庫和經典分銷供應鍊一樣，持續流和容器鏡像存儲既帶來安全挑戰，也帶來機遇。考慮零售分銷供應鍊中的這些場景：

——你如何檢測并防止篡改最終存放在商店貨架上的産品？

——你如何防止假冒？

——當報告有受污染的成分時，你如何隔離不良庫存？你如何量化風險并識别有風險的客戶？

——如何隻讓經過授權的人檢視庫存？

這些“供應鍊”相關事宜在基于容器的軟體中有類似之處，而一些鏡像系統資料庫帶有處理這些問題的功能。

财務風險和隐私考慮

公共注冊服務基本且易于使用，這就是它們如此受歡迎的原因。但是，由于它們在開發人員之間共享，并且主機鏡像在多個位置由多達1000個人運作，用公共系統資料庫不太現實。

許多流行的軟體元件是開源的并且易于在網際網路上找到（通常是預先打包的容器鏡像）。但是把這些元件直接用于生産是萬萬不行的。

可以找到各種開源和商業支援的私有容器鏡像系統資料庫。有些提供了一些企業級功能，例如容器鏡像安全掃描。有些私有系統資料庫功能齊全，具有嚴格的治理和審計日志記錄等功能。

具有掃描功能的系統資料庫有什麼用？

容器的構成方式使得我們可以分析内容并确定其中包含的所有部件。這意味着當在容器鏡像中的一個小包中新發現安全漏洞時，你可以判斷系統是否易于受到攻擊。

行業和政府機構贊助商經常更新常見漏洞和風險（CVE）資料庫。一些容器鏡像系統資料庫可以利用它們來執行庫存鏡像的靜态分析。無論何時更新，使用鏡像或有新的CVE資料庫通知，都可以觸發掃描。

從網際網路下載下傳的這些容器是否值得信賴？通常不行。但是要知道開發人員也不是完美的：他們的代碼可能包含錯誤，并且可能包含存在缺陷的庫和包。

如果你的系統記錄流和容器鏡像的使用，你甚至可以生成報告，以特定的時間、日期和位置量化風險——這就跟在倉庫中使用攝像頭一樣。

用于治理的鏡像簽名和通路控制

可以對容器鏡像簽名，并在部署時驗證簽名——這類似于識别物品出處的雷射全息圖。同時，一些開源代碼可能不被許可用于特定用途，可能使你處于法律風險之中。

通過私有系統資料庫，你可以決定誰來準許可以在你的系統上運作的容器，并允許驗證鏡像未被篡改。

基于角色的通路控制實施與特定活動、位置和部門相關的使用者權限，即誰可以釋出更新的鏡像，誰可以使用它們。

治理補充掃描。如果沒有特定的程式和保護措施，錯誤和惡意代碼（或未經許可使用的代碼）可能會在整個組織中出現。

支援複制的好處

當大規模運作時，單個中央系統資料庫不太可能滿足需求。在運作容器的系統附近運作系統資料庫可以減少部署延遲并減少網絡中斷的風險。在負載均衡器之後運作多個系統資料庫執行個體可帶來規模和高可用性的優勢。有時，還需要将開發、測試和生産系統資料庫分離為自動化CI / CD管道的一部分。

如果你的系統資料庫支援政策驅動的自動鏡像複制，那麼多個系統資料庫可以支援自動的持續容器開發工作流程、負載均衡、高可用性和全球規模的多雲運維——所有這些都具有最小的運維開銷和延遲。

小結

許多流行的容器系統資料庫都是開源的，但有些系統資料庫有更廣泛的社群支援。從長遠來看，應該尋找在一個有效的組織（如CNCF）的治理下的、充滿活力的社群（擁有大量積極參與的開發人員群組織）提供的解決方案。這可以增加快速識别和修複錯誤的可能性，并添加新的功能。

應用程式開發是一個永無止境的過程，但容器鏡像系統資料庫使事情盡可能清晰明了。不過不要滿足于提供基本功能和API的簡單容器鏡像系統資料庫。