Häufig gestellte Fragen zu Bottlerocket

AWS stellt ein Amazon Machine Image (AMI) für Bottlerocket bereit, das Sie zur Ausführung auf unterstützten EC2-Instance-Typen über die AWS-Konsole, CLI und das SDK verwenden können. AWS stellt Bottlerocket-Builds bereit, die für die Verwendung mit EKS, ECS, VMware und EKS Anywhere auf Bare Metal vorkonfiguriert sind. Sie können den Orchestrator verwenden, um das Betriebssystem mit minimalen Unterbrechungen zu aktualisieren und zu verwalten, ohne sich bei jeder Betriebssystem-Instance anmelden zu müssen.

Sie können containerisierte Anwendungen auf einer Bottlerocket-Instanz über Ihren Orchestrator starten. Sie können auch während der Bildanpassung Ihre Software und Startup-Skripte in Bottlerocket einschließen. Weitere Einzelheiten finden Sie in der Dokumentation zu Bottlerocket.

Sie können Bottlerocket mithilfe der folgenden Schritte bereitstellen und warten:

• Schritt 1: Sie können Bottlerocket wie jedes andere Betriebssystem in einer virtuellen Maschine bereitstellen. Auf AWS können Sie Bottlerocket über API oder über AWS CLI auf EC2-Instances von der AWS-Managementkonsole bereitstellen. Sie müssen Konfigurationsdetails über Benutzerdaten für jede Bottlerocket-Instance bereitstellen, um sich bei einem Amazon-EKS-Cluster anzumelden.
• Schritt 2: Um Bottlerocket mit Ihrem Orchestrator zu betreiben, müssen Sie eine Integrationskomponente in Ihrem Cluster bereitstellen. Die Integrationskomponente ermöglicht es dem Orchestrator, Neustarts, Rollback-Aktualisierungen und das Ersetzen von Containern für Rolling-Aktualisierungen minimal zu initiieren.

Bottlerocket-Aktualisierungen werden automatisch von vorkonfigurierten AWS-Repositorys heruntergeladen, wenn sie verfügbar sind. Ein Neustart von Bottlerocket ist zum Anwenden von Aktualisierungen erforderlich und kann entweder manuell initiiert oder vom Orchestrator wie Kubernetes verwaltet werden. Sie müssen den geeigneten Mechanismus auswählen, um Neustarts basierend auf der Toleranz Ihrer Anwendungen gegenüber Neustarts und Ihren Betriebsanforderungen zu handhaben. Wenn Ihre Anwendung zustandslos und widerstandsfähig gegen Neustarts ist, können Neustarts sofort nach dem Herunterladen von Aktualisierungen durchgeführt werden. Wenn Sie zustandsbehaftete traditionelle Workloads (z. B. Datenbanken, Branchenanwendungen mit langer Laufzeit usw.) in Containern ausführen, die nicht gegen Neustarts widerstandsfähig sind, müssen Sie sicherstellen, dass dieser Zustand vor Neustarts beibehalten wird.

Bottlerocket-Neustarts können von Orchestratoren verwaltet werden, indem Container auf allen Hosts geleert und neu gestartet werden, um fortlaufende Aktualisierungen in einem Cluster zu ermöglichen und Unterbrechungen zu reduzieren. Aktualisierungen für Bottlerocket können auch im Fehlerfall über unterstützte Orchestratoren oder mit manuellen Maßnahmen sicher zurückgesetzt werden. Schritte zum Bereitstellen und Verwenden des „Bottlerocket-Aktualisierungs-Operators“ in Amazon-EKS-Clustern und in Amazon-ECS-Clustern finden Sie in der Dokumentation zu Bottlerocket.

Von AWS bereitgestellte Builds von Bottlerocket-Builds folgen einem semantischen Versionsverwaltungsschema „major.minor.patch“. Nebenversionen von Bottlerocket werden mehrmals im Jahr mit Änderungen wie der Unterstützung für neue EC2-Plattformen, Unterstützung für neue Orchestrator-Agenten und Aktualisierungen von Open-Source-Komponenten veröffentlicht. Das Versionsschema zeigt an, ob die Aktualisierungen grundlegende Änderungen enthalten.

Eine Variante ist ein Build von Bottlerocket, das unterschiedliche Funktionen oder Integrationsmerkmale unterstützt. AWS bietet Bottlerocket-Varianten, die Kubernetes-Worker-Knoten in EC2, in VMware und auf Bare Metal unterstützen. AWS bietet auch Bottlerocket-Varianten für ECS in EC2. Sie können die Liste aller von AWS bereitgestellten Varianten einsehen.

Ja. Bottlerocket verfügt über Varianten, die NVIDIA-GPU-basierte Amazon EC2-Instance-Typen auf Amazon Elastic Container Services (Amazon ECS) und auf Kubernetes-Worker-Knoten in EC2 unterstützt. Bitte lesen Sie die Blog-Beiträge zur Verwendungsweise dieser Varianten in ECS und in EKS.

Bottlerocket-Funktionsveröffentlichungen (Nebenversionen, z. B. 1.10.0, 1.11.0) werden in der Regel in Abständen von 6 bis 8 Wochen veröffentlicht. Fehler- und CVE-Fixes (Patch-Versionen, z. B. 1.10.1, 1.11.1) werden nach Bedarf behoben, und die Häufigkeit der Veröffentlichungen hängt vom Schweregrad des Problems ab. Im CHANGELOG finden Sie alle Bottlerocket-Releases mit dem jeweiligen Zeitpunkt der Veröffentlichung.

Von AWS bereitgestellte Builds von Bottlerocket erhalten Sicherheitsaktualisierungen, Fehlerbehebungen und sind durch AWS-Supportpläne abgedeckt. Der Supportzeitraum für einen bestimmten Build hängt von der Version des verwendeten Container-Orchestrators ab. Bottlerocket-Builds werden verworfen, wenn die entsprechende Orchestrator-Version veraltet ist. Beispielsweise unterstützen wir aws-k8s-1.19 nicht mehr, das ist der Bottlerocket-Build für Kubernetes 1.19. Dies steht im Einklang mit Kubernetes 1.19, das keinen Support mehr im Upstream erhält. Wir empfehlen, dass Kunden aws-k8s-1.19-Knoten durch einen neueren Build zu ersetzen, der von Ihrem Cluster unterstützt wird. Darüber hinaus ist der Community-Support für Bottlerocket auf GitHub verfügbar. Dort können Sie Fragen stellen, Anfragen im Zusammenhang mit Features stellen und Fehler melden. Details zu Releases und Fehlerbehebungen für CVEs werden im Bottlerocket-Änderungsprotokoll veröffentlicht.

Die aktuellen EKS-optimierten AMIs, die auf Amazon Linux basieren, werden unterstützt und erhalten weiterhin Sicherheitsaktualisierungen. Weitere Einzelheiten zur Support-Dauer finden Sie unter EKS-optimiertes Amazon-Linux-2-AMI und ECS-optimiertes AMI.

Bottlerocket-Builds von AWS werden in HVM- und EC2-Bare-Metal-Instance-Familien unterstützt, mit Ausnahme der F-, G4ad- und INF-Instance-Typen.

Ja. Weitere Einzelheiten finden Sie in diesem Blog-Eintrag.

AWS bietet vorab getestete Aktualisierungen für Bottlerocket, die in einem einzigen Schritt angewendet werden. Diese Aktualisierungen können auch in einem einzigen Schritt auf einen bekannten guten Zustand zurückgesetzt werden. Infolgedessen treten bei Bottlerocket keine „verpfuschten“ Aktualisierungen auf, die das System aufgrund inkonsistenter Zustände, die eine manuelle Reparatur erfordern, unbrauchbar machen können. Bei atomaren Aktualisierungen in einem Schritt ist die Komplexität geringer, wodurch Aktualisierungsfehler reduziert werden.

Aktualisierungen für von AWS bereitgestellte Builds von Bottlerocket werden automatisch aus vorkonfigurierten AWS-Repositorys heruntergeladen, wenn sie verfügbar sind. Ein Neustart von Bottlerocket ist zum Anwenden von Aktualisierungen erforderlich und kann entweder manuell initiiert oder vom Orchestrator wie Kubernetes verwaltet werden. Sie müssen den geeigneten Mechanismus auswählen, um Neustarts basierend auf der Toleranz Ihrer Anwendungen gegenüber Neustarts und Ihren Betriebsanforderungen zu handhaben. Wenn Ihre Anwendung zustandslos und widerstandsfähig gegen Neustarts ist, können Neustarts sofort nach dem Herunterladen von Aktualisierungen durchgeführt werden. Wenn Sie zustandsbehaftete traditionelle Workloads (z. B. Datenbanken oder Branchenanwendungen mit langer Laufzeit) in Containern ausführen, die nicht gegen Neustarts widerstandsfähig sind, müssen Sie sicherstellen, dass dieser Zustand vor dem Neustart beibehalten wird.

Bottlerocket-Neustarts können von Orchestratoren wie Kubernetes verwaltet werden, indem Container auf allen Hosts geleert und neu gestartet werden, um fortlaufende Aktualiseirungen in einem Cluster zu ermöglichen und Unterbrechungen zu reduzieren. Standardmäßig aktualisiert Bottlerocket beim Booten automatisch auf die neueste sichere Version. Aktualisierungen für Bottlerocket können auch im Fehlerfall über unterstützte Orchestratoren oder mit manuellen Maßnahmen sicher zurückgesetzt werden.

Die Integration mit Orchestratoren wie Kubernetes trägt dazu bei, dass Aktualisierungen für Bottlerocket minimal störend sind. Während des Aktualisierungsprozesses leert der Orchestrator Container auf den zu aktualisierenden Hosts und platziert sie auf anderen freien Hosts im Cluster. Der Orchestrator führt auch ein Rollback der Hosts auf die vorherige Version von Bottlerocket durch, wenn Aktualisierungen fehlschlagen.

Bottlerocket kann alle Container-Images ausführen, die die Spezifikation des OCI-Image-Formats erfüllen, sowie Docker-Images.

Ja, Sie können Ihre Container ohne Änderungen zwischen Amazon Linux 2 und Bottlerocket verschieben.

Wenn Ihre betrieblichen Workflows zum Ausführen von Containern die Installation von Software auf dem Host-Betriebssystem mit yum, das direkte ssh in Instances, die individuelle Anpassung jeder Instance oder das Ausführen von nicht containerisierter ISV-Software von Drittanbietern (z. B. Agenten für Protokollierung und Überwachung) umfassen, könnte Amazon Linux 2 die besser passende Option sein. Bottlerocket ist für die Ausführung und Verwaltung großer containerisierter Bereitstellungen optimiert und lässt viele dieser Aktivitäten nicht ohne weiteres zu.

Sie können einen „Administrator-Container“ mit der API von Bottlerocket ausführen (aufgerufen über Benutzerdaten oder AWS Systems Manager) und sich dann mit SSH für erweitertes Debugging und Fehlerbehebung mit erhöhten Rechten anmelden. AWS bietet den Administrator-Container, mit dem Sie Debugging-Tools wie sosreport, traceroute, strace, tcpdump installieren und verwenden können. Die Anmeldung bei einer einzelnen Bottlerocket-Instance soll ein seltener Vorgang für erweitertes Debugging und Fehlerbehebung sein.

Ein Administrator-Container ist ein Amazon-Linux-Container-Image, das Hilfsprogramme für die Fehlerbehebung und das Debugging von Bottlerocket enthält und mit erhöhten Rechten ausgeführt wird. Bitte lesen Sie die Details zur Verwendungsweise des Admin-Containers.

Bottlerocket ermöglicht automatische Sicherheitsaktualisierungen und reduziert das Risiko von Sicherheitsangriffen, indem nur die erforderliche Software zum Hosten von Containern verwendet wird. Bottlerocket verwendet Container-Kontrollgruppen (cgroups) und Kern-Namespaces zur Isolierung zwischen Containern. Es kommt auch mit Security-Enhanced Linux (SELinux) im Durchführungsmodus und seccomp. eBPF im Kern reduziert den Bedarf an Kern-Modulen für viele Systemoperationen auf niedriger Ebene, indem es ein Nachverfolgungs-Framework mit geringem Overhead für die Nachverfolgung von I/O, Dateisystem-Operationen, CPU-Auslastung, Eindringungserkennung und Fehlerbehebung bereitstellt. Bottlerocket nutzt device-mapper-verity (dm-verity), ein Feature des Linux-Kernels, das Integritätsprüfungen ermöglicht, damit Root-Kits keine Root-Rechte behalten.

Es gibt mehrere Möglichkeiten, Protokolle von Bottlerocket-Knoten zu sammeln. Beispielsweise können Sie dafür CloudWatch Container Insights oder Fluent Bit mit OpenSearch verwenden.

Ja, Bottlerocket hat einen CIS-Benchmark. Der CIS-Benchmark ist ein Katalog an sicherheitsorientierten Konfigurationseinstellungen, der Bottlerocket-Kunden dabei unterstützt, alle nicht konformen Konfigurationen auf einfache und effektive Art zu konfigurieren oder dokumentieren. Die CIS-Benchmark für Bottlerocket beinhaltet Konfigurationsprofile der Ebenen 1 und 2 und ist über die CIS-Website zugänglich.

Nein, Bottlerocket verfügt noch nicht über eine FIPS-Zertifizierung. Die FIPS-Zertifizierung für Bottlerocket steht auf unserer Roadmap, aber im Moment können wir noch nicht abschätzen, wann sie verfügbar sein wird.

Ja, Sie können mit Bottlerocket PCI-Konformität erreichen. Der optimierte Funktionsumfang und die reduzierte Angriffsfläche bedeuten, dass Bottlerocket-Instanzen weniger Konfiguration benötigen, um die PCI DSS-Anforderungen zu erfüllen. Die CIS-Benchmark für Bottlerocket ist eine hervorragende Ressource für Hilfestellung zur Absicherung (Hardening). Sie unterstützt die Kundenanforderungen für sichere Konfigurationsstandards gemäß PCI-DSS-Anforderung 2.2. Außerdem können Kunden Fluent Bit nutzen, um die Kundenanforderungen für die Protokollierung von Prüfungen auf Betriebssystemebene gemäß PCI-DSS-Anforderung 10.2 zu erfüllen. AWS veröffentlicht regelmäßig neue (gepatchte) Bottlerocket-Instances, um Kunden bei der Erfüllung der PCI-DSS-Anforderung 6.2 (für v3.2.1) und der Anforderung 6.3.3 (für v4.0) zu unterstützen.

Ja, Bottlerocket ist eine HIPAA-fähige Funktion, die für die Verwendung mit regulierten Workloads für Amazon EC2 und Amazon EKS autorisiert ist. Weitere Hilfestellung zur Konfiguration von Amazon EKS finden Sie in diesem Whitepaper.

Weitere Informationen finden Sie im Leitfaden zur Absicherung (Hardening) und Validierung von Bottlerocket, wenn es mit Amazon EKS verwendet wird.

Ja. Amazon Inspector ist ein Service zur Verwaltung von Sicherheitsschwachstellen, der EC2- und Container-Workloads kontinuierlich auf Softwareschwachstellen und unbeabsichtigte Netzwerkrisiken scannt. Amazon Inspector nutzt den AWS System Manager (SSM)-Agent zum Scannen von Schwachstellen. Der SSM-Agent wird bei Bottlerocket-Hosts im Container des Control-Hosts ausgeführt, daher müssen Sie sicherstellen, dass er auf Ihren Hosts aktiviert ist.

Bottlerocket-Code ist unter Apache 2.0 oder MIT lizenziert. Amazon hat Bottlerocket in Rust geschrieben, daher haben wir eine Lizenz ausgewählt, die sich leicht in diese Community einfügt. Der zugrunde liegende Code von Drittanbietern, wie der Linux-Kern, unterliegt weiterhin seiner ursprünglichen Lizenz.

Bottlerocket wurde als Open-Source-Projekt veröffentlicht, das auf GitHub gehostet wird. Designdokumente, Code, Build-Tools, Tests und Dokumentation werden auf GitHub gehostet. Wir werden die Fehler- und Funktions-Verfolgungs-Systeme von GitHub für die Projektverwaltung verwenden. Sie können den Quellcode von Bottlerocket mithilfe von Standard-GitHub-Workflows anzeigen und dazu beitragen.

Sie können das GitHub-Repository abspalten, Änderungen vornehmen und unserem Entwicklungsleitfaden folgen.

Ja. Wenn Sie Bottlerocket aus einer unveränderten Quelle erstellen und die Ergebnisse weiterverbreiten, dürfen Sie „Bottlerocket“ nur verwenden, wenn sowohl im Namen Ihrer Distribution als auch im damit verbundenen Inhalt klar ist, dass Ihre Distribution Ihr Build von Amazons Bottlerocket und nicht der offizielle Build ist und Sie müssen den Commit angeben, aus dem es erstellt wurde, einschließlich des Commit-Datums.

Sie müssen die BS-Release-Datei ändern, um Bottlerocket entweder gemäß dieser Richtlinie zu nutzen oder um die Bottlerocket-Warenzeichen zu entfernen. Dies kann durch Ändern von packages/release/release.spec und tools/rpm2img erfolgen. Namen des System-Roots (/x86_64-bottlerocket-linux-gnu/sys-root), Partitionsbezeichnungen, Verzeichnispfade und Service-Dateibeschreibungen müssen nicht geändert werden, um dieser Richtlinie zu entsprechen.

Wenn Ihnen eine verwirrende oder irreführende Verwendung oder ein sonstiger Missbrauch der Bottlerocket-Warenzeichen bekannt ist, können Sie uns wie oben beschrieben unter trademarks@amazon.com kontaktieren, damit wir weitere Nachforschungen anstellen können.