Bottlerocket 常見問答集

AWS 為 Bottlerocket 提供 Amazon Machine Image (AMI)，您可以使用它從 AWS Console、CLI 和開發套件在支援的 EC2 執行個體類型上執行。AWS 將提供 Bottlerocket 建置，其已預先設定為搭配 EKS、ECS、VMware 及裸機上的 EKS Anywhere 使用。您可以使用協調器，以最短的中斷時間更新和管理作業系統，而不必登入每個作業系統執行個體。

您可透過協調器，在 Bottlerocket 執行個體上啟動容器化應用程式。您還可以在影像自訂期間將軟體和啟動指令碼包含到 Bottlerocket 中。請參閱 Bottlerocket 文件以取得詳細資訊。

您可以使用下列步驟來部署和維修 Bottlerocket：

• 第 1 步：您可以像在虛擬機器中部署任何其他作業系統一樣部署 Bottlerocket。在 AWS 上，您可以從 AWS 管理主控台，透過 API 或透過 AWS CLI 將 Bottlerocket 部署至 EC2 執行個體。您需要透過使用者資料為每個 Bottlerocket 執行個體提供組態詳細資訊，以註冊到 Amazon EKS 叢集。
• 步驟 2：若要與協調器一起運作 Bottlerocket，您需要將整合元件部署至您的叢集。整合元件使協調器能夠以干擾性最小的方式啟動重新啟動、回復更新和取代容器以進行輪流升級。

Bottlerocket 更新會在可用時自動從預先設定的 AWS 儲存庫中下載。需要重新啟動 Bottlerocket 來套用更新，可手動起始或由 Kubernetes 之類的協調器進行管理。您需要選擇適當的機制，以根據應用程式對重新啟動的容忍度和營運需要來處理重新啟動。如果您的應用程式為無狀態且可彈性地重新啟動，則可在下載更新後立即執行重新啟動。如果您在對重新啟動沒有彈性的容器中執行有狀態的傳統工作負載 (例如，資料庫、長期執行的業務線應用程式等)，則需要確保在重新啟動之前保留狀態。

Bottlerocket 重新啟動可由協調器管理，方法是跨主機排空和重新啟動容器，從而在叢集中啟用輪流更新以減少中斷。如果透過支援的協調器或手動動作發生故障，也可以安全地回復 Bottlerocket 的更新。如需在 Amazon EKS 叢集和 Amazon ECS 叢集上部署和使用「Bottlerocket 更新運算子」的步驟，請參閱 Bottlerocket 文件。

AWS 提供的 Bottlerocket 建置遵循 “major.minor.patch” 語義版本控制方案。Bottlerocket 的次要版本將在一年中多次發佈，其中包含對新 EC2 平台的支援、對新協調器代理程式的支援以及對開源元件的更新等變更。版本方案將指示更新是否包含重大變更。

變體是一種支援不同功能或整合特性 Bottlerocket 建置版本。AWS 提供支援 EC2、VMware 及裸機上的 Kubernetes 工作節點的 Bottlerocket 變體。AWS 還在 EC2 中為 ECS 提供 Bottlerocket。您可以查看所有 AWS 提供的變體清單。

是。Bottlerocket 在 EC2 的 Amazon Elastic Container Services (Amazon ECS) 和 Kubernetes 工作節點上，有支援 NVIDIA GPU 型 Amazon EC2 執行個體類型的變體。請參閱有關如何在 ECS 和 EKS 上使用這些變體的部落格文章。

Bottlerocket 功能版本 (次要版本，例如 1.10.0、1.11.0) 通常以 6 到 8 週的節奏發行。錯誤和 CVE 修正 (修補程式版本，例如 1.10.1、1.11.1) 會視需要進行發行，並且發行節奏視問題的嚴重程度而定。請參閱 CHANGELOG，其中顯示了所有 Bottlerocket 發行版本及其時間表。

AWS 提供的 Bottlerocket 建置將接受安全性更新、錯誤修正，且包含在 AWS Support 計劃中。指定建置的支援期間將視所使用的容器協調器版本而定。對應的協調器版本被取代時，Bottlerocket 建置也將被取代。例如，我們不再支援 aws-k8s-1.19，這是適用於 Kubernetes 1.19 的 Bottlerocket 建置。這與 Kubernetes 1.19 不再接受上游支援一致。我們建議客戶將 aws-k8s-1.19 節點取代為您的叢集支援的最新建置。此外，GitHub 上提供了對 Bottlerocket 的社群支援，您可以在其中發佈問題、功能請求和報告錯誤。有關 CVE 發行和修正的詳細資訊將發佈在 Bottlerocket 變更日誌中。

目前基於 Amazon Linux 的 EKS 最佳化的 AMI 將受支援且繼續接受安全更新。如需支援生命週期的詳細資訊，請參閱 EKS 最佳化的 Amazon Linux 2 AMI 和 ECS 最佳化的 AMI。

除了 F、G4ad 和 INF 執行個體類型之外，HVM 和 EC2 裸機執行個體系列支援來自 AWS 的 Bottlerocket 建置。

是。請參閱這篇部落格文章，以進一步了解詳細資訊。

AWS 針對 Bottlerocket 提供預先測試的更新，只需一個步驟即可套用。這些更新也可在單一步驟中回復至已知良好狀態。因此，Bottlerocket 不會發生由於需要手動修復的狀態不一致而導致系統無法使用的「失敗」更新。使用單一步驟原子更新時，複雜性較低，進而減少更新失敗情況。

AWS 提供的 Bottlerocket 建置的更新會在可用時自動從預先設定的 AWS 儲存庫中下載。需要重新啟動 Bottlerocket 來套用更新，可手動起始或由 Kubernetes 之類的協調器進行管理。您需要選擇適當的機制，以根據應用程式對重新啟動的容忍度和營運需要來處理重新啟動。如果您的應用程式為無狀態且可彈性地重新啟動，則可在下載更新後立即執行重新啟動。如果您在對重新啟動沒有彈性的容器中執行有狀態的傳統工作負載 (例如，資料庫或長期執行的業務線應用程式)，則需要確保在重新啟動之前保留狀態。

Bottlerocket 重新啟動可由 Kubernetes 等協調器管理，方法是跨主機排空和重新啟動容器，從而在叢集中啟用輪流更新以減少中斷。依預設，Bottlerocket 將在啟動時自動更新至最新安全版本。如果透過支援的協調器或手動動作發生故障，也可以安全地回復 Bottlerocket 的更新。

與 Kubernetes 這樣的協調器整合可讓 Bottlerocket 更新的中斷時間最短。更新程序期間，協調器會排空正在更新的主機上的容器，並將其置於叢集中的其他閒置主機上。如果更新失敗，協調器還會將主機回復至 Bottlerocket 的上一個版本。

Bottlerocket 可執行所有符合 OCI 映像格式規範和 Docker 映像檔的所有容器映像。

可以，您可以在 Amazon Linux 2 和 Bottlerocket 之間移動容器，而無需進行任何修改。

如果要執行容器的營運工作流程設計在主機作業系統上使用 yum 安裝軟體、直接 SSH 至執行個體、個別自訂每個執行個體，或執行非容器化的第三方 ISV 軟體 (例如，用於記錄和監控的代理程式)，則 Amazon Linux 2 可能非常適合。Bottlerocket 經過最佳化，可執行和管理大型容器化部署，且不會輕易允許許多這些活動。

您可以使用 Bottlerocket 的 API (透過使用者資料或 AWS Systems Manager 叫用) 執行「管理員容器」，然後使用 SSH 登入，以使用較高的權限進行進階偵錯和疑難排解。AWS 提供的管理員容器可讓您安裝和使用 sosreport、traceroute、strace、tcpdump 等偵錯工具。不會頻繁登入個別 Bottlerocket 執行個體來進行進階偵錯和疑難排解。

管理員容器是一種 Amazon Linux 容器映像，包含用於疑難排解和偵錯 Bottlerocket 的公用程式，且可以較高的權限執行。請參閱有關如何使用管理員容器的詳細資訊。

Bottlerocket 可透過僅包含託管容器的必要軟體，進而實現自動安全性更新並減少遭受安全攻擊的風險。Bottlerocket 使用容器控制群組 (cgroups) 和內核命名空間來隔離容器之間。它還帶有處於強制模式和 seccomp 的安全增強 Linux (SELinux)。核心中的 eBPF 透過提供用於追蹤 I/O、檔案系統操作、CPU 使用率、入侵偵測和疑難排解的低開銷追蹤架構，減少了許多低級系統操作對核心模組的需求。Bottlerocket 使用 device-mapper-verity (dm-verity)，這是一種 Linux 核心功能，它提供完整性檢查，以協助防止可以保留根權限的 Rootkit。

有多種選項可從 Bottlerocket 節點收集日誌。例如，可以使用 CloudWatch Container Insights 或 Fluent Bit with OpenSearch。

是的，Bottlerocket 有 CIS 基準。CIS Benchmark 是注重安全的組態設定型錄，可協助 Bottlerocket 客戶以簡單而有效的方式，來設定或記錄任何不合規的組態。Bottlerocket 的 CIS 基準測試包括 1 級和 2 級組態設定檔，並且可以從 CIS 網站存取。

否，Bottlerocket 還沒有通過 FIPS 認證。我們的藍圖涵蓋了 Bottlerocket 的 FIPS 認證，但目前並未預計何時通過此認證。

是，可以使用 Bottlerocket 達到 PCI 合規性。最佳化功能集和減少的受攻擊面，意味著 Bottlerocket 執行個體需要較少的組態即可滿足 PCI DSS 需求。Bottlerocket 的 CIS 基準是強化指導的絕佳資源，可依據 PCI DSS 要求 2.2 版支援客戶對安全組態標準的要求。客戶也可以利用 Fluent Bit 來支援 PCI DSS 要求 10.2 版下的作業系統層級稽核記錄的客戶要求。AWS 會定期發佈新的 (已修補的) Bottlerocket 執行個體，以協助客戶滿足 PCI DSS 要求 6.2 (適用於 v3.2.1) 和要求 6.3.3 (適用於 v4.0)。

是，Bottlerocket 是符合 HIPAA 資格的功能，可與 Amazon EC2 和 Amazon EKS 的受管制工作負載搭配使用。如需有關 Amazon EKS 的組態指導，請參閱此白皮書以取得其他資訊。

請參閱有關強化和驗證 Bottlerocket 的指南 (在其與 Amazon EKS 搭配使用時)。

是。Amazon Inspector 是一項漏洞管理服務，可不斷掃描 EC2 和容器工作負載以尋找軟體漏洞和意外網路風險。Amazon Inspector 利用 AWS System Manager (SSM) 代理程式來掃描漏洞。在 Bottlerocket 主機中，SSM 代理程式會在控制主機容器範圍內執行，因此您需要確定已在主機中啟用此代理程式。

Bottlerocket 程式碼根據 Apache 2.0 OR MIT 取得授權。Amazon 在 Rust 中編寫 Bottlerocket，因此，我們選擇了可輕鬆適應該社群的授權。基礎第三方程式碼 (如 Linux 內核) 仍然受其原始授權的約束。

Bottlerocket 作為 GitHub 上託管的開放原始碼專案發行。設計文件、程式碼、建置工具、測試和文件將會託管於 GitHub 上。我們將使用 GitHub 的錯誤和功能追蹤系統進行專案管理。您可以使用標準 GitHub 工作流程來檢視和提供原始程式碼。

您可以延伸 GitHub 儲存庫，執行變更並按照我們的建置指南進行操作。

是。如果您從未修改的原始程式碼建置 Bottlerocket 並轉散佈結果，則只有在分發名稱和與其相關聯的內容都清楚的情況下，才可以使用「Bottlerocket」，並且必須確定其建置時的遞交，包括遞交日期。

您必須修改作業系統版本檔案，才能依據本政策使用 Bottlerocket，否則必須移除 Bottlerocket 商標。可以透過修改 packages/release/release.spec 和 tools/rpm2img 來完成此操作。您不需要變更系統根文件夾名稱 (/x86_64-bottlerocket-linux-gnu/sys-root)、分割區標籤、目錄路徑和服務檔案描述，即可符合此政策。

如果您發現對 Bottlerocket 商標有混淆或誤導性的使用或其他濫用，則可以透過以上所述與我們聯絡：[email protected]，以便我們進一步調查。