Anfang 2019 wurde Amazon-Corretto 8, eine kostenlose, plattformübergreifende Distribution von OpenJDK für Java 8 veröffentlicht. Kurz darauf kam Amazon-Corretto 11 für Java 11 hinzu. Amazon setzt intern Corretto bei Tausenden von produktiven Workloads ein und hat auf Basis dieser Erfahrung Verbesserungen hinsichtlich Sicherheit, Stabilität oder Leistung im OpenJDK-Projekt beigesteuert. In diesem Artikel betrachten wir genauer, welche spezifischen Vorteile Amazon-Corretto bietet.
Die Installation von Amazon-Corretto
Amazon-Corretto 11 ist als Headless-Variante verfügbar. Diese Variante enthält keine Laufzeitabhängigkeiten, die in der Regel mit GUI-Anwendungen wie X11 und ASLA verbunden sind, und ist für serverseitige Workloads sinnvoll. Im folgenden werden die Installationsanweisungen für Amazon-Linux 2 gezeigt. Amazon-Linux 2 ist die nächste Generation von Amazon-Linux, einem Linux-Server-Betriebssystem von Amazon-Web-Services (AWS). Es bietet eine sichere, stabile und hochleistungsfähige Ausführungsumgebung zur Entwicklung und Ausführung von Cloud- und Unternehmensanwendungen.
Option 1:
Installieren der Headless-Variante von Amazon-Corretto 11:
(Listing 1)
Option 2:
Installieren der vollständigen Variante von Amazon-Corretto 11:
(Listing 2)
/usr/lib/jvm/java-11-amazon-corretto.<cpu_arch> ist der Installationspfad für Amazon-Corretto. Für Debian-basierte und RPM-basierte Linux-Distributionen sind nachfolgende Installationsschritte notwendig: Im ersten Schritt muss die .rpm-Datei für Linux von der Download-Seite heruntergeladen und dann mithilfe von yum localinstall installiert werden.
(Listing 3)
Der Turbo für Crypto
In der Vergangenheit war die Java-Kryptographie langsam und sehr CPU-intensiv. Kryptografische Operationen in Java führen zu einer erheblichen CPU-Auslastung (Utilization), Engpässen beim Durchsatz und erhöhten Betriebskosten. Um diese Probleme zu lösen, wurde der Amazon-Corretto-Crypto-Provider (ACCP) entwickelt, in dem Dutzende von kryptografischen Algorithmen optimiert wurden. Die Leistungszuwächse variieren je nach Algorithmus und Arbeitsaufwand, aber in Benchmarks und in Produktion wurde eine Verbesserung des Durchsatzes von Services um mehr als 25% festgestellt. Im Allgemeinen profitieren langsamere Algorithmen und größere Datensätze am meisten von ACCP: der AES-GCM-Algorithmus mit ACCP ist über 28 Mal schneller als AES-GCM ohne ACCP. ACCP implementiert die Standard-Java-Cryptography-Architecture-Schnittstellen (JCA). Es ersetzt die Standard-Java-Kryptographie Implementierungen durch die, welche libcrypto aus dem OpenSSL-Projekt bereitstellt. Als Beispiel wurde der Auslastungsgraphen eines AWS-Dienstes ausgewählt, der Transport-Layer-Security (TLS) auf Host-Ebene terminiert. In der Grafik (Abb. 1) ist deutlich der Unterschied vor und nach der Verwendung von ACCP zu sehen.
Effekt der Nutzung von ACCP auf einem AWS-Service (Abb. 1)
Die Nutzung von ACCP ist sehr einfach. Im ersten Schritt muss die entsprechende Abhängigkeit in der pom.xml eingetragen werden, falls Maven genutzt wird (Listing 4).
(Listing 4)
Beim Bootstrapping der Anwendung müssen die notwendigen Klassen genutzt werden, dazu sollte möglichst früh im Programmcode die folgende Zeile eingetragen werden (Listing 5).
(Listing 5)
Um zu prüfen, ob ACCP auf dem System ordnungsgemäß funktioniert, kann eine der folgenden Aktionen durchgeführt werden.
Überprüfen, ob der Provider mit der höchsten Priorität tatsächlich ACCP ist (Listing 6):
(Listing 6)
Health-Check für ACCP durchführen (Listing 7)
(Listing 7)
Sicherstellen, dass ACCP korrekt funktioniert und eine RuntimeCryptoException werden, wenn dies nicht der Fall ist (Listing 8)
(Listing 8)
Amazon-Corretto im Container
Amazon-Corretto kann natürlich auch im Kontext von Containern genutzt werden. Dafür existiert ein Docker-Base-Image, das als Basis für eigene Docker-Images genutzt werden kann. Ein Dockerfile für eine Hello-World-Anwendung sieht folgendermaßen aus (Listing 9)
(Listing 9)
Um dieses Image zu bauen, muss das Kommando docker build -t hello-app ausgeführt werden. Die Ausführung dieses Images als Docker-Container wird in (Listing 10) aufgezeigt. Darüber hinaus ist es auch möglich, ein Docker-Image auf Basis des GitHub-Repositories zu bauen (Listing 11).
(Listing 10)
(Listing 11)
Nach dem erfolgreichen Bauen des Docker-Images befindet sich dieses lokal unter dem Nanem amazon-corretto-11. Mit dem Kommando docker run -it amazon-corretto-11 kann der Docker-Container gestartet werden. Das verwendete Dockerfile nutzt jlink, um nur die benötigten Pakete aus der JRE für eine eigene Runtime zu nutzen, was die JRE deutlich kompakter macht. In den meisten Fällen sind Pakete wie AWT oder Swing nicht notwendig. Zudem basiert das Base–Image auf Alpin-Linux, was sich nochmals positiv auf die Größe auswirkt.
Unterstützung für ARM64
Im Dezember 2019 hat AWS den M6g-Instanztyp veröffentlicht. Das “g” steht hier für Graviton2, die nächste Generation eines auf Arm basierenden Chips, der von AWS entwickelt wurde und 64-Bit-Arm-Neoverse-N1-Kerne nutzt. Amazon-Corretto wird auch für die ARM64-Prozessorarchitektur für Amazon-Linux 2 angeboten[1]. Die Installation ist identisch mit dem Vorgehen für die x64-Architektur. Diese Prozessoren unterstützen 256-Bit-DRAM-Verschlüsselung im Dauerbetrieb.
Die M6g-Instanzen sind in 8 Größen mit 1, 2, 4, 8, 16, 32, 48 und 64 vCPUs oder als Bare-Metal-Instanzen erhältlich. Sie unterstützen Konfigurationen mit bis zu 256 GB Speicher, 25 Gbit/s Netzwerkleistung und 19 Gbit/s EBS-Bandbreite. Diese Instanzen werden vom AWS-Nitro-System betrieben, einer Kombination aus dedizierter Hardware und einem leichtgewichtigen Hypervisor.
Typische Open-Source-Anwendungs-Stacks, die in der Regel auf x86-64-Architekturen eingesetzt werden, gehen durch die Migration auf Graviton2-basierte Instanzen mit einem bis zu 40% besseren Preis-Leistungs-Verhältnis im Vergleich zu ähnlich großen M5-Instanzen einher. M6g-Instanzen eignen sich gut für Workloads wie Application-Server, Gaming-Server, mittelgroße Datenbanken, Caching-Fleets, Web-Anwendungen und dergleichen.
Immer auf dem neuesten Stand
In vielen Fällen ist die automatisierte Aktualisierung von Anwendungen eine notwendige Anforderung, weil die Software direkt auf Server ausgeliefert wird, die beispielsweise mit Chef oder Puppet provisioniert werden. Der Release-Schedule von Amazon-Corretto orientiert sich an den Long-Term-Support-Releases (LTS) des OpenJDK. Ab OpenJDK 11 erscheinen zukünftige LTS-Releases im Drei-Jahres-Turnus, so dass die nächste Version OpenJDK17 im Jahre 2021 veröffentlicht werden wird. Die OpenJDK 11 Distribution Corretto 11 wird mindestens bis August 2024 vierteljährlich Updates erhalten.
Um die Kompatibilität mit der Java-SE-Plattform sicherzustellen, führt Amazon vor jedem Corretto-Release das Java-Technology-Compatibility-Kit (TCK) aus. Dabei handelt es sich um eine umfangreiche Testsuite, die von Oracle und Lizenznehmern verwendet wird, um kompatible Implementierungen der Java-Plattform sicherzustellen. Die Einschränkungen des OpenJDK gegenüber dem kommerziellem Oracle JDK bestehen natürlich auch bei Amazon-Corretto: Anwendungen, welche Funktionen nutzen, die in OpenJDK nicht verfügbar sind, wie zum Beispiel Java-Flight-Recorder, funktionieren nicht mit Corretto.
Aber nicht nur Major-Releases unterliegen einem Release-Plan: Zwischen den LTS-Releases erscheinen mindestens quartalsweise Updates. Diese Änderungen sind in der Corretto-Dokumentation[2] aufgeführt. Mit Amazon-Linux 2 sind zudem wichtige Updates auch im Amazon-Linux-Security-Center[3] ausgeführt. Die Aktualisierungen enthalten Performance-Verbesserungen und kritische Fehlerbehebungen für die Anwendungsentwicklung von Unternehmen. Aus diesem Grund sollten Änderungen kontrolliert, aber so zeitnah wie möglich ihren Weg in die Anwendung finden. Dazu existieren mehrere mögliche Vorgehensweisen, die im Folgenden kurz erläutert werden.
Beim initialen Start einer EC2-Instanz wird ein sogenanntes User-Data-Skript ausgeführt. Dadurch lassen sich Benutzerdaten an die Instanz übergeben, die man verwenden kann, um allgemeine automatisierte Konfigurationsaufgaben durchzuführen und nach dem Start der Instanzskripte auszuführen. Ein generelles Muster auf dem neuesten Stand zu bleiben, ist der Befehl in diesem Script am Beispiel von Amazon-Linux. Alle verfügbaren Updates werden damit zum frühestmöglichen Zeitpunkt installiert. Es besteht die Möglichkeit, nur sicherheitsrelevante Updates mit dem Zusatz – -security zu installieren.
(Listing 12)
Im Gegensatz zum eigenen Datacenter existieren EC2-Instanzen in vielen Fällen nicht für längere Zeit, denn sie können sehr einfach erzeugt und auch wieder terminiert werden. Eine Auto-Scaling-Gruppe enthält eine Sammlung von Amazon-EC2-Instanzen, die als logische Gruppierung zum Zweck der automatischen Skalierung und Verwaltung behandelt werden. In diesem Kontext werden Auto-Scaling-Groups eingesetzt: eine Auto-Scaling-Gruppe ermöglicht die Verwendung von Amazon-EC2-Auto-Scaling-Funktionen, wie beispielsweise Ersetzungen im Zuge von Zustandsprüfungen und Skalierungsrichtlinien.
Die zwei wichtigsten Funktionen des Amazon-EC2-Auto-Scaling-Services bestehen in der automatischen Skalierung und der Beibehaltung der Anzahl der Instanzen, falls beispielsweise bei einer EC2-Instanz Fehler auftreten sollten. Die Größe einer Auto-Scaling-Gruppe richtet sich nach der Anzahl der Instanzen, die als die gewünschte Kapazität definiert worden sind. Bei der Skalierung durch eine Auto-Scaling-Group wird somit das vorher definierte User-Data-Script ausgeführt, was zur Folge hat, dass die notwendigen Updates automatisiert eingespielt werden können.
Für einige Workloads sind kurze Startzeiten beim Auto-Scaling aufgrund eines Lastanstiegs entscheidend. Aus diesem Grund eignet sich auch die Erstellung eigener Amazon-Machine-Images (AMIs) mit Hilfe von AWS-Systems-Manager-Automation[4] oder zum Beispiel HashiCorp-Packer[5]. Ein AMI stellt die Informationen zur Verfügung, die zum Starten einer Instanz erforderlich sind.
Mit dem AWS-Systems-Manager und dessen vordefinierten Automation-Dokument AWS-UpdateLinuxAmi auf Basis eines Amazon-Linux-AMIs, ist die Erstellung eines AMIs denkbar einfach. Mit dem AWS-CLI wird die Automation wie in (Listing 13) gestartet. Das PostUpdateScript ist ein benutzerdefiniertes Skript mit Befehle. Der AWS-Systems-Manager führt die Befehle nach der Aktualisierung aller Pakete aber noch vor der Erstellung des AMIs aus. Das Skript enthält lediglich die Zeilen aus (Listing 14).
(Listing 13)
(Listing 14)
Nach dem erfolgreichen Erstellen des AMI, enthält die Ausgabe der Automation die ID des gebauten AMIs. Wird danach die Auto-Scaling-Group über AWS-CloudFormation auf dieses AMI angepasst, übernimmt AWS-CloudFormation das Ausrollen des AMIs automatisch. Der Vorteil dieser Variante ist, dass der genaue Stand der installierten Software in Code dokumentiert ist. So ist auch ein Zurückrollen auf eine ältere Version im Fehlerfall möglich. Es ist ein durchaus übliches Vorgehen, nach einem erfolgreichen Build einer neuen Softwareversion ein aktuelles AMI mit diesem Release zu erstellen und in der Auto-Scaling-Group die einzelnen Instanzen auszutauschen. Dieses Konzept nennt sich Immutable-Infrastructure.
Die letzte Variante zum Update kommt ins Spiel, wenn die Instanzen nicht regelmäßig neu gestartet werden sollen. In den aktuellen Standard-AMIs für Windows- und Amazon-Linus ist der AWS-Systems-Manager-Agent vorinstaliert. Dieser übernimmt die Aktualisierung der installierten Pakete[6] anhand einer Batch-Baseline, die im AWS-Systems-Manager-Patch-Manager für die jeweilige Instanz konfiguriert wurde.
Fazit:
Amazon bietet mit der OpenJDK-Distribution Corretto ein kostenfreies, plattformübergreifendes und produktionsreifes Drop-in-Replacement für bestehende OpenJDK-Distributionen an. Corretto wird für eine Vielzahl von unterschiedlichen Betriebssystemen und zwei Prozessor-Architekturen angeboten. Durch die langfristige Unterstützung der LTS-Releases ist ein hohes Maß an Stabilität und Planungssicherheit gegeben. Dennoch sollten regelmäßig wichtige Sicherheitsaktualisierungen installiert und getestet werden.
Sascha Möllering arbeitet seit mehr als 4 Jahren als Solutions-Architect und Solutions-Architect-Manager bei der Amazon Web Services EMEA SARL, Niederlassung Deutschland. Zuvor war er als Team-Lead und Software-Architect bei zanox in Berlin tätig. Er teilt seine Expertise mit dem Fokus auf die Bereiche Automation, Infrastructurre-as-aCode,, Distributed-Computing, Container und JVM regelmäßig in Beiträgen verschiedener IT-Magazine im deutschsprachigen Raum.