Learn About Designing a Landing Zone for Oracle E-Business Suite and Cloud Manager Deployment

You must first prepare your tenancy, to migrate an on-premises Oracle E-Business Suite (EBS) to Oracle Cloud Infrastructure (OCI). You can design and deploy a landing zone to make this preparation simple.

In this solution, you learn how to deploy a landing zone with a new tenancy which also meets the specific requirements for deploying an EBS workload. You do this using three different Oracle Cloud Infrastructure Resource Manager stacks:

  • Oracle E-Business Suite: Tenancy Administrator Stack for Landing Zones (IAM Stack)
  • Oracle E-Business Suite: Network Administrator Stack for Landing Zones (Network Stack)
  • Oracle E-Business Suite: Cloud Manager Deployment Stack for Landing Zones (CM Stack)

You can then use EBS Cloud Manager to automate migration, deployment, and lifecycle management of multiple EBS environments in this landing zone.

Before You Begin

Before you begin, review the following solution:

You can optionally also deploy the following reference architecture:

Architecture

The following architecture diagram shows a landing zone setup for deploying Oracle E-Business Suite using EBS Cloud Manager using the provided IAM, Network, and Cloud Manager stacks.

Description of cis-landing-zone-ebs-arch.png follows
Description of the illustration cis-landing-zone-ebs-arch.png

cis-landing-zone-ebs-arch.zip

  1. A member of the Tenancy Administrators group must run the initial deployment of the Tenancy Administrator stack or the IAM stack. After the initial deployment of the IAM stack, the Tenancy Administrator must create accounts for each user and add IAM administrators to their groups.
  2. Then IAM administrators can add the rest of the users to their groups.
    • Administrator groups have manage permissions for the resources they oversee in their specific compartment. IAM Administrators can manage the IAM stack including compartments, groups, and policies. This stack will also create the vault and key resources needed to pass configuration information securely between stacks using secrets. IAM Administrators need permissions to the IAM Administrator, Network User, and Security User groups.

      Note:

      They can optionally be a part of the Credential Administrators group.
    • User groups provide read or limited use access to these resources in order to be able to access the resources created by the Administrator group.
  3. Network Administrators manage the Network stack including VCN, subnets, and Bastion service. A set of subnets is correlated with each distinct EBS environment category. This set requires dedicated subnets for internal application tier nodes and a database tier node. It can also contain dedicated subnets for internal load balancer, external load balancer, external application tier nodes. Additional shared subnets may be deployed once for Bastion, EBS Cloud Manager app, load balancer, and File Storage mount target. Network Administrators must have permissions to the Network Administrator and Security User groups.
  4. An Administrator (either the IAM or Cloud manager) must create a Confidential application for the EBS Cloud Manager. They need permissions to either the IDCS Application Administrator or OCI Identity Domain Application Administrator role (or must be a Tenancy Administrator).
  5. EBS Cloud Manager Administrators manage the Cloud Manager stack including the Cloud Manager instance and Load Balancer. EBS Cloud Manager Administrators need permissions to the EBS CM group, Network User group, Security User group, and either the general EBS workload group or specific EBS environment category groups.
  6. EBS Environment Category Administrators can use the Cloud Manager web portal to manage EBS environments.

This architecture includes the following components:

  • Oracle E-Business Suite Cloud Manager

    Oracle E-Business Suite Cloud Manager is a web-based application that drives the principal automation flows for Oracle E-Business Suite on Oracle Cloud Infrastructure (OCI), including migrating Linux-based environments from on-premises, provisioning new environments, and performing lifecycle management activities.

  • Secrets

    Oracle Cloud Infrastructure Vault enables you to centrally manage the encryption keys that protect your data and the secret credentials that you use to secure access to your resources in the cloud. You can use the Vault service to create and manage vaults, keys, and secrets.

    Secrets are credentials such as passwords, certificates, SSH keys, or authentication tokens that you use with Oracle Cloud Infrastructure services. Storing secrets in a vault provides greater security than you might achieve storing them elsewhere, such as in code or configuration files.

  • Identity and Access Management (IAM)

    Oracle Cloud Infrastructure Identity and Access Management (IAM) is the access control plane for Oracle Cloud Infrastructure (OCI) and Oracle Cloud Applications. The IAM API and the user interface enable you to manage identity domains and the resources within the identity domain. Each OCI IAM identity domain represents a standalone identity and access management solution or a different user population.

  • 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.

  • Bastion service

    Oracle Cloud Infrastructure Bastion provides restricted and time-limited secure access to resources that don't have public endpoints and that require strict resource access controls, such as bare metal and virtual machines, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE), and any other resource that allows Secure Shell Protocol (SSH) access. With Oracle Cloud Infrastructure Bastion service, you can enable access to private hosts without deploying and maintaining a jump host. In addition, you gain improved security posture with identity-based permissions and a centralized, audited, and time-bound SSH session. Oracle Cloud Infrastructure Bastion removes the need for a public IP for bastion access, eliminating the hassle and potential attack surface when providing remote access.

Considerations for Deploying a Landing Zone for E-Business Suite

Before deploying the infrastructure, you must make several decisions about how you want to set up your environments.

This solution playbook assumes you will deploy all the three Terraform stacks. These stacks can be considered Infrastructure-as-Code (IaC) or collaborative IaC depending upon how your teams communicate. You have the option of rolling back to a semi-automated operating model where one of your teams don't use the Terraform stacks. You can also roll back to a completely manual approach after the initial stack deployment.

General Decisions

You must make certain decisions for infrastructure, information sharing, environments, and naming conventions.

Area Consideration Options
Infrastructure Management Operating Model Consider if you are committed to managing and maintaining Terraform stacks or do you want to use Terraform as a one-off script and manage resources using the console or the CLI. This helps you determine the Terraform skill level needed on your team and the specific stack code you will be running.
  • Collaborative Infrastructure as Code: Supported
  • Infrastructure-as-Code: Default
  • Semi-automated: Supported
  • Manual maintenance: Supported
Information Sharing Decide how you want to pass information between stacks. Oracle recommends that you use Oracle Cloud Infrastructure Vault Secrets. Alternatively, you can use Hashicorps vault for secrets. You can also choose not use secrets and pass information using input variables or sharing output using state files.
  • OCI Secrets: Default
  • Input variables: Supported
  • Other methods: Requires code customizations
E-Business Suite Environments

You create multiple categories of EBS Environments that are isolated from each other at the Identity and Network levels. Identity Isolation involves creating a separate compartment and IAM resources, which also restricts access in the CM UI. Network Isolation involves creating a separate set of subnets within a VCN.

  • Unique Identity and Network for each Environment Category: Default
  • Shared Single Identity and Network: Supported
  • Combination of shared Identity and unique Network or the converse: Supported
Region The IAM stack contains resources that can only be created in the home region. Hence, the automation for the Network and Cloud Manager stacks is restricted to the home region.
  • IAM stack: Home Region: Required
  • Network stack: Home Region: Recommended
  • Cloud Manager stack: Home Region: Recommended

Naming Convention

These stacks share a naming convention, which helps ensure resources have the required unique names across the tenancy and are easily identifiable by your organization. By default, you will set these names in the IAM stack and the secrets will propagate the naming convention through the Network and Cloud Manager stacks.

Note:

If you deploy the Network or Cloud Manager stacks as standalone, you will need to manually enter your naming convention.

The following are the list of prefixes and what they are used for:

lz_prefix: Used to identify what landing zone you are using. Multiple workloads can share a landing zone (network and security compartments) or use different landing zones depending upon your organization's internal structure.

ebs_workload_prefix: Identify a workload or application. Each workload has its own isolated compartment.

ebs_workload_environment_category(ies): Identifies the EBS environment categories to use or create. The IAM stack allows you to create resources for multiple EBS environment categories. You'll need to deploy the Network stack multiple times, once for each EBS category.

IAM Stack Decisions

Consider the various factors to decide on your Tenancies and Identity Domains.

Area Consideration Options
Tenancies

Consider whether you need a new tenancy or plan to use an existing tenancy.

New Tenancy: You must configure recommended identity and governance systems including creating user accounts and setting up tenancy-level personas to manage IAM, credentials, auditors, announcements, and costs.

Existing Tenancy: Oracle recommends that you set up identity resources for networking, EBS applications, and security. You can create new ones with the IAM stack or reuse existing resources if they fit your needs and EBS requirements.

New Tenancy
  • Deploy the IAM stack.
  • Oracle recommends that you deploy additional administrative resources as defined in the landing zone.
Existing Tenancy
  • Deploy the IAM stack: Default
  • Reuse existing resources: Supported
IDCS or Identity Domains Verify if Identity Domains are enabled in your tenancy as the setup is slightly different for these services.
  • IDCS: Follow the manual IDCS setup instructions.
  • Identity Domains: Follow the manual Identity Domain setup instructions.

Network Stack Decisions

You must make certain decisions about the networking requirements for your business needs.

Area Consideration Options
Virtual Cloud Network (VCN) Consider whether you need a new or an existing VCN. New VCN

The Networking stack can deploy a new VCN for you. If you want to peer this network to another VCN, cloud, or an on-premises data center, you must do that outside this Terraform stack.

Existing VCN
You can pass an existing VCN using input variables. This will create the required subnets, security lists, and route tables within your existing VCN.

Note:

This method assumes that the required gateways already exist in the VCN.
Multiple E-Business Suite Environment categories If you create multiple EBS environment categories, you can create isolated networks by deploying the Network stack multiple times. On subsequent deployments, you must specify the existing VCN as the one you created or used in the first deployment. You also only need to deploy the required EBS subnets. You don't need another set of Cloud Manager or Bastion subnets. Initial stack: Option to choose an existing or new VCN:
  • Cloud Manager and/or file storage subnets additionally require the CIDR blocks for any EBS category subnets made outside this stack to properly network
  • Optionally deploy the Bastion subnet

Additional environment category stacks

  • Select an existing VCN and make sure it is the same one you used in the first stack
  • Don't create new Cloud Manager, File Storage, or Bastion subnets

This stack will require the CIDR blocks for any Cloud Manager and/or file storage subnets made in the initial stack to properly network.

Network Access Your employees will need network access to OCI through private network peering, Bastion access, or both. You may want to set up a Bastion subnet if your employees need remote SSH access outside of your private network or in case your private connection goes down.

You can also directly peer your OCI VCN to your private network to allow SSH access and internal EBS web traffic. Pairing two networks is not part of these Terraform stacks, you can do that using the CIS Landing Zone.

Bastion subnet (Deploy once):

  • Private bastion subnet and bastion service: Default
  • Public bastion subnet and bastion VM: Partially supported
  • Create and manage your own bastion VM: Partially supported
Private network peering: Supported in CIS Landing Zone
Cloud Manager subnets You must deploy a set of Cloud Manager subnets to use the EBS Cloud Manager application to manage your EBS environments. You only need to deploy this set of CM subnets once. Cloud Manager subnets (Deploy once):
  • Default LB and app subnets: Default subnets for EBS, which are private and have NAT access.
  • External LB and app subnets: Only use these external subnets when you want to provide access to the EBS application over the internet. The external LB subnet is public and has internet access.

    Note:

    The external app subnet is private. These subnets can be used with or without the default LB and app subnets depending on your requirements.
EBS subnets Follow these recommendations to configure the EBS subnets according to your environment's needs:
  • Create database and App subnets for every environment.
  • By default, a private LB subnet is also provisioned to provide access to EBS across your VCN and any peered networks.
  • If you need to provide access to EBS over the internet, you can use the External LB and app subnets. Only select this if public internet access is absolutely needed and your team understands the risks of opening the app to the public internet.
  • You only need the File Storage subnet if your EBS environment uses a shared file storage system.
  • App and Database subnets: Recommended (Required)
  • Default LB subnet: recommended
  • External LB and App subnets (Optional): Public Internet access
  • File Storage subnet (optional): shared file systems
CIDR Blocks

If you choose to create a new VCN, you must specify a single CIDR block range for your network.

For each subnet you plan to deploy, you need to specify an unused CIDR block range from within your VCNs CIDR block range.

Cloud Manager Stack Decisions

You must make certain decisions about for deploying the Cloud Manager stack.

Area Considerations Options
DNS

Consider how you currently use DNS for EBS. You must update your DNS entries to point to the new EBS IP addresses. Follow your organization's existing process for updating DNS entries. In addition to DNS for EBS environments, the Cloud Manager app itself requires a new DNS entry, which should match the hostname you give it.

  • External DNS system: Recommended
  • No DNS: Optional
Certificates Consider how you currently use certificates for EBS. You must create certificates using an external certificate service and can then upload the certificates as files in the stacks. You should follow your organization's existing process for generating certificates. In addition to certificates for EBS environments, the Cloud Manager app itself also requires a certificate.
  • Externally-managed certificates: Default (Recommended)
  • No provided Certificate: Optional

About Required Services and Roles

This solution requires the following services and roles:

  • Oracle Cloud Infrastructure

  • Oracle Cloud Infrastructure Identity and Access Management

  • Oracle Cloud Infrastructure Networking Service
  • Oracle Cloud Infrastructure Security Service
  • Oracle E-Business Suite Cloud Manager

The following roles are required to deploy the Terraform stacks:

Service Name: Role Required to...
OCI: Tenancy administrator Performs the initial deployment of the IAM stack.

Note:

The Tenancy admin has permissions to deploy all the stacks. Oracle recommends that you use dedicated roles to perform individual deployments based on your organizational needs.

IDCS: Application administrator

or

OCI Identity Domain: Application administrator

Register the E-Business Suite Cloud Manager Confidential Application in IDCS or OCI Identity Domains.

The following are the roles that are automatically generated by the IAM Stack:

Service Name: Role Required to...
OCI: IAM-Administrators Manage the IAM stack including compartments, groups, and policies.
OCI: Credential-Administrators Manage user credentials.
OCI: <lz-prefix>-Network-Administrators Manage the Network stack including VCNs, subnets, security rules, and Bastions.
OCI: <lz-prefix>-Network-Users Allow other teams to use the provided network resources.
OCI: <lz-prefix>-Security-Administrators Monitor the Security compartment.
OCI: <lz-prefix>-Security-Users Allow other teams to use the provided security resources.
OCI: <lz-prefix>-<ebs-workload-prefix>-Administrators Access the EBS Cloud Manager UI to provision environments and conduct lifecycle management activities for all environment categories. These users are usually referred as EBS DBAs.

Note:

They must be direct IAM users.
<lz-prefix>-<ebs-workload-prefix>-cm-Administrators
  • Create the EBS Cloud Manager compute instance.
  • Configure the EBS Cloud Manager application.

A member of an EBS Cloud Manager administrators group must:

  • Define network profiles within the EBS Cloud Manager UI.
  • Manage network profile assignments to the EBS administrators group.

Note:

They must be direct IAM users.
OCI: <lz-prefix>-<ebs-workload-prefix>-<ebs-workload-environment-category>-Administrators Access the EBS Cloud Manager UI to provision environments and conduct lifecycle management activities for a specific environment category. These users are usually referred as EBS DBAs.

Note:

They must be direct IAM users.
OCI: General Allows users view access to various IAM and core resources. It also gives use access to Oracle tags.

See Oracle Products, Solutions, and Services to get what you need.