OCI Notes

Terraform Provider https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/terraformproviderconfiguration.htm https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/terraformproviderconfiguration.htm#environmentVariables OCI CLI Requirements: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm#Requirements Quick start: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm#Quickstart Environment variables: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/clienvironmentvariables.htm Authenticate: To refresh the token: Examples https://github.com/oracle/terraform-provider-oci/tree/master/examples AVX Access Account https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm#five https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm Do not forget to click the add button to add the private key to the user. Supported Instance Sizes Regions and Availability Domains https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm Minimal Required OCI IAM Policy Bound by Compartment Continue reading OCI Notes

Using GitHub Actions to deploy Aviatrix

Automating Terraform with CI/CD enforces configuration best practices, promotes collaboration and automates the Terraform workflow. GitHub Actions Prime Actions An action is a custom application for the GitHub Actions platform that performs a repeated task. GitHub Actions is composed by: Workflow Workflows are defined by a YAML in a repository and will run when triggered by an event or manually. A workflow contains one or more jobs which can run in sequential order or in parallel. Jobs A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script … Continue reading Using GitHub Actions to deploy Aviatrix

5 min RTO with Aviatrix and Terraform

Disaster recovery involves a set of policies, tools, and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. The Recovery Time Objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. I covered using Aviatrix to address the challenges of DR/BC before: In this new blog I address a new set of requirements: Proposed Design The proposed solution has the following major … Continue reading 5 min RTO with Aviatrix and Terraform

From 0 to 100 mph with Aviatrix and Terraform

Credit to Zack (https://www.linkedin.com/in/zack-schaefer/) on creating a high-available and disaster ready architecture on Azure using Aviatrix. Thanks also to Mr Smoker (https://www.linkedin.com/in/johnsmoker/) and Dennis (https://www.linkedin.com/in/dennishagens/) for helping directly and indirectly :). The gist shared below creates the following topology: The VMs are running NGINX on port 80 and the traffic manager favors East. Transit and Firenet Peering Spokes VMs East: Central: Load Balancers Standalone Gateways SNAT DNAT Traffic Manager Provider Variables Continue reading From 0 to 100 mph with Aviatrix and Terraform

Deploying an Aviatrix FireNet on Azure with Fortinet FortiGate

Aviatrix Transit FireNet allows the deployment of 3rd party firewalls onto the Aviatrix transit architecture. Transit FireNet works the same way as the Firewall Network where traffic in and out of the specified Spoke is forwarded to the firewall instances for inspection or policy application. FireNet Design The diagram below shows the Aviatrix Firenet design for Azure. When a transit gateway is deployed with the firenet option checked, the Aviatrix controller will: create subnets create UDRs create an internal NLB configure the internal NLB (front end, back-end, healtch check) Aviatrix deploys and configures the Internal Load Balancers for a Firenet. … Continue reading Deploying an Aviatrix FireNet on Azure with Fortinet FortiGate