kalafoto - stock.adobe.com
Die Vorteile von Firecracker für Container-Apps
AWS Firecracker ist ein Tool zum Anlegen von Mikro-VMs für containerisierte Anwendungen. Wir haben einige wichtige Hinweise zum Einsatz in Ihrem Unternehmen zusammengetragen.
Mikro-VMs sind kleine virtuelle Maschinen, die einfach und in großen Mengen angelegt werden können. Dabei sind Mikro-VMs so ressourceneffizient wie Container, bieten aber dennoch die Isolation und Sicherheit vollständiger virtueller Maschinen. Ursprünglich war Firecracker ein zentrales internes Virtualisierungs-Tool bei AWS. Mit dieser Technologie wurden Dienste wie AWS Lambda und AWS Fargate umgesetzt. Im November 2018 setzte AWS für die Firecracker-Lösung ein Projekt auf, um die Entwicklung von Serverless-IT-Infrastrukturen zu unterstützen.
Firecracker und andere Mikro-VMs sind so konzipiert, dass sie modernen Entwicklungsmethoden wie Mikroservices entsprechen. Dies könnte allenfalls durch den Einsatz von VMs oder Containern behindert werden. Beispielsweise bieten VMs eine umfassende Isolierung und unterstützen ganze Workloads. Andererseits können VMs ressourcenintensiv und langsam sein. Container hingegen benötigen deutlich weniger Ressourcen und können schnell erstellt oder gelöscht werden. Dafür sind sie nicht so isoliert und betriebssystemunabhängig wie vollwertige VMs.
Firecracker im Überblick
AWS entwickelte Firecracker als sichere, mandantenfähige Alternative zu Containern. Firecracker setzt dazu einen Virtual Machine Monitor (VMM) – also einen Hypervisor – basierend auf KVM ein. Damit werden vollständig isolierte VMs angelegt. Firecracker wird daher oft mit anderen Maschinenemulatoren und Virtualisierungsplattformen wie QEMU in eine Kategorie eingeteilt.
Jede Mikro-VM, die unter Firecracker läuft, verbraucht etwa 5 MByte Speicher für den Overhead, obwohl leicht 128 MByte, 256 MByte oder mehr für jede Mikro-VM eingestellt werden könnte. Da sie klein sind und relativ wenige Ressourcen verbrauchen, kann man Firecracker Mikro-VMs auf Bare-Metal-Systemen in etwa 125 Millisekunden anlegen – und die Geschwindigkeit nimmt noch zu. Theoretisch ist es möglich, Tausende von Mikro-VMs auf einem einzigen Server einzusetzen. Durch die kurze Anlaufzeit eignen sie sich gut für wechselnde oder kurzlebige Workloads. Damit soll Firecracker mit den Containertechnologien konkurrieren.
Zur Verwaltung von Firecracker sowie zur Bereitstellung von vCPU-, Speicher-, Netzwerk- und Speicherressourcen wird eine RESTful API genutzt. Die RESTful API kann die Mikro-VMs auch starten oder stoppen, Metadaten zwischen Host- und Gastbetriebssystem konfigurieren und die Protokollierung einrichten. Administratoren können die API auch verwenden, um Beschränkungen für die von Mikro-VMs verwendeten Speicher- und Netzwerkressourcen festzulegen. Das verhindert, dass eine oder mehrere Mikro-VMs die I/Os des Systems okkupieren und die Leistung anderer Mikro-VMs beeinträchtigen.
Die VMs von Firecracker sind minimalistisch. Alle unnötigen Geräte und Funktionen wurden eliminiert. Der Speicherbedarf und die potenziellen Angriffsvektoren für jede Mikro-VM werden dadurch reduziert. AWS schrieb auch Firecracker in Rust, das helfen soll, die Threads zu schützen und häufige Schwachstellen wie Buffer-Overruns zu stoppen. Darüber hinaus wird der Firecracker-Prozess „jailed", also eingesperrt, um die Zugriff zu beschränken und nur eine geringe Anzahl von Systemaufrufen zuzulassen.
Das Verfahren hat außerdem hinsichtlich der Funktionsfähigkeit und Sicherheit bewährt, weil AWS damit bereits intern mehrere datenintensive Dienste betreibt.
Voraussetzungen für Firecracker
Benutzer können Firecracker auf AWS-Bare-Metal-Instanzen sowie anderen lokalen Bare-Metal-Servern, Laptops und anderer Hardware ausführen.
Große Vorarbeiten sind für Firecracker typischerweise nicht nötig. Firecracker unterstützt Linux x86_64 Hosts mit Kernel Version 4.14 oder höher. Benutzer können Firecracker jedoch auch auf AWS mit einer i3.metal-Instanz mit Ubuntu 18.04 oder höher laufen lassen. Firecracker benötigt auch Lese-/Schreibzugriff auf KVM, den Benutzer zuerst im Linux-Kernel aktivieren und über eine Linux-Sudo-Befehlszeile konfigurieren müssen.
Als nächstes können Benutzer die neuesten Firecracker-Binaries von GitHub beziehen. Da die Firecracker-Binärdateien keine anderen Abhängigkeiten haben, können Benutzer diese direkt auf dem x86_64-Linux-Rechner ausführen. Unternehmen, die sich für eine Kompilierung oder Änderung der Firecracker-Codebasis entscheiden, können den Quellcode aus dem GitHub-Repository klonen.
Firecracker starten
Der eigentliche Einsatz von Firecracker ist etwas aufwändiger. Sobald die Firecracker-Binärdateien verfügbar sind, benötigen Benutzer eine unkomprimierte Linux-Kernel-Binary als Gastbetriebssystem sowie ein ext4-Dateisystem-Image als Root-Dateisystem. AWS stellt für Testzwecke herunterladbare Binärdateien eines Kernels und eines Root-Dateisystems zur Verfügung.
Firecracker eignet sich für Produktionsumgebungen, solange das Tool innerhalb eines abgesicherten Umgebung mit einer gekapselten Binary, wie zum Beispiel Firecracker Jailer v0.14.0, ausgeführt wird. Eine solche Absicherung bietet der Mikro-VM mehr Sicherheit und Schutz vor Angriffen und Schadsoftware (und wird für Test- und Evaluierungszwecke nicht unbedingt benötigt).
Zum Starten ist eine Shell zu öffnen und auszuführen. Eine zweite Shell benötigen Sie zum Schreiben Ihrer Anpassungen in die API. Beide Shells müssen im gleichen Verzeichnis wie die Firecracker-Binary laufen. Verwenden Sie die zweite Shell, um den Kernel des Gastbetriebssystems und das Gast-Root-Dateisystem zu bestimmen. Anschließend starten Sie die Gastmaschine. Kehren Sie nun zur ersten Shell zurück und melden Sie sich auf der Gastmaschine an.
Standardmäßig verfügt die Gast-Mikro-VM über eine vCPU und 128 MB Speicher, wobei Sie die Zuweisung der Ressourcen über die API vor dem Start jeder Instanz anpassen können.
Die Mikro-VMs können nicht neu gestartet werden. Will jemand die Gastmaschine neu starten, fährt Firecracker die Mikro-VM herunter. Auf diese Weise können Mikro-VMs gut für Anwendungen und Dienste geeignet sein, deren Infrastrukturen nicht verändert werden darf oder soll.
Das bringt die Zukunft
Das Firecracker-Projekt befindet sich noch in der Anfangsphase, aber die Open-Source-Community hat bereits mit der Entwicklung weitere Funktionen und Leistungsmerkmale begonnen. Die aktuelle Firecracker-Roadmap in GitHub enthält eine ganze Reihe neuer Funktionen, wie zum Beispiel die Unterstützung verschachtelter (nested) Virtualisierung und mehr Speicherverschlüsselung. Man hofft in der Community, Firecracker noch stärker zu automatisieren sowie AMD- und ARM-Chips, Kubernetes, Docker, Kata-Container und mehr zu unterstützen.
Es ist noch nicht klar, wann oder ob alle in der Roadmap angekündigten Funktionen schlussendlich in die eigentliche Firecracker-Lösung implementiert werden. Die ehrgeizigen Ziele sind jedoch gute Indikatoren für die Begeisterung der Open-Source-Community und für das Potenzial von Firecracker. Firecracker wird seinen Platz unter den VMs und Containern im Software-Park für Enterprise Virtualization einnehmen.