Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Technische Domains
Dieser Abschnitt bietet einen Überblick über die wichtigsten Technologie-Domains für die Containerisierung. Das folgende Diagramm zeigt die Architektur einer herkömmlichen Java-EE-Anwendung.
Das folgende Diagramm zeigt die Architektur einer containerisierten Java-EE-Anwendung.
1. Status der Sitzung
In den meisten Fällen speichern Java-EE-Anwendungen die Sitzungsdaten, die mit Benutzeranfragen verknüpft sind, z. B. Cookies für Servlets und Stateful-Sitzungen von Enterprise Java Beans (EJB). Wir empfehlen, Zustandsinformationen nicht im JVM-Speicher (Java Virtual Machine) zu speichern, da Ihr Container zustandslos bleiben muss. Weitere Informationen zum Verfügbarkeitsprinzip finden Sie unter Prinzipien des Container-basierten Anwendungsdesigns
Der Arbeitsspeicherreplikationsmechanismus geht davon aus, dass immer eine bestimmte Gruppe von Servern im Cluster vorhanden ist oder dass eine kleine Anzahl von Servern dem Cluster beitritt oder ihn verlässt. Dies ist mit einer Containerumgebung nicht kompatibel. Wir empfehlen daher, den Arbeitsspeicherreplikationsmechanismus zu deaktivieren. In einer Containerumgebung werden die Anwendungsserver neu bereitgestellt, wenn eine neue Version des Container-Images erstellt wird. Das heißt, alle replizierten Arbeitsspeicherdaten werden ebenfalls gelöscht.
2. Kundendienstmitarbeiters (Kundendienstmitarbeiter)
Auf einem einzigen physischen oder virtuellen Server laufen mehrere Agentenprozesse, die in der Regel Automatisierungs- und Hilfsaufgaben ausführen, wie z. B. die folgenden:
-
Überwachung – Herkömmliche Java-EE-Anwendungsumgebungen verwenden häufig spezielle Agenten für die Überwachung. Diese Agenten sind für die Überwachung der Server-CPU, des Arbeitsspeichers, der Festplattennutzung, der Speichernutzung innerhalb der JVM, der Protokollnachrichten und mehr verantwortlich. Es ist jedoch nicht möglich, Überwachungs-Agenten direkt in einer Containerumgebung auszuführen. Sie müssen die Überwachungsagenten durch die von der Container-Plattform bereitgestellten Überwachungsmechanismen wie Amazon CloudWatch und Amazon CloudWatch Logs ersetzen.
-
Aufgaben (geplante Aufgaben) – In herkömmlichen Java-EE-Anwendungsumgebungen befindet sich die Aufgaben-Ausführungsumgebung oft auf demselben Server wie der Anwendungsserver und ist neben Benutzeranforderungen auch für Batch-Prozesse mit langer Laufzeit zuständig. Beispielsweise greift der vom Aufgaben-Controller gesteuerte Batch-Prozess auf die Datenbank zu, um Daten abzurufen und einen Bericht zu erstellen. Da diese verschiedenen Workloads in einer Containerumgebung nicht nebeneinander existieren können, müssen Sie die Aufgaben- und Batch-Ausführungsumgebung getrennt von der Container-Umgebung erstellen.
-
Übertragung von Dateien – Dateiübertragungsagenten sind in Java-EE-Anwendungsumgebungen in der Regel nicht so verbreitet, aber sie laufen manchmal auf demselben Betriebssystem wie die Java-Anwendung als eigenständiger Prozess für den Austausch von Dateien zu oder von externen Anwendungen. Beispielsweise werden Daten, die von anderen Anwendungen verwendet werden, täglich in eine Datei übertragen und in der Datenbank wiedergegeben. Dateiübertragungs-Agenten können nicht neben Containern ausgeführt werden, sondern müssen auf einem anderen Server ausgeführt werden, der Zugriff auf die Datenbank und die Dateien hat.
3. Anwendungsserver
Die größte Herausforderung bei der Containerisierung ist die Änderung der Anwendungsserver. Herkömmliche Java-EE-konforme Anwendungsserver gehen von einer statischen Rechenumgebung aus, sodass sie möglicherweise nicht für die Ausführung in einer Containerumgebung geeignet sind. Das heißt, es wird davon ausgegangen, dass die physischen oder virtuellen Server die Einheit der Rechenumgebung für Java-EE-Anwendungen bilden. Beispielsweise verfügen proprietäre Java EE-Anwendungsserver, wie ein herkömmlicher IBM WebSphere Application Server (TWAs) und Oracle WebLogic Server, über ihren eigenen Mechanismus zur Anwendungsbereitstellung.
In einer Container-Umgebung ist die Situation anders. In dieser Umgebung umfassen Container einen Anwendungsserver und eine Laufzeit mit Anwendungsentwicklungspaketen (z. B. WAR- und JAR-Dateien) und werden auf Containerplattformen wie Amazon ECS oder Amazon EKS bereitgestellt. Wir empfehlen, einen Container-Plattformmechanismus zu verwenden, um Anwendungen in Umgebungen bereitzustellen. Anwendungsserver werden häufig mit Containern bereitgestellt, daher müssen sie klein (weniger als 500 MB) und schnell zu starten sein. Um diese Anforderung zu erfüllen, müssen Sie möglicherweise den herkömmlichen Anwendungsserver ändern und auf einen containerfreundlicheren Anwendungsserver migrieren. Dies könnte eine Migration von IBM WebSphere Application Server zu IBM WebSphere Liberty oder JBoss Enterprise Application Platform (EAP) erfordern. WildFly
Wir empfehlen Ihnen, die folgenden Auswirkungen zu berücksichtigen, die sich aus dem Wechsel eines Anwendungsservers ergeben können:
-
Konfigurationsinjektion über Umgebungsvariablen (im Gegensatz zu herkömmlichen Java-EE-Anwendungen, die Konfigurationen in einer Datei speichern, z. B. web.xml)
-
Kompatibilität mit Java-EE-Funktionen
-
JVM-Versionen
4. Dateispeicher
Der am häufigsten für herkömmliche Java-EE-Anwendungen verwendete Dateispeicher ist das lokale Dateisystem. Zu den häufigsten Anwendungsfällen gehören Anwendungsprotokolldateien, von Anwendungen generierte Dateien wie Geschäftsberichte und von Benutzern hochgeladene Inhalte. Wir empfehlen, Dateien nicht innerhalb des Containers zu speichern, da Container statuslos sind, was bedeutet, dass Dateispeicher für die Containerisierung externalisiert werden müssen.
Ziehen Sie die folgenden Containerisierungsoptionen in Betracht:
-
Amazon Elastic File System (Amazon EFS) – Amazon EFS ist ein verwalteter NFS-Service, auf den von Containern aus zugegriffen werden kann. Amazon EFS ist in Amazon ECS und Amazon EKS integriert. Wenn Sie Amazon EFS verwenden, müssen Sie keine benutzerdefinierten Skripts schreiben, um EFS-Volumes in Ihren Containern zu mounten. Der erste Schritt für diese Option besteht darin, alle Dateisystempfade in Ihrer Anwendung aufzulisten, die zum Lesen oder Schreiben verwendet werden. Nachdem Sie den Dateisystempfad identifiziert haben, der dauerhaft gespeichert werden soll, können Sie den Dateisystempfad einem EFS-Dateisystempfad zuordnen. Weitere Informationen finden Sie unter Tutorial: Verwenden von Amazon-EFS-Dateisystemen mit Amazon ECS in der Amazon-ECS-Dokumentation. Nicht alle Pfade müssen dauerhaft gespeichert werden, insbesondere Anwendungsprotokolldateien. Die meisten Unternehmensanwendungen schreiben Protokolldateien in ein lokales Dateisystem. Im Rahmen der Containerisierung empfehlen wir, dass Sie erwägen, das Protokollierungsziel so zu ändern, dass Standard Out und Standard Error verwendet werden. Auf diese Weise können Sie alle Ausgaben in CloudWatch Logs erfassen, ohne sich um Größe und Leistung des Protokollspeichers kümmern zu müssen. Weitere Informationen zur Protokollierung in Amazon ECS finden Sie unter Verwenden des awslogs-Treibers in der Amazon-ECS-Dokumentation.
-
Amazon Simple Storage Service (Amazon S3) – Amazon S3 ist günstiger als Amazon EFS und unterstützt eine größere Bandbreite als Amazon EFS, aber Amazon S3 erfordert eine umfassendere Änderung des Anwendungscodes als Amazon EFS. Das liegt daran, dass Amazon S3 kein Dateisystem ist.
5. Prozess zum Erstellen und Bereitstellen
Der Containerisierungsprozess beinhaltet die Änderung und Erweiterung des Anwendungsbereitstellungsprozesses. In herkömmlichen Umgebungen umfasst der Prozess der Anwendungsbereitstellung hauptsächlich Java-Artefakte (z. B. WAR- und EAR-Dateien). In einer Containerumgebung ist das Container-Image die Liefereinheit. Zusätzlich zum Prozess zum Erstellen vorhandener Java-Artefakte müssen Sie einen Prozess zum Erstellen und Bereitstellen von Docker-Containern erstellen. Weitere Informationen zum Pipeline-Prozess finden Sie unter Automatisches Erstellen und Bereitstellen einer Java-Anwendung für Amazon EKS mithilfe einer CI/CD Pipeline in der Dokumentation AWS Prescriptive Guidance.
6. Zugriff auf die Datenbank
Herkömmliche Containerisierungen von Anwendungen gehen häufig mit einer Datenbankmigration einher. Um das Migrationsrisiko zu verringern, empfehlen wir, die Migrationsstrategie für relationale Datenbanken (AWS Prescriptive Guidance) zu befolgen. Containerisierte Umgebungen erfordern eine externe Konfiguration, einschließlich Datenbankverbindungszeichenfolgen. Sie können Tools wie Spring Cloud Config
