核心升級是否可以使用以上作業系統軟體的配置管理 (CM) 工具來完成？
我使用各種 Linux 發行版，主要是基於 Debian 的，通常都是預設的（我在核心/shell 或內部實用程序（發行版附帶的實用程序）中沒有任何更改。我通常在這些系統上安裝 Apache、MySQL 和 PHP，並且沒有也不要改變任何東西。
我從來沒有對任何系統進行過核心升級，因為我不記得曾經有過這樣的需求或收到一些需要它的本地郵件。
我知道像 Ansible 這樣的配置管理 (CM) 工具用於編排、部署並且可能還自動化作業系統層（當然包括核心）之上的所有內容，但出於好奇 - 可以使用 Ansible “潛入”到核心並使用它自動升級核心？
如果您認為這是基本全預設系統（發行版本身 - 其核心、shell 和內部實用程序根本沒有更改的系統）中的最佳實踐，也請分享。
對於大多數現代 Linux 發行版，核心作為一個包分發，就像任何其他軟體/庫一樣。因此，以 Ansible 為例，您可以執行以下任務：
- name: Ensure that latest kernel is installed apt: name: linux-image-amd64 state: latest update_cache: yes notify: reboot_server # You would need a corresponding handler that reboots the system這將確保每次執行播放時都會安裝最新的核心包。
然而，核心與大多數其他軟體包的不同之處在於：
- 可以同時安裝多個版本，因此您需要管理舊版本的刪除。您不一定要自動執行此操作，因為：
- 要啟用新安裝的核心，您需要重新啟動系統，因此需要從業務流程 POV 和技術上對其進行管理。這不是完全無風險的操作，因此取決於系統架構的性質，通常不被視為簡單自動化的適當任務。
有一些方法可以在不重新啟動的情況下啟動新安裝的核心，但它們仍然不是真正的主流方法。
至於是否應該進行核心更新，一般來說是的。鑑於由於軟體過時而導致的一連串高調的安全故障（而且高調的故障可能只是冰山一角），所有軟體都應該保持最新。最近的 Meltdown 和 Spectre 漏洞強調核心並不特殊，需要像任何其他軟體包一樣保持最新。
考慮到在此過程中可能發生的故障與未完成時可能發生的故障之間的權衡，維護有效的修補策略需要認真考慮。自動化當然會有所幫助，但每個環境都不同，因此您必須檢查自己的要求，以評估它在多大程度上適合您自己的情況。
無論哪種方式，如果你說：
（一個發行版本身——它的核心、外殼和內部實用程序根本沒有改變的系統）
你的意思是一旦安裝，你永遠不會重新訪問和修補/更新/升級這些元素，你會大大增加你的系統被破壞的風險。