A1 Configuration Has Been Deprecated in Favor of EL2 EC2 Linux Launch
To use EL2, as user devops  change directory to  /root/terraformation/el2  and take advantage of its many advanced features, which are amazing to watch in action:





a1 Configuration Features

a1 configuration allows you to automate and avoid the need to use the AWS console for:

  • the creation of a single EC2 instance in any region
  • the selection of the latest official Amazon Linux 2 AMI
  • the selection of the latest official Ubuntu Xenial AMI from Canonical
  • the selection of the latest official Ubuntu Trusty AMI from Canonical

    • Official Amazon Linux and Ubuntu AMIs change frequently for all regions, making automated selection of the current IDs useful in eliminating the risk of specify an old or invalid image.

  • the selection of any AMI of your choice, instead of automatic selection of the newest AMI from one of the above mentioned distributions
  • the provision of a public IP address and domain name
  • the insertion of an SSH public key, readying your instance for immediate SSH access upon its creation

a1 Configuration Parameters

region
AWS Region Code such as us-east-1, representing one of twenty regions. The comments in vars.tf  list all possible values that may be used
access_key
IAM Access key ID
secret_key
IAM Secret access key
[instance_type]
EC2 instance type that defaults to t2.micro ,  which is Free Tier compatible
[public_key]
SSH public key to insert into the EC2 instance allowing SSH access, given ownership of the corresponding private key. This could be omitted if for example the instance would have some other communication facility, or serves a non-communicative purpose
[ami]
region specific AMI ID, which if given will cause linux_distro to be ignored
[linux_distro]
trusty, xenial and amazon (the default) are the possible values, respectively specifying the latest official Ubunty Trusty, Ubuntu Xenial, and Amazon Linux 2 AMIs for the region specified by region

[…] indicates an optional parameter

a1 Configuration Example Runs

As user devops  from within the a1 subdirectory:

Initialize the Terraform AWS provider with the terraform init command:


devops@stretch:/root/terraformation/a1$ terraform init

Initializing provider plugins...

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.
devops@stretch:/root/terraformation/a1$

Decide on your parameter values and whether to specify them on the command line with subsequent Terraform subcommands or in the vars.tf  file, or a mixture of both. Use the -var ‘parameter=value’  syntax to append Terraform subcommands as needed, or edit vars.tf  accordingly with either the vi(vim), nano, pico or mg editors. Note that storing IAM credentials in such a plain text file should not be a production practice. Consider using both mechanisms to gain convenience and a measure of security.

Remember to use the terraform destroy command to tear down infrastructure that is not needed. Only the region, access_key  and secret_key  parameters need to be passed, but using it with all the same parameters as the terraform apply command would work.

To make Terraform’s apply and destroysubcommands non-interactive use them with the -auto-approve option.

Terraform is all about workflow, terraform plan for dry running is worth finding out about (you run it like the apply subcommand with the same options apart from -auto-approve). There’s obviously vastly more to Terraform workflow than that, it requires experience and intuition, but that is all secondary, the most important thing is to get the actual working Infrastructure as Code (IaC) – from somewhere – get the actual software – so can just run it and get the benefits.

For a1 you need the AmazonEC2FullAccess policy for your IAM user. If you’re sure you’ve specified your IAM keys correctly and you see the following error when doing a terraform plan or terraform apply:

AuthFailure: AWS was not able to validate the provided access credentials

This is due to clock skew between the VM and AWS. Resetting the time within the VM to match your host system (assuming that’s roughly right for your time zone), will fix the issue. You can do this with this form of the date +%T -s “HH:MM:SS”  command, so that would look this if resetting the VM time to 7:51pm for example:


devops@stretch:/root/terraformation/a1$ date +%T -s "19:51:00"
19:51:00 
devops@stretch:/root/terraformation/a1$

 


Using all defaults to launch an instance of the latest official Amazon Linux 2 AMI

Only the three mandatory parameters would be required and if specifying them on the command line, this could be achieved with:

terraform apply -var 'region=us-west-1' -var 'access_key=...' -var 'secret_key=...'

in the case of the intended region being US West (N. California). The linux_distro parameter doesn’t have to be set if Amazon Linux 2 is needed as this will be selected by default.

An a1 run gives you a nice report, with just the essential information you need to make use of your instance:


...
aws_key_pair.rn: Creation complete after 2s (ID: a1kp)
aws_default_subnet.first_available_az: Creation complete after 3s (ID: subnet-1.....7a)
aws_instance.latest_amazon_linux_2: Still creating... (10s elapsed)
aws_instance.latest_amazon_linux_2: Still creating... (20s elapsed)
aws_instance.latest_amazon_linux_2: Creation complete after 30s (ID: i-00...……...85cff)

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

amazon_arn = [
    arn:aws:ec2:ap-south-1:...…..7887:instance/i-00...……..5cff
]
amazon_id = [
    i-...……….5cff
]
amazon_public_dns = [
    ec2-.-...-91-144.ap-south-1.compute.amazonaws.com
]
amazon_public_ip = [
    …....91.144
]

specific_arn = []
specific_id = []
specific_public_dns = []
specific_public_ip = []
trusty_arn = []
trusty_id = []
trusty_public_dns = []
trusty_public_ip = []
xenial_arn = []
xenial_id = []
xenial_public_dns = []
xenial_public_ip = []
devops@stretch:/root/terraformation/a1$

Remember to login as ec2-user  when connecting with SSH using the public IP or domain name.

 

Launching an instance of the latest official Ubuntu Xenial AMI

If your intended region has already been specified in vars.tf,  this would suffice to launch an instance of the latest official Ubuntu Xenial Xerus 16.04 LTS AMI:

terraform apply -var 'access_key=...' -var 'secret_key=...' -var 'linux_distro=xenial'

You would then be able to login via SSH as user ubuntu.

 

Launching an instance of the latest official Ubuntu Trusty AMI

Similarly the latest official Ubuntu Trusty Tahr 14.04 LTS AMI can be chosen thus (a region being specified on the command line in this example):

terraform apply -var 'region=ap-northeast-1' -var 'access_key=...' -var 'secret_key=...' -var 'linux_distro=trusty'

As with Xenial, login via SSH as user ubuntu.

 

Launching an instance of your specified AMI

A specific choice of AMI can be selected by an AMI ID:

terraform apply -var 'region=...' -var 'access_key=...' -var 'secret_key=...' -var 'ami=ami-...'

Below all three mandatory parameters; region, access_key and secret_key, have been omitted from the command line, so would have to have been supplied in vars.tf :

terraform apply -var 'ami=ami-...'

If appropriate for your situation absolutely all parameters can be supplied in vars.tf, terraform apply being all that’s needed.