1. Set up infrastructure components for deploying PeopleSoft
  2. About Developing Infrastructure Components Using Terraform

About Developing Infrastructure Components Using Terraform

The Terraform modules that you downloaded contain separate scripts to create and set up various infrastructure components. You can view and edit these scripts to understand what components will be created and the characteristics of each component.

The root level of the Terraform directory contains the main configuration file, main.tf, which references the configuration files in various subdirectories. This directory also contains files that define variables used in the Terraform configuration files, or that contain information about the Terraform provider, data resources, or output. In addition, the Terraform configuration files to create security lists and route tables are also located at the root level.

The Terraform directory contains a modules directory. The modules directory contain following:

  • bastion: Used to create bastion hosts.

  • compute: Used to create UNIX and Windows Oracle Cloud Infrastructure Compute instances.

  • dbsystem: Used to create Oracle Cloud Infrastructure Database systems.

  • filesystem: Used to create Oracle Cloud Infrastructure File Storage file system.

  • loadbalancer: Used to create Oracle Cloud Infrastructure Load Balancing instances.

  • network: Used to create network resources such as Virtual Cloud Network (VCN), subnets, Internet gateway, service gateway, dynamic routing gateway (DRG) and network address translation (NAT) gateway.

About the Infrastructure Components to Be Created

Before you create any infrastructure components, you must provide some input about the type, number, and distribution of your components. For example, you can specify how many application instances you require, whether you want all your resources to be created in a single availability domain or across two availability domains, what edition and version of database you want on your DB Systems, and so on.

You use the terraform.tfvars file in the root level of the Terraform directory to provide this input. Open the terraform.tfvars file in a text editor and enter the required information. Refer to the README provided in the root level directory for suggested values that you can use in this file.

The Terraform modules by default create components in two availability domains. This is governed by the value of the variable AD in the terraform.tfvars file. You can view or modify the availability domains that will be used to host your infrastructure components by editing this value. If you want to create components in a single availability domain, set the value of AD to the required availability domain 1, 2, or 3, in the terraform.tfvars file. If you want to create components in two availability domains, specify or modify the numbers of the availability domains.

If you apply the Terraform configuration files using the suggested default values without making any changes, the following infrastructure components are created in two availability domains.

  • A VCN with the name psftvcn and the IP address range 172.16.0.0/16.

  • Sixteen subnets, eight in each availability domain. Each subnet has a /24 CIDR. For example: 172.16.4.0/24. The number suffixed to each subnet’s name indicates the availability domain that the subnet is created in.

    • Private subnets for the application servers, with the name appsubad1 and appsubad2.

    • Private subnets for the web servers, with the name websubad1 and websubad2.

    • Private subnets for the load balancers, with the name lbsubad1 and lbsubad2.

    • Private subnets for the database systems, with the name dbsubad1 and dbsubad2.

    • Private subnets for the ElasticSearch servers, with the name essubad1 and essubad2

    • Private subnets for the PeopleTools instances, with the name toolsssubad1 and toolssubad2.

    • Private subnets for the file system service, with the name fsssubad1 and fsssubad2.

    • Public subnets for the bastion hosts, with the name bassubad1 and bassubad2.

  • The following route tables. The DNS label for the VCN specified in the terraform.tfvars file is prefixed to each route table’s name.

    • The default route table, which has no rules.

    • A private route table, psftvcnpvtrt, which has route rules to route Object Storage traffic to the service gateway and all other traffic to the NAT instance.

    • A public route table, psftvcnpubrt, which has a route rule to route traffic to the internet gateway.

  • The following security lists:

    • The default security list.

    • A security list for the application servers subnet, with the name AppSecList .

    • A security list for the bastion hosts subnet, with the name BastionSecList.

    • A security list for the database subnet, with the name DBSecList.

    • A security list for the ElasticSearch server subnet, with the name ESSecList.

    • A security list for the file system server subnet, with the name FSSSecList.

    • A security list for the load balancer subnet, with the name LBSecList.

    • A security list for the PeopleTools subnet, with the name PToolsSecList.

    • A security list for the web server subnet, with the name WebSecList.

  • An internet gateway, with the name psftvcnigw. The DNS label specified in the terraform.tfvars file is prefixed to the internet gateway’s name. The internet gateway connects the edge of the cloud network with the internet. Traffic from your VCN to a public IP address outside the VCN goes through the internet gateway.

  • A dynamic routing gateway, with the name psftvcndrg. The DNS label name specified in the terraform.tfvars file is prefixed to the dynamic routing gateway’s name. The dynamic routing gateway provides a path for traffic between your VCN and destinations other than the internet — for example, traffic to your on-premises network using IPSec VPN or Oracle Cloud Infrastructure FastConnect, or traffic to a VCN in another region using remote VCN peering.

  • A service gateway, with the name psftvcnsvcgtw. The DNS label name specified in the terraform.tfvars file is prefixed to the service gateway’s name. The service gateway enables your VCN to access public Oracle Cloud Infrastructure services such as Oracle Cloud Infrastructure Object Storage, but without exposing the VCN to the public internet.

  • The following Oracle Cloud Infrastructure Compute instances, distributed in both availability domains. The environment prefix specified in the terraform.tfvars file is prefixed to each instance’s name, and the region, availability domain number, and count are suffixed. Each instance has an associated boot volume.

    • Application servers. The number of application server instances created and their shapes are determined by values you specify in the terraform.tfvars file.

    • Bastion hosts.

  • Two Oracle Cloud Infrastructure Database systems, one in each availability domain. The name, version, edition, and other properties of the Oracle Cloud Infrastructure Database systems are determined by values you specify in the terraform.tfvars file. Oracle Cloud Infrastructure Database systems are created in the database subnet dbsubad1 and dbsubad2.

  • One file system used for staging the PeopleSoft software is created. The file system is created in the file system subnet, fssubad1. The file system is mounted across all Oracle Cloud Infrastructure Compute instances.

  • Two load balancers, one in each availability domain. The environment prefix specified in the terraform.tfvars file is prefixed to each load balancer’s name, and the region and count are suffixed. The load balancers are in the web servers subnet, websubad1 and websubad2. The backend set and listeners for the load balancers are also created.

Create Infrastructure Components Using Terraform

After you’ve installed Terraform along with the OCI provider and set the environment variables on your local system, you’re ready to apply the Terraform modules to create the infrastructure components in Oracle Cloud Infrastructure.

  1. On your local system, open a terminal or launch Windows PowerShell. Navigate into the directory where your Terraform modules are located.
  2. Enter: terraform apply
  3. When you’re prompted to confirm the action, enter yes.
Terraform starts to create all of the components specified in the Terraform modules in the current directory. The output shows objects being created. Some object, for example database systems, can take quite a long time to create. When all components have been created, Terraform displays a completion message. For example: Apply complete! Resources: 90 added, 0 changed, 0 destroyed.

In the Outputs section of the command output, Terraform displays the public and private IP addresses of the instances that were created. Make a note of the IP addresses of instances that you want to connect to.

If you encounter any errors, you can fix those errors and run terraform apply again. Ensure that you re-run this command in the same directory where you ran this command the first time. Terraform checks the current state of your components and creates the components that don’t exist. Note, however, that if you run Terraform in a different directory or from a different local system that has the same Terraform modules, Terraform treats this as a fresh set up and creates all the resources specified in the various configuration files. If you want to run Terraform in a different directory or local system to manage existing resources, copy the Terraform state files from the existing directory to the new directory or system. In general, however, it’s recommended that you don’t use Terraform in one system or directory to manage components created by Terraform in another system or directory.