Learn About Migrating Apache Tomcat Workloads

You're spending valuable resource time applying patches to databases and operating systems, creating backups, and performing other maintenance tasks when your time would be better spent focusing on your core business. Consider migrating your on-premises Apache Tomcat workloads to the cloud and free up resources and improve security.

Before You Begin

Learn more about migrating your on-premises Tomcat Server workloads to the cloud.

Review the following related reference architecture, workshop, and solution playbooks:

• Deploy Apache Tomcat connected to an autonomous database (reference architecture)
• Migrate Tomcat Java Applications to OCI Workshop (Oracle LiveLabs)
• Best practices framework for Oracle Cloud Infrastructure (solution playbook)
• Learn about reducing downtime during a database migration (solution playbook)

Architecture

This architecture shows Apache Tomcat servers and an autonomous database in the cloud.

Oracle quick-start terraform template library provides a reference architecture to deploy Tomcat servers to Oracle Cloud Infrastructure as infrastructure-as-code, a reproducible deployment method. By default, the template provisions an Oracle Autonomous Transaction Processing database and configures the Oracle Java Database Connectivity (JDBC) driver for use with Tomcat.

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

This architecture supports the following components:

• Region

  An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

• Availability domain

  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 domain

  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 distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

• Virtual cloud network (VCN) and subnet

  A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

• Load balancer

  The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

• Security list

  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 table

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

• Internet gateway

  The internet gateway allows traffic between the public subnets in a VCN and the public internet.

• 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. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

• Apache Tomcat Servers

  Apache Tomcat software powers numerous large-scale, mission-critical web applications across a diverse range of industries and organizations. The Tomcat servers host the Java Servlet, JavaServer Pages, Java Expression Language, and Java WebSockets. Your applications exist in this layer.

• Database servers

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

• Autonomous database

  Oracle Cloud Infrastructure autonomous databases are fully managed, preconfigured database environments that you can use for transaction processing and data warehousing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

About Required Services and Roles

This solution requires the following services and roles:

• Oracle Cloud Infrastructure: Destination location in the cloud when migrating the database from on-premises.

• Oracle Database and Oracle Cloud Infrastructure Database: Source databases are on-premises and destination databases are provisioned under Oracle Cloud Infrastructure.

• Oracle Autonomous Transaction Processing: Oracle autonomous database system in the cloud.

These are the roles needed for each service.

Service Name: Role	Required to...
Oracle Database: root system privileges or sudo with the ability to run commands as root.	Migrate the database.
Oracle Cloud Infrastructure Identity and Access Management: OCI_Administrator	Control policies and who has access to your region's cloud resources. You can control what type of access a group of users have and to which specific resources.

If you require users who are not administrators to deploy this solution, make sure that the user belongs to a group that has the following security policies in place:

• Allow group MyGroup to manage instance-family in compartment MyCompartment

• Allow group MyGroup to manage virtual-network-family in compartment MyCompartment

• Allow group MyGroup to manage volume-family in compartment MyCompartment

• Allow group MyGroup to manage load-balancers in compartment MyCompartment

• Allow group MyGroup to manage autonomous-database-family in compartment MyCompartment

See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.