Oracle Enterprise Landing Zone v2 - Workload Expansion Implementation
The following information describes how to implement the Oracle Enterprise Landing Zone (OELZ) v2 Workload Expansion.
Prerequisites
The prerequisites for deploying the OELZ Workload Expansion from the Terraform CLI are:
- Latest Version of Terraform
- OCI Terraform provider v4.109.0 or later
- OCI CLI
- Oracle Enterprise Landing Zone is deployed. See Oracle Enterprise Landing Zone v2 Implementation.
- If you need to deploy multiple workloads, copy and paste the elz-workload folder to deploy each workload separately.
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.
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.
Set up API keys to work with your OCI account. Follow the instructions here.
Go to the GitHub page to clone the Terraform template.
In the repository, change directory (cd) to the
templates/elz-workload/
directory. This is the main template for the workload expansion.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.
From the root of the module, run the following commands to deploy the Terraform.
terraform init
terraform plan
terraform apply
When it's finished, Terraform provisions your resources and provides outputs.
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.
Navigate to the baseline stack
enterprise-landing-zone
.Use the following information to add the variables to your tfvars file.
Name Description Type Default Required nonprod_additional_workload_subnets_cidr_blocks List 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_names Workload 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.
Name Description Type Default Required prod_additional_workload_subnets_cidr_blocks List 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_names Workload compartment name. (Also include the workload name created in the baseline.) list(string)
Yes From the root of the module, run the following commands to deploy the Terraform:
terraform init
terraform plan
terraform apply
The subnet CIDR blocks are used to update the route table in Hub.
The workload name is used to update the related policy in the environment.
Resource Manager
Use the following steps to deploy with Resource Manager.
From the Console home page, navigate to Developer Services, Resource Manager, and then select Stacks.
Select the compartment that you want to create the stack in, and then select Create stack.
Select the source code control system for the Terraform source.
In the Stack Configuration box, under Source Code Management Type, select GitHub.
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.
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.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#
Click Create to create the config provider.
For the repository, select oci-landing-zones.
For the branch, select, main.
For the working directory, select templates/elz-workload.
For the name, give the stack a name or accept the default.
For Create in Compartment, select the compartment in which to store the stack.
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.
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.
- Navigate to the baseline stack in Resource Manager.
- Go to the variables section of the baseline stack, and then add the values:
nonprod_additional_workload_subnets_cidr_blocks
andnonprod_workload_compartment_names
orprod_additional_workload_subnets_cidr_blocks
andprod_workload_compartment_names
. - 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.