Deploy Apache Tomcat on Arm-based Ampere A1 compute connected to an autonomous database

Apache Tomcat is an open source Java application server. It implements the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies.

Architecture

This is a multi-arch reference architecture that contains a load balancer, an application tier with Apache Tomcat running on Arm AArch64 shapes (Arm-based Ampere A1 Compute), and a database tier with Oracle Autonomous Database running on x86.

As a Java developer, you can take advantage of this flexibility and deploy a Tomcat web application using the security and performance of Arm shapes in OCI. In this scenario, can you change the core count based on your application requirements.

The components are located in different subnets. The load balancer is in a public subnet. The Tomcat servers share a private subnet and the database is in its own private subnet. All external access is through the load balancer via an Internet gateway.

A sample application that shows application session management using the database is included.

The following diagram illustrates this reference architecture.

Description of the illustration architecture-deploy-tomcat-adb.png

architecture-deploy-tomcat-adb-oracle.zip

The architecture has the following components:

• Region

  A region is a localized geographic area composed of one or more availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or continents).

• Availability domains

  Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

• Fault domains

  A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you place Compute instances across multiple fault domains, applications can tolerate physical server failure, system maintenance, and many common networking and power failures inside the availability domain.

• Virtual cloud network (VCN) and subnets

  A VCN is a software-defined network that you set up in an Oracle Cloud Infrastructure region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

• Load Balancer

  The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from one entry point to multiple servers reachable from your VCN. When you create the application layer in cluster mode, you can configure the load balancer to distribute traffic across the Tomcat servers. The load balancer provides a front end to the application servers, isolating and preventing unnecessary or unauthorized access to the internal layer.

• Security lists

  For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

• Route tables

  Virtual route tables contain rules to route traffic from subnets to destinations outside the VCN, typically through gateways.

• Internet gateway

  The internet gateway allows traffic between the VCN and the public internet.

• Tomcat servers

  The Tomcat servers host the Java Servlet, JavaServer Pages, Java Expression Language, and Java WebSockets. Tomcat servers are installed on Arm-based Ampere A1 shapes in this architecture.

• Database servers

  Tomcat can connect to any database that offers JDBC Java Database Connectivity. This architecture uses Oracle Autonomous Database.

• Bastion host

  The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. As a result, you can avoid exposing the more sensitive components of the topology without compromising access to them.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

• VCN

  When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address space that's within the standard private IP address blocks.

  Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network, if necessary.

  After you create a VCN, you can't change its address range.

  When you design the subnets, consider your functionality and security requirements. Attach all the compute instances within the same tier or role to the same subnet, which can serve as a security boundary.

  Use regional subnets.

• Load balancer

  This architecture uses an Always Free 10-Mbps load balancer.

  The shape of non-free load balancers start at 100 Mbps. Depending on the number of simultaneous connections needed and on the total throughput, you can use larger shapes.

  We recommend that you use DNS names because the load balancer's IP address can't be reserved.

• Instances

  As part of the flexible shapes, all tenancies get 4 cores of Ampere A1 compute shape for free and a total of 24GB of memory.

• Database (DB) systems

  All tenancies get two Always Free Oracle Autonomous Databases. Autonomous Databases use shared Exadata infrastructure, where Oracle handles provisioning and maintaining the infrastructure.

  If more than two databases are required, use a non-free Oracle Autonomous Database.

• Storage

  The instances in this architecture use regular block storage; no extra performance is required.

• Network connectivity

  You can manage the environment by connecting to your existing on-premises infrastructure by using a site-to-site VPN or a dedicated connection with FastConnect.

  If the environment needs to be segregated from the existing infrastructure or accessed externally, a bastion host can secure the management connections. The bastion host is typically provisioned in a demilitarized zone (DMZ). It protects sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. You can avoid exposing the more sensitive components of the architecture without compromising access to them.

Considerations

Consider the following points when deploying this reference architecture.

• Performance

  This architecture uses Oracle Cloud Infrastructure's Always Free resources. Due to the limitations of processing power, this architecture is not intended for production. For more intense workloads, the regular shapes of instances, load balancers, and databases should be used.

• Security

  Except for the bastion host, if present, and load balancers, all the components should be placed in private subnets.

• Availability

  The load balancers and the databases are redundant, not requiring any intervention to take advantage of these features. The Tomcat servers are deployed as a pair and balanced by the load balancer. More nodes can be added, but they’re not included in the Always Free Tier.

• Cost

  This architecture uses the Always Free tier. There is no cost if the standard deployment configuration is used.

Deploy

The Terraform code for this reference architecture is available on GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

• Deploy by using Oracle Cloud Infrastructure Resource Manager:
  1. Click

     If you aren't already signed in, enter the tenancy and user credentials.

  2. Review and accept the terms and conditions.
  3. Select the region where you want to deploy the stack.
  4. Follow the on-screen prompts and instructions to create the stack.
  5. After creating the stack, click Terraform Actions, and select Plan.
  6. Wait for the job to be completed, and review the plan.

     To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

  7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
• Deploy using the Terraform code in GitHub:
  1. Go to GitHub.
  2. Clone or download the repository to your local computer.
  3. Follow the instructions in the README document.

More Information

Links to additional information that can help you learn about, modify, use, or implement this architecture.

• A free hands-on workshop on Oracle LiveLabs where you migrate Tomcat to Oracle Cloud Infrastructure and connect to an Autonomous Database.

  Migrate Tomcat Java Applications to OCI Workshop

• Technical articles, white papers, code samples, FAQs, and more that describe how to use JDBC, the Universal Connection Pool, and the embedded JVM to connect to Oracle Database.

  Develop Java applications with Oracle Database

• A repository on GitHub that has code samples for a Java Servlet that connects to Oracle Database using the Oracle JDBC driver.

  Tomcat Java Servlet

Change Log

This log lists significant changes:

February 8, 2021

In the More Information section, added a link to an Oracle LiveLab workshop.