td devops infrax templates

Tech Design - Infrastrucutre Templates (WIP | Still In Review)

This document describes the direction of the infrastructure template structure.

Heirarchy & Scopes

The infrastructure deployed will first be divided between infrastructure that is utilized by multiple applications and infrastructure dedicated to an individual application.

Domain

Domain infrastructure would be used by multiple applications and environments. Examples of domain infrastructure would be Container Registry and Service Principals.

• Multiplicity -> 1 instance per domain
• Deployment Access Required -> User Access Administrator

The domain infrastructure requires the highest level of access to the Azure Tenant and Subscription. Due to the elevated privilege requirement, its expected the the deployment is done manually by teams that have (or near) Owner level privileges to subscriptions. Additionally, since this has the lowest multiplicity its expected the deployment would be infrequent.

Platform

Platform infrastructure would be used by multiple applications within the same environment. Examples of this type of infrastructure would be Virtual Networks and Key Vault.

• Multiplicity -> 1 instance per domain and environment
• Deployment Access Required -> Network Contributor

The environment infrastructure requires slightly elevated privileges to manage network resources such as the virtual network and/or express route. Since its expected that every environment will require an instance of this infrastructure, the deployment should be automated.

App

App infrastructure would be provisioned to serve a single application within the same environment. Examples of this type of infrastructure would be Web App, App Service Plan, and Application Gateway.

• Multiplicity -> 1 instance per domain, environment, and app
• Deployment Access Required -> Contributor

Since its expected that there will be the most instances of this infrastructure deployed of any of the types, the deployment will be automated.

Template Repo Structure

The repository will be divided into three sections. These sections align to each of the scopes outlined above.

./domain
    - deploy.sh
    - readme.md
./platform
    - main.tf
    - variables.tf
./app
    - main.tf
    - variables.tf

Note that the domain scope does not have terraform templates. This is due to the elevated privileges and low frequency at which this script should be run. Its intentionally developed for manual execution. This should assist in making sure its execution is intentional and deliberate.

The platform and app scopes will be deployed using terraform as they will be automated and have a much larger number of instances deployed.

Scope Contracts (Inputs)

The following describes the expected inputs of each scope. The inputs drive two functions. First, they are used to automatically name resources according to the project naming convention. Second, the inputs will drive the instantiation of each scope. See Instantiating the Scopes for how inputs drive instantiation.

Domain Inputs

Input	Max Chars	Examples	Description
Domain	4	cblt (short for cobalt)	The name of the domain for which the infrastructure supports.
Location	n/a	eastus	The azure location to which the resources should be deployed.

deploy.sh -d "cblt" -l "eastus"

Platform Inputs

Input	Max Chars	Examples	Description
Domain	4	cblt (short for cobalt)	The name of the domain for which the infrastructure supports.
Location	n/a	eastus	The azure location to which the resources should be deployed.
Environment	4	dev	The name of the environment for which infrastructure supports.

terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev"

App Inputs

Input	Max Chars	Examples	Description
Domain	4	cblt (short for cobalt)	The name of the domain for which the infrastructure supports.
Location	n/a	eastus	The azure location to which the resources should be deployed.
Environment	4	dev	The name of the environment for which infrastructure supports.
Application	4	inv (short for inventory)	The short name of the application for which the infrastructure supports.

terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev" -var "app=inv"

Instantiating the Scopes

This section will describe how multiple instances of each scope would be created. As mentioned earlier, instantiating the scopes is driven by the inputs provided. The examples below illustrate how input values control how many instances of each scope exist.

Deploying Multiple Domain Instances

deploy.sh -d "cblt" -l "eastus"
deploy.sh -d "cblt" -l "westus"

Then two the following two instances of Container Registry would be created

• useaacrcblt
• usweacrcblt

However if the same command was executed twice with the same args as follows:

deploy.sh -d "cblt" -l "eastus"
deploy.sh -d "cblt" -l "eastus"

Only one instance of Container Registry should exist

• useaacrcblt

Deploy the Platform Infrastructure to Multiple Environments

Lets assume in this example the Platform Infrastructure provisions an instance of Key Vault to manage secrets.

If the following commands were executed

terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev"
terraform apply -var "domain=cblt" -var "location=eastus" -var "env=qa"
terraform apply -var "domain=cblt" -var "location=westus" -var "env=stg"

The following instances of key vault would be provisioned

• usea-kv-dev-cblt
• usea-kv-qa-cblt
• usea-kv-stg-cblt

Three instances of key vault are deployed that are uniquely named according to the inputs provided.

Deploy the App Infrastructure to Multiple Environments

Assume in this example that the Application Insfrastructure provisions a Web App.

If the following commands were executed

terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev" -var "app=inv"
terraform apply -var "domain=cblt" -var "location=eastus" -var "env=qa" -var "app=inv"
terraform apply -var "domain=cblt" -var "location=eastus" -var "env=stg" -var "app=inv"

The following instances of web app would be provisioned

• inv-usea-web-dev-cblt
• inv-usea-web-qa-cblt
• inv-usea-web-stg-cblt

Three instances of key vault are deployed that are uniquely named according to the inputs provided.

Deploy New Domain, Environment, and App

Assuming each scope provisions the following infrastructure

• domain -> Container Registry
• platform -> Key Vault
• app -> Web App

If the following commands were executed

cd ./domain     && deploy.sh -d "cblt" -l "eastus" && cd ..
cd ./platform   && terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev" && cd ..
cd ./app        && terraform apply -var "domain=cblt" -var "location=eastus" -var "env=dev" -var "app=inv"

The following infrastructure would be provisioned

• useaacrcblt (Container Registry deployed to East US)
• usea-kv-dev-cblt (Key Vault for Dev Environment deployed to East US)
• inv-usea-web-dev-cblt (Web App for Inventory app for Dev Environment deployed to East US)