為了使OpenStack部署更平穩安全運行，更新和打補丁是非常關鍵的工作。但是要執行這些更新任務，IT團隊要投入的時間精力遠不只是按按開關就可以的。

OpenStack平臺由大約30個不同的模塊組成，其中每個模塊都有著相當復雜的功能和要求。OpenStack的開發團隊也是基于開源的，這有可能導致不平衡的測試、文檔和代碼質量。

這就要求IT團隊必須定期執行OpenStack更新以避免影響系統運行的穩定性。在很多方面，那就如同是維護一個操作系統(如Windows)一樣，需要將bug修復更新保持至最新和確保安全性處于最佳水平。

但是，Windows和OpenStack之間的區別在于后者仍然處于變化較快的發展期，尤其是不同模塊的成熟度水平有著較大差異。OpenStack的重要版本發布頻率大約為六個月，而微軟的發布周期為2-4年。此外，由于OpenStack整體軟件成熟度水平不高，功能集在不斷發展，所以在重要版本之間的小版本發布也是非常頻繁且復雜。

直到近來，用于執行OpenStack更新的首選方法都是使用命令行界面(CLI)，這種方法對于單個服務器是很好的，但對于大型節點集群則顯得效率低下。對于大型集群執行更新來說，出現錯誤和更新失敗的幾率則會顯著提高。

執行OpenStack更新的最佳做法

在理想的OpenStack更新中，IT人員應體用所有節點，打補丁，然后重新啟動整個配置——但這種方法會導致大量的停機時間。在實施具體更新之前仔細分析更新內容可以提供一種替代解決方案。

尋找那些不對其他模塊有依賴性且不會實質性改變存儲數據結構的模塊。Bug修復是最常見的OpenStack更新，這類更新可滾動應用于所有節點。

如果OpenStack更新影響了跨模塊的交互，那么IT團隊就需要一起更新這兩個模塊。但是，難題在于任何節點都可能與其他任何節點進行交互。最安全的打補丁方法就是關閉所有節點。但是，如果跨模塊更新涉及了可以關閉的功能，那么就可以安全地重新啟動系統。然后，當集群更新時，可再次打開功能。

一般來說，最好是一次更新一個OpenStack模塊，然后確定集群是否穩定和無錯誤。當錯誤修復出錯時，區域化方法可實現更為簡便的調試。

務必始終從已知和安全的來源獲取更新代碼包。這一原則也同樣適用于實例與容器鏡像、實例與容器中的應用程序和數據，以及OpenStack代碼等。當OpenStack集群擴展規模并鏈接至公共云時，從安全黑客中識別和恢復可能是非常耗時的。

OpenStack更新的自動化選項

OpenStack社區牢記了Windows中的教訓。例如，實現OpenStack更新過程自動化是非常有意義的，因為此舉將有助于實現停機時間和風險的最小化。而相關的實現工具在一些OpenStack發布版本中。

Red Hat公司的OpenStack平臺軟件包就是一個典型的例子。這個軟件包可處理所有主要的升級任務，以及一些次要的更新。Red Hat試圖避免在非重要發布版本中進行功能變更，例如可能具有跨模塊影響的API。

其他的供應商也正在解決這個自動化問題。Platform9可實現OpenStack升級的自動化，而惠普企業、戴爾科技以及IBM也紛紛加入此行列。其他的軟件供應商則包括Stratoscale、NephoScale 和 Mirantis�？紤]到通過CLI方式手工實現OpenStack升級這一方式的復雜性，管理員應當使用這些軟件包中的一種來控制升級過程，從而進一步降低風險。雖然它們還不夠完美，因為跨模塊的依賴性仍然會是這一過程復雜化，但是它們確實有助于主要版本的升級和發布。