Oracle Enterprise Landing Zone v2 - Workload Expansion Implementation

The following information describes how to implement the Oracle Enterprise Landing Zone (OELZ) v2 Workload Expansion.

Deployment

The following information describes how to deploy the OELZ v2 Workload Expansion.

Terraform CLI

Use the following steps to deploy with the Terraform CLI.

  1. Have Terraform installed on the system that you will deploy from. OELZ is designed to work with any version of Terraform later than 1.0.0, including the latest version (currently 1.3.9). If you don't have Terraform installed, the Terraform Download page provides links for installation instructions.

  2. Set up API keys to work with your OCI account. Follow the instructions here.

  3. Go to the GitHub page to clone the Terraform template.

  4. In the repository, change directory (cd) to the templates/elz-workload/ directory. This is the main template for the workload expansion.

  5. Create a terraform.tfvars file in the directory and populate it with the required variables or override existing variables. To reference the configuration variable values, see the Configuration Guide. For a list of all available configuration variables, see the Input Variables Reference in the README.

    Note: An example tfvars file (workload_extension.tfvars) is included for reference. We recommend using this file to run the stack from the CLI because of the large number of variables to manage.

  6. From the root of the module, run the following commands to deploy the Terraform.

    • terraform init
    • terraform plan
    • terraform apply
  7. When it's finished, Terraform provisions your resources and provides outputs.

  8. Follow the steps in the After Deploying the Workload Expansion section to re-run the apply and update the configuration

After Deploying the Workload Expansion

Return to the baseline stack enterprise-landing-zone to re-run Terraform apply and update the baseline configuration.

Terraform CLI

Use the following information to update with the Terraform CLI.

  1. Navigate to the baseline stack enterprise-landing-zone.

  2. Use the following information to add the variables to your tfvars file.

    NameDescriptionTypeDefaultRequired
    nonprod_additional_workload_subnets_cidr_blocksList of 3 subnets CIDR blocks used in the workload expansion. (Don't include the CIDR blocks created in the baseline.)list(string) Yes
    nonprod_workload_compartment_namesWorkload compartment name. (Also include the workload name created in the baseline.)list(string) Yes

    If your workload expansion was deployed in Prod, instead use the following variables.

    NameDescriptionTypeDefaultRequired
    prod_additional_workload_subnets_cidr_blocksList of 3 subnets CIDR blocks used in the workload expansion. (Don't include the CIDR blocks created in the baseline.)list(string) Yes
    prod_workload_compartment_namesWorkload compartment name. (Also include the workload name created in the baseline.)list(string) Yes
  3. From the root of the module, run the following commands to deploy the Terraform:

    • terraform init
    • terraform plan
    • terraform apply
  4. The subnet CIDR blocks are used to update the route table in Hub.

  5. The workload name is used to update the related policy in the environment.

Resource Manager

Use the following steps to deploy with Resource Manager.

  1. From the Console home page, navigate to Developer Services, Resource Manager, and then select Stacks.

  2. Select the compartment that you want to create the stack in, and then select Create stack.

  3. Select the source code control system for the Terraform source.

  4. In the Stack Configuration box, under Source Code Management Type, select GitHub.

  5. Under the configuration source provider, if you have a provider set up for public GitHub, you can select it, and then skip to step 9. Otherwise, select Create configuration source provider.

  6. If you don't have a Personal Access Token for your GitHub account, log in to GitHub and create one. You can find this option under Settings, Developer settings, Personal access tokens, Tokens (classic) on the GitHub site. The token must have the repo scope.

  7. To create the configuration provider for GitHub in OCI, complete the form for creating a configuration source provider:

    • Name: GitHub
    • Description: (Optional) Public Github Repositories
    • Select the Public Endpoint option.
    • Type: GitHub
    • Server URL: https://github.com/
    • Personal Access Token: #Your Personal Access Token#
  8. Click Create to create the config provider.

  9. For the repository, select oci-landing-zones.

  10. For the branch, select, main.

  11. For the working directory, select templates/elz-workload.

  12. For the name, give the stack a name or accept the default.

  13. For Create in Compartment, select the compartment in which to store the stack.

  14. For the Terraform version, select 1.0.x or later. Previous Terraform versions aren't supported.

    After completing the Stack Creation Wizard, the subsequent step prompts for variables values. To reference the configuration variable values, see the Configuration Guide. For a list of all available configuration variables, see the Input Variables Reference in the README

    After entering the required input variables, click Next to review the stack values and create the stack.

    In the Stack page, use the appropriate buttons to plan, apply, or destroy your stack.

  15. Follow the steps in the After Deploying the Workload Expansion (Resource Manager) section to re-run the apply with the updated stack.

After Deploying the Workload Expansion

Return to the baseline stack enterprise-landing-zone to re-run Terraform apply and update the baseline configuration.

Resource Manager

Use the following information to update with Resource Manager.

  1. Navigate to the baseline stack in Resource Manager.
  2. Go to the variables section of the baseline stack, and then add the values: nonprod_additional_workload_subnets_cidr_blocks and nonprod_workload_compartment_names or prod_additional_workload_subnets_cidr_blocks and prod_workload_compartment_names.
  3. Click Terraform Apply to update the stack

User

The OELZ Workload Expansion should be deployed by a user who is a member of the Administrators group for the tenancy. The user must have an API key entry defined as described here. When the user and API Key are defined, your oci-cli config should resemble:

[DEFAULT]
user=ocid1.xxxxxx.xxxxxx.xxxxxx.....  #ocid of the user
fingerprint=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx #user api key fingerprint
tenancy=ocid1.xxxxxx.xxxxxx.xxxxxx..... #tenancy ocid
region=us-phoenix-1 #or desired region
key_file=<path to your private keyfile> # TODO

Region

The OELZ workload is deployed as L3 on the user defined parent compartment OCID.

Compartment Structure

The following information provides the compartment architecture for OELZ. The OELZ workload compartment is deployed in the user defined parent compartment OCID. There are two deployment scenarios:

First Case: The workload expansion is deployed in the Prod environment.

Prod

  • Shared Infrastructure
    • Network
    • Security
  • Workload
  • Logging
  • Backup
  • Workload Expansion

Second Case: The workload expansion is deployed in the Non-Prod environment.

Non Prod

  • Shared Infrastructure
    • Network
    • Security
  • Workload
  • Logging
  • Backup
  • Workload Expansion

Workload Expansion: Network

The OELZ Workload Expansion stack deploys one spoke VCN on the user defined compartment. It deploys VCN Gateway like Nat Gateway and Service Gateway, Security Rules, and Route Tables, according to user preference, and attaches the VCN to the configured DRG. There are three subnets for Web, App, and DB Application Resources.

Logging for the Oracle Enterprise Landing Zone is configured at the environment level, with logs for all workloads within a given environment sent to the object storage buckets set up according to each environment, in addition to an archive bucket for all environments, with a long term retention policy. A logging configuration for each workload isn't needed.

Workload Expansion: Policy

As part of workload expansion, three user groups are created: Workload Admin, Application Admin, and Database Admin. We're adding a default policy so that newly created user groups have fine-grained access to workload resources.

Workload Expansion: Monitoring

The workload expansion creates a series of monitoring alarms (11 Critical alarms and 6 Warning alarms) for each workload it creates. Notifications created by these triggered alarms are delivered by email to a list of email addresses (the workload_topic_endpoints) specified for that workload.