1. Apache Tomcat auf Arm-basiertem Ampere A1-Computer bereitstellen, der mit einer autonomen Datenbank verbunden ist
  2. Apache Tomcat auf Arm-basiertem Ampere A1-Computer bereitstellen, der mit einer autonomen Datenbank verbunden ist

Apache Tomcat auf Arm-basiertem Ampere A1-Computer bereitstellen, der mit einer autonomen Datenbank verbunden ist

Apache Tomcat ist ein Open Source Java-Anwendungsserver. Es implementiert die Technologien Java Servlet, JavaServer Pages, Java Expression Language und Java WebSocket.

Architektur

Dies ist eine Multi-Arch-Referenzarchitektur, die einen Load Balancer, eine Anwendungsebene mit Apache Tomcat enthält, die auf Arm AArch64-Formen (Arm-based Ampere A1 Compute) ausgeführt wird, und eine Datenbankebene mit Oracle Autonomous Database, die auf x86 ausgeführt wird.

Als Java-Entwickler können Sie diese Flexibilität nutzen und eine Tomcat-Webanwendung mithilfe der Sicherheit und Performance von Armformen in OCI bereitstellen. In diesem Szenario können Sie die Kernanzahl basierend auf Ihren Anwendungsanforderungen ändern.

Die Komponenten befinden sich in verschiedenen Subnetzen. Der Load Balancer befindet sich in einem öffentlichen Subnetz. Die Tomcat-Server teilen ein privates Subnetz und die Datenbank befindet sich in einem eigenen privaten Subnetz. Der gesamte externe Zugriff erfolgt über den Load Balancer über ein Internetgateway.

Eine Beispielanwendung, die die Anwendungssitzungsverwaltung mit der Datenbank anzeigt, ist enthalten.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung von architecture-deploy-tomcat-adb.png folgt
Beschreibung der Abbildung architecture-deploy-tomcat-adb.png

architecture-deploy-tomcat-adb-oracle.zip

Die Architektur enthält die folgenden Komponenten:

  • Region

    Eine Region ist ein lokalisiertes geografisches Gebiet, das aus einer oder mehreren Availability-Domains besteht. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder Kontinente).

  • Availability-Domains

    Verfügbarkeitsdomains sind eigenständige, unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domain-Netzwerk. Ein Fehler bei einer Availability-Domain wirkt sich daher unwahrscheinlich auf die anderen Availability-Domains in der Region aus.

  • Faultdomains

    Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Fault-Domains mit unabhängiger Power und Hardware. Wenn Sie Compute-Instanzen über mehrere Faultdomains hinweg platzieren, können Anwendungen physischen Serverfehler, Systemwartung und viele häufige Netzwerk- und Stromausfälle innerhalb der Availability-Domain tolerieren.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region eingerichtet haben. VCNs können in Subnetze segmentiert werden, die für eine Region oder eine Availability-Domain spezifisch sein können. Sowohl regionsspezifische als auch Verfügbarkeitsdomainspezifische Subnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein.

  • Load Balancer

    Der Oracle Cloud Infrastructure Load Balancing-Service stellt eine automatisierte Trafficverteilung von einem Einstiegspunkt zu mehreren Servern bereit, die von Ihrem VCN aus erreichbar sind. Wenn Sie die Anwendungsebene im Clustermodus erstellen, können Sie den Load Balancer so konfigurieren, dass der Datenverkehr auf die Tomcat-Server verteilt wird. Der Load Balancer stellt den Anwendungsservern ein Frontend zur Verfügung, das unnötigen oder nicht autorisierten Zugriff auf die interne Ebene isoliert und verhindert.

  • Sicherheitslisten

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die im Subnetz und außerhalb des Subnetzes zulässig sein müssen.

  • Routentabellen

    Virtuelle Routentabellen enthalten Regeln zur Weiterleitung von Traffic von Subnetzen an Ziele außerhalb von VCN, normalerweise über Gateways.

  • Internetgateway

    Das Internetgateway ermöglicht den Datenverkehr zwischen VCN und dem öffentlichen Internet.

  • Tomcat-Server

    Die Tomcat-Server hosten das Java-Servlet, JavaServer Pages, Java Expression Language und Java WebSockets. Tomcat-Server werden auf Arm-basierten Ampere A1-Formen in dieser Architektur installiert.

  • Datenbankserver

    Tomcat kann sich bei jeder Datenbank anmelden, die JDBC-Java-Datenbankverbindung anbietet. Diese Architektur verwendet Oracle Autonomous Database.

  • Bastion-Host

    Der Bastionshost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt für die Topologie außerhalb der Cloud dient. Der Bastionshost wird normalerweise in einer entmilitarisierten Zone (DMZ) bereitgestellt. Dadurch können Sie sensible Ressourcen schützen, indem Sie sie in private Netzwerke platzieren, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Die Topologie hat einen einzigen bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. Dadurch können Sie vermeiden, die sensibleren Komponenten der Topologie freizugeben, ohne den Zugriff darauf zu beeinträchtigen.

Empfehlungen

Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

  • VCN

    Legen Sie beim Erstellen des VCN fest, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Notation Classless Inter-Domain Routing (CIDR) eine Subnetzmaske und einen Netzwerkadressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressraum, der sich innerhalb der standardmäßigen privaten IP-Adressblöcke befindet.

    Wählen Sie einen Adressbereich, der sich nicht mit Ihrem On-Premise-Netzwerk überschneidet, damit Sie gegebenenfalls eine Verbindung zwischen VCN und Ihrem On-Premise-Netzwerk einrichten können.

    Nachdem Sie ein VCN erstellt haben, können Sie den Adressbereich nicht mehr ändern.

    Beachten Sie beim Entwerfen der Subnetze Ihre Funktions- und Sicherheitsanforderungen. Ordnen Sie alle Compute-Instanzen innerhalb derselben Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.

    Verwenden Sie regionale Subnetze.

  • Load Balancer

    Diese Architektur verwendet einen Everways Free 10-Mbps Load Balancer.

    Die Form der nicht freien Load Balancer beginnt bei 100 Mbps. Je nach Anzahl der benötigten gleichzeitigen Verbindungen und dem Gesamtdurchsatz können Sie größere Formen verwenden.

    Wir empfehlen Ihnen, DNS-Namen zu verwenden, weil die IP-Adresse des Load Balancers nicht reserviert werden kann.

  • Instanzen

    Als Teil der flexiblen Formen erhalten alle Mandanten 4 Kerne der Ampere A1 Compute-Form kostenlos und insgesamt 24 GB Speicher.

  • Datenbanksysteme (DB)

    Alle Mandanten erhalten zwei immer kostenlose autonome Oracle-Datenbanken. Autonomous Databases verwenden gemeinsam genutzte Exadata-Infrastruktur, in der Oracle das Provisioning und die Verwaltung der Infrastruktur verarbeitet.

    Wenn mehr als zwei Datenbanken erforderlich sind, verwenden Sie ein nicht-freies Oracle Autonomous Database.

  • Speicherung

    Die Instanzen in dieser Architektur verwenden regulären Blockspeicher. Es ist keine zusätzliche Performance erforderlich.

  • Netzwerkverbindungen

    Sie können die Umgebung verwalten, indem Sie eine Verbindung zu Ihrer vorhandenen On-Premise-Infrastruktur herstellen, indem Sie ein Site-to-Site-VPN oder eine dedizierte Verbindung mit FastConnect verwenden.

    Wenn die Umgebung von der vorhandenen Infrastruktur getrennt oder extern aufgerufen werden muss, kann ein Bastionshost die Managementverbindungen sichern. Der Bastionshost wird normalerweise in einer entmilitarisierten Zone (DMZ) bereitgestellt. Sie schützt sensible Ressourcen, indem sie in private Netzwerke platziert werden, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Sie können vermeiden, die sensibleren Komponenten der Architektur freizugeben, ohne den Zugriff auf sie zu beeinträchtigen.

Wichtige Aspekte

Beachten Sie bei der Bereitstellung dieser Referenzarchitektur Folgendes.

  • Performance

    Diese Architektur verwendet immer kostenlose Oracle Cloud Infrastructure-Ressourcen. Aufgrund der Einschränkungen der Verarbeitungsleistung ist diese Architektur nicht für die Produktion gedacht. Für intensivere Workloads sollten die regulären Formen von Instanzen, Load Balancern und Datenbanken verwendet werden.

  • Sicherheit

    Außer dem Bastionshost, falls vorhanden, und Load Balancern, sollten alle Komponenten in private Subnetze gesetzt werden.

  • Verfügbarkeit

    Die Load Balancer und die Datenbanken sind redundant und erfordern keine Intervention, um diese Features zu nutzen. Die Tomcat-Server werden als Paar bereitgestellt und vom Load Balancer ausgeglichen. Weitere Knoten können hinzugefügt werden, sind jedoch nicht in der Immer freien Ebene enthalten.

  • Kostenfaktor

    Diese Architektur verwendet die Immer freie Ebene. Wenn die Standardbereitstellungskonfiguration verwendet wird, fallen keine Kosten an.

Bereitstellen

Der Terraform-Code für diese Referenzarchitektur ist auf GitHub verfügbar. Sie können den Code mit einem einzigen Klick in Oracle Cloud Infrastructure Resource Manager ziehen, den Stack erstellen und bereitstellen. Alternativ können Sie den Code von GitHub auf Ihren Computer herunterladen, den Code anpassen und die Architektur mit der Terraform-CLI bereitstellen.

  • Mit Oracle Cloud Infrastructure Resource Manager bereitstellen:
    1. KlickenSie auf In Oracle Cloud bereitstellen

      Wenn Sie sich noch nicht angemeldet haben, geben Sie die Mandanten- und Benutzerzugangsdaten ein.

    2. Lesen Sie die allgemeinen Geschäftsbedingungen, und akzeptieren Sie sie.
    3. Wählen Sie den Bereich, in dem der Stack bereitgestellt werden soll.
    4. Befolgen Sie die Prompts und Anweisungen auf dem Bildschirm, um den Stack zu erstellen.
    5. Klicken Sie nach dem Erstellen des Stacks auf Terraform-Aktionen, und wählen Sie Plan.
    6. Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.

      Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken auf "Stack bearbeiten" und nehmen die erforderlichen Änderungen vor. Führen Sie dann die Aktion Plan erneut aus.

    7. Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken auf Terraform-Aktionen, und wählen Sie Anwenden.
  • Deployment mit dem Terraform-Code in GitHub:
    1. Gehen Sie zu GitHub.
    2. Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
    3. Befolgen Sie die Anweisungen im Dokument README.

Weitere Informationen

Links zu zusätzlichen Informationen, mit denen Sie diese Architektur kennenlernen, ändern, verwenden oder implementieren können.

  • Ein kostenloser praktischer Workshop auf Oracle LiveLabs, in dem Sie Tomcat zu Oracle Cloud Infrastructure migrieren und eine Verbindung zu einem Autonomous Database herstellen.

    Tomcat Java-Anwendungen in OCI-Workshop migrieren

  • Technische Artikel, Whitepaper, Codebeispiele, FAQs und mehr beschreiben, wie JDBC, der Universal Connection Pool und die eingebettete JVM zur Verbindung mit Oracle Database verwendet werden.

    Java-Anwendungen mit Oracle Database entwickeln

  • Ein Repository auf GitHub mit Codebeispielen für ein Java-Servlet, das sich mit dem Oracle JDBC-Treiber bei Oracle Database anmeldet.

    Tomcat Java-Servlet

Änderungslog

In diesem Log werden wesentliche Änderungen aufgeführt: