Terraform Again

Terraform frequent commands

$ cat /tmp/tfhelp | awk '{$1=$1;print}' | awk -F ' ' '{$1=""; print $0}' | sort -u
 cat terraform
 cat /usr/local/bin/terraform
 cd .terraform/modules/cell_shared.databricks_email_notification/
 cd .terraform/modules/cell_shared.databricks_email_notification/modules
 history | grep terraform > /tmp/tfhelp
 rm -rf .terraform && terraform init
 rm -rf .terraform && terraform init && terraform plan -out tf.plan
 rm -rf .terraform && terraform init && terraform plan -out tf.plan | tee -a out.plan
 rm -rf .terraform && terraform init && terraform plan -out tf.plan | tee /tmp/wfplan
 rm -rf .terraform && terraform init && terraform plan -out tf.plan | tee /tmp/wfplan2
 terraform apply
 terraform apply "tf.plan"
 terraform apply tf.plan
 terraform apply "tf.plan" terraform apply "tf.plan" terraform apply "tf.plan"terraform apply "tf.plan"
 terraform destroy
 terraform destroy --target=module.nomad.module.nomad_cluster.aws_autoscaling_group.nomad[0]
 terraform destroy --target=module.ops_tgw.aws_ram_resource_share.ops_tgw
 terraform init
 terraform init && terraform plan -out tf.plan
 terraform output
 terraform outputs
 terraform plan
 terraform plan -out tf.plan
 terraform plan -out tf.plan && terraform apply tf.plan
 terraform resources
 terraform state list
 terraform state list |grep boot
 terraform state list |grep vault
 terraform state list |grep vault |grep boot
 terraform state outputs
 terraform taint module.vault_bootstrap.null_resource.vault_bootstrap
 TF_DEBUG=true && terraform plan -out tf.plan
 TF_LOG=DEBUG && terraform apply tf.plan
 TF_LOG=DEBUG && terraform plan -out tf.plan
 vim terraform
 vim .terraform/modules/cell_shared.databricks_email_notification/main.tf
 vim .terraform/modules/cell_shared.databricks_email_notification/modules/
 vim .terraform/modules/cell_shared.databricks_email_notification/modules/api_gateway/main.tf
 vim .terraform/modules/cell_shared.databricks_email_notification/modules/lambda_function/main.tf
 vim .terraform/modules/cell_shared.zookeeper/modules/zookeeper_nomad_job/main.tf
 vim .terraform/modules/cell_shared.zookeeper/modules/zookeeper_nomad_job/zookeeper_server_nomad.tpl
 vim /usr/local/bin/terraform
 vi .terraform/modules/cell_eap/kube_application_roles.tf
 vi .terraform/modules/cross_connectivity_for_crypter_usw2_vpc/modules/cross_connectivity/main.tf
 vi .terraform/modules/vault_config/auth/aws/main.tf
 vi .terraform/modules/vault_config/auth/aws/variables.tf
 which terraform

Hashicorp App Delivery flow and Tools

The workflow


A) DEVELOPMENT:

First the developer develops the App

B) TESTING:

Once the app is developed, we then move to the next stage of Testing
TDD is complete

C) STATIC Code Analysis:

The next stage is Packaging. This is where we come to the stage of  using
 1) Configuraiton Management
  2) Security
  3) Compliance

Take all of the above and transform the code into something, that is a production worthy image.


Once we have packaged our application, then how do we do provisioning

1) Day 1 - nothing running, where we go from nothing to something
2) Day 2 - how do we continue to Evolve ?

Day2 challenge is much mor eimportant and challenging because we are in production.

Our Next challenge is Deployment

How do we take an application that we manage and Deploy on the infrastructure we just provisioned

The Goal here is two fold
Once we do our deployment, now we have to monitor it to make sure it stays up and running



Monitoring is its own universe:
It is everything from , logging, telemetry, tracing, health checking and alerting

Once our application is in production, will we be notified if it goes down

1) Logs
2) Telemetry
3) Tracing
4) Health Check
5) Alert *
6)

Any production system is a big black bog
Do we have enough observability ?

The ability to have enough probes and hooks into the system to understand whats gone wrong once we get alerted.

What do we do to get the alert remediated and get the system online


Security ?:
How do we harden this this ?


What we really have to do is to think about security throughout the pipeline and harden so that we do not have any weakest link.






Hashicorp has strong adoptability over Workflow

Tight  UNIX philosophy

Do one thing and do it well


Vagrant - Test phase

Provide a developer environment - local VM or a dockerized environment , so that we have a dev test parity.




VAGRANT File:
Describe everything we need to build a developer environment

When i join the company - i run vagrant up and i have a developer environment

Goal of packer is to consume all the inputs and specify what our output is .

src, config ,

What we need output of all the configuration is to get out an AMI

Version it , checkou t the files
Understand incrementally , who changed what ?

Manually point to and clicking one of the golden images

Terraform - Ec2 instance

Terraform is configured using a high-level, expressive configuration syntax to describe the resources that make up your infrastructure.


First create the main.tf file
Then we see the following

 main.tf


workbook:terraform workbookcode$ pwd
/Users/workbookcode/repos/terraform
workbook-ltm1:terraform workbookcode$ subl .
workbook-ltm1:terraform workbookcode$ pwd
/Users/workbookcode/repos/terraform
workbook-ltm1:terraform workbookcode$ terraform init
There are some problems with the configuration, described below.

The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.

Error: Argument or block definition required

  on main.tf line 13, in resource "aws_instance" "web":

An argument or block definition is required here.

workbook-ltm1:terraform workbookcode$ terraform init

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (terraform-providers/aws) 2.13.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.13"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.



#-----------------------------------------------------------------------------------------------------------------

In the example above, I am creating a machine on the region “us-east-1” using the profile “terraform”.


My machine size is t2.micro and it is using the AMI ami-0e55e373 , which is a Ubuntu 17.04 image available for the region “us-east-1”.
Note : Ubuntu 17.04 image doesn’t have the same AMI id in two different regions.


One issue with the main.tf  was that, the  region had a typo in it

Instead of us-east-1 . it was . eu-east-1 . and terraform was erroring out





Now as we move on, we keep on adding the variables that we can use in the terraform







variable "region" {
  default = "us-east-1"
}

variable "shared_credentials_file" {
  default = "/Users/asdf/.aws/credentials"
}

variable "profile" {
  default = "terraform"
}

provider "aws" {
  region                  = "us-east-1"
  shared_credentials_file = "/Users/asdf/.aws/credentials"
  profile                 = "terraform"
}

resource "aws_instance" "artifactory_test" {
  ami = "ami-04d587fb777042a31"
  instance_type = "t2.micro"
  tags = {
    Name = "artifactory_test"
  }
}