Terraform – Page 2 – A nice guy's view on life

"Field Notes - Sweet Tooth" by "The Marmot" on Flickr

Multi-OS builds in AWS with Terraform – some notes from the field!

2020-05-222020-05-22 JonTheNiceGuy Leave a comment

Late edit: 2020-05-22 – Updated with better search criteria from colleague conversations

I’m building a proof of concept for … well, a product that needs testing on several different Linux and Windows variants on AWS and Azure. I’m building this environment with Terraform, and it’s thrown me a few curve balls, so I thought I’d document the issues I’ve had!

The versions of distributions I have tested are the latest releases of each of these images at-or-near the time of writing. The major version listed is the earliest I have tested, so no assumption is made about previous versions, and later versions, after the time of this post should not assume any of this data is also accurate!

(Fujitsu Staff – please contact me on my work email address for details on how to get the internal AMIs of our builds of these images 😄)

Linux Distributions

On the whole, I tend to be much more confident and knowledgable about Linux distributions. I’ve also done far more installs of each of these!

Almost all of these installs are Free of Charge, with the exception of Red Hat Enterprise Linux, which requires a subscription fee, and this can be “Pay As You Go” or “Bring Your Own License”. These sorts of things are arranged for me, so I don’t know how easy or hard it is to organise these licenses!

These builds all use cloud-init, via either a cloud-init yaml script, or some shell scripting language (usually accepted to be bash). If this script fails to execute, you will find your user-data file in /var/lib/cloud/instance/scripts/part-001. If this is a shell script then you will be able to execute it by running that script as your root user.

Amazon Linux 2 or Amzn2

Amazon Linux2 is the “preferred” distribution for Amazon Web Services (AWS) (surprisingly enough). It is based on Red Hat Enterprise Linux (RHEL), and many of the instructions you’ll want to run to install software will use RHEL based instructions. This platform is not available outside the AWS ecosystem, as far as I can tell, although you might be able to run it on-prem.

Software packages are limited in this distribution, so any “extra” features require the installation of the “EPEL” repository, by executing the command sudo amazon-linux-extras install epel and then using the yum command to install further packages. I needed nginx for part of my build, and this was only in EPEL.

Amzn2 AMI Lookup

data "aws_ami" "amzn2" {
  most_recent = true

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-2.0.*-gp2"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["amazon"] # Canonical
}

Amzn2 User Account

Amazon Linux 2 images under AWS have a default “ec2-user” user account. sudo will allow escalation to Root with no password prompt.

Amzn2 AWS Interface Configuration

The primary interface is called eth0. Network Manager is not installed. To manage the interface, you need to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and apply changes with ifdown eth0 ; ifup eth0.

Amzn2 user-data / Cloud-Init Troubleshooting

I’ve found the output from user-data scripts appearing in /var/log/cloud-init-output.log.

CentOS 7

For starters, AWS doesn’t have an official CentOS8 image, so I’m a bit stymied there! In fact, as far as I can make out, CentOS is only releasing ISOs for builds now, and not any cloud images. There’s an open issue on their bug tracker which seems to suggest that it’s not going to get any priority any time soon! Blimey.

This image may require you to “subscribe” to the image (particularly if you have a “private marketplace”), but this will be requested of you (via a URL provided on screen) when you provision your first machine with this AMI.

Like with Amzn2, CentOS7 does not have nginx installed, and like Amzn2, installation of the EPEL library is not a difficult task. CentOS7 bundles a file to install the EPEL, installed by running yum install epel-release. After this is installed, you have the “full” range of software in EPEL available to you.

CentOS AMI Lookup

data "aws_ami" "centos7" {
  most_recent = true

  filter {
    name   = "name"
    values = ["CentOS Linux 7*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["aws-marketplace"]
}

CentOS User Account

CentOS7 images under AWS have a default “centos” user account. sudo will allow escalation to Root with no password prompt.

CentOS AWS Interface Configuration

The primary interface is called eth0. Network Manager is not installed. To manage the interface, you need to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and apply changes with ifdown eth0 ; ifup eth0.

CentOS Cloud-Init Troubleshooting

I’ve run several different user-data located bash scripts against this system, and the logs from these scripts are appearing in the default syslog file (/var/log/syslog) or by running journalctl -xefu cloud-init. They do not appear in /var/log/cloud-init-output.log.

Red Hat Enterprise Linux (RHEL) 7 and 8

Red Hat has both RHEL7 and RHEL8 images in the AWS market place. The Proof Of Value (POV) I was building was only looking at RHEL7, so I didn’t extensively test RHEL8.

Like Amzn2 and CentOS7, RHEL7 needs EPEL installing to have additional packages installed. Unlike Amzn2 and CentOS7, you need to obtain the EPEL package from the Fedora Project. Do this by executing these two commands:

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install epel-release-latest-7.noarch.rpm

After this is installed, you’ll have access to the broader range of software that you’re likely to require. Again, I needed nginx, and this was not available to me with the stock install.

RHEL7 AMI Lookup

data "aws_ami" "rhel7" {
  most_recent = true

  filter {
    name   = "name"
    values = ["RHEL-7*GA*Hourly*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["309956199498"] # Red Hat
}

RHEL8 AMI Lookup

data "aws_ami" "rhel8" {
  most_recent = true

  filter {
    name   = "name"
    values = ["RHEL-8*HVM-*Hourly*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["309956199498"] # Red Hat
}

RHEL User Accounts

RHEL7 and RHEL8 images under AWS have a default “ec2-user” user account. sudo will allow escalation to Root with no password prompt.

RHEL AWS Interface Configuration

The primary interface is called eth0. Network Manager is installed, and the eth0 interface has a profile called “System eth0” associated to it.

RHEL Cloud-Init Troubleshooting

In RHEL7, as per CentOS7, logs from user-data scripts are appear in the general syslog file (in this case, /var/log/messages) or by running journalctl -xefu cloud-init. They do not appear in /var/log/cloud-init-output.log.

In RHEL8, logs from user-data scrips now appear in /var/log/cloud-init-output.log.

Ubuntu 18.04

At the time of writing this, the vendor, who’s product I was testing, categorically stated that the newest Ubuntu LTS, Ubuntu 20.04 (Focal Fossa) would not be supported until some time after our testing was complete. As such, I spent no time at all researching or planning to use this image.

Ubuntu is the only non-RPM based distribution in this test, instead being based on the Debian project’s DEB packages. As such, it’s range of packages is much wider. That said, for the project I was working on, I required a later version of nginx than was available in the Ubuntu Repositories, so I had to use the nginx Personal Package Archive (PPA). To do this, I found the official PPA for the nginx project, and followed the instructions there. Generally speaking, this would potentially risk any support from the distribution vendor, as it’s not certified or supported by the project… but I needed that version, so I had to do it!

Ubuntu 18.04 AMI Lookup

data "aws_ami" "ubuntu1804" {
  most_recent = true

  filter {
    name   = "name"
    values = ["*ubuntu*18.04*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["099720109477"] # Canonical
}

Ubuntu 18.04 User Accounts

Ubuntu 18.04 images under AWS have a default “ubuntu” user account. sudo will allow escalation to Root with no password prompt.

Ubuntu 18.04 AWS Interface Configuration

The primary interface is called eth0. Network Manager is not installed, and instead Ubuntu uses Netplan to manage interfaces. The file to manage the interface defaults is /etc/netplan/50-cloud-init.yaml. If you struggle with this method, you may wish to install ifupdown and define your configuration in /etc/network/interfaces.

Ubuntu 18.04 Cloud-Init Troubleshooting

In Ubuntu 18.04, logs from user-data scrips appear in /var/log/cloud-init-output.log.

Windows

This section is far more likely to have it’s data consolidated here!

Windows has a common “standard” username – Administrator, and a common way of creating a password (this is generated on-boot, and the password is transferred to the AWS Metadata Service, which it is retrieved and decrypted with the SSH key you’ve used to build the “authentication” to the box) which Terraform handles quite nicely.

The network device is referred to as “AWS PV Network Device #0”. It can be managed with powershell, netsh (although apparently Microsoft are rumbling about demising this script), or from the GUI.

Windows 2012R2

This version is very old now, and should be compared to Windows 7 in terms of age. It is only supported by Microsoft with an extended maintenance package!

Windows 2012R2 AMI Lookup

data "aws_ami" "w2012r2" {
  most_recent = true

  filter {
    name = "name"
    values = ["Windows_Server-2012-R2_RTM-English-64Bit-Base*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["801119661308"] # AWS
}

Windows 2012R2 Cloud-Init Troubleshooting

Logs from the Metadata Service can be found in C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt. You can also find the userdata script in C:\Program Files\Amazon\Ec2ConfigService\Scripts\UserScript.ps1. This can be launched and debugged using PowerShell ISE, which is in the “Start” menu.

Windows 2016

This version is reasonably old now, and should be compared to Windows 8 in terms of age. It is supported until 2022 in “mainline” support.

Windows 2016 AMI Lookup

data "aws_ami" "w2016" {
  most_recent = true

  filter {
    name = "name"
    values = ["Windows_Server-2016-English-Full-Base*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["801119661308"] # AWS
}

Windows 2016 Cloud-Init Troubleshooting

The metadata service has moved from Windows 2016 and onwards. Logs are stored in a partially hidden directory tree, so you may need to click in the “Address” bar of the Explorer window and type in part of this path. The path to these files is: C:\ProgramData\Amazon\EC2-Windows\Launch\Log. I say “files” as there are two parts to this file – an “Ec2Launch.log” file which reports on the boot process, and “UserdataExecution.log” which shows the output from the userdata script.

Unlike with the Windows 2012R2 version, you can’t get hold of the actual userdata script on the filesystem, you need to browse to a special path in the metadata service (actually, technically, you can do this with any of the metadata services – OpenStack, Azure, and so on) which is: http://169.254.169.254/latest/user-data/

This will contain userdata between a <powershell> and </powershell> pair of tags. This would need to be copied out of this URL and pasted into a new file on your local machine to determine why issues are occurring. Again, I would recommend using PowerShell ISE from the Start Menu to debug your code.

Windows 2019

This version is the most recent released version of Windows Server, and should be compared to Windows 10 in terms of age.

Windows 2019 AMI Lookup

data "aws_ami" "w2019" {
  most_recent = true

  filter {
    name = "name"
    values = ["Windows_Server-2019-English-Full-Base*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "state"
    values = ["available"]
  }

  owners = ["801119661308"] # AWS
}

Windows 2019 Cloud-Init Troubleshooting

Functionally, the same as Windows 2016, but to recap, the metadata service has moved from Windows 2016 and onwards. Logs are stored in a partially hidden directory tree, so you may need to click in the “Address” bar of the Explorer window and type in part of this path. The path to these files is: C:\ProgramData\Amazon\EC2-Windows\Launch\Log. I say “files” as there are two parts to this file – an “Ec2Launch.log” file which reports on the boot process, and “UserdataExecution.log” which shows the output from the userdata script.

Featured image is “Field Notes – Sweet Tooth” by “The Marmot” on Flickr and is released under a CC-BY license.

“code crunching” by “Ruben Molina” on Flickr

Getting Started with Terraform on AWS

2019-08-092019-08-09 JonTheNiceGuy Leave a comment

I recently wrote a blog post about Getting Started with Terraform on Azure. You might have read it (I know I did!).

Having got a VM stood up in Azure, I wanted to build a VM in AWS, after all, it’s more-or-less the same steps. Note, this is a work-in-progress, and shouldn’t be considered “Final” – this is just something to use as *your* starting block.

What do you need?

You need an AWS account for this. If you’ve not got one, signing up for one is easy, but bear in mind that while there are free resource on AWS (only for the first year!), it’s also quite easy to suddenly enable a load of features that cost you money.

Best practice suggests (or rather, INSISTS) you shouldn’t use your “root” account for AWS. It’s literally just there to let you define the rest of your admin accounts. Turn on MFA (Multi-Factor Authentication) on that account, give it an exceedingly complex password, write that on a sheet of paper, and lock it in a box. You should NEVER use it!

Create your admin account, log in to that account. Turn on MFA on *that* account too. Then, create an “Access Token” for your account. This is in IAM (Identity and Access Management). These are what we’ll use to let Terraform perform actions in AWS, without you needing to actually “log in”.

On my machine, I’ve put the credentials for this in /home/<MYUSER>/.aws/credentials and it looks like this:

[default]
aws_access_key_id = ABC123DEF456
aws_secret_access_key = AaBbCcDd1234EeFf56

This file should be chmod 600 and make sure it’s only your account that can access this file. With this token, Terraform can perform *ANY ACTION* as you, including anything that charges you money, or creating servers that can mine a “cryptocurrency” for someone malicious.

I’m using Windows Subsystem for Linux (WSL). I’m using the Ubuntu 18.04 distribution obtained from the Store. This post won’t explain how to get *that*. Also, you might want to run Terraform on Mac, in Windows or on Linux natively… so, yehr.

Next, we need to actually install Terraform. Excuse the long, unwrapped code block, but it gets what you need quickly (assuming the terraform webpage doesn’t change any time soon!)

mkdir -p ~/bin
cd ~/bin
sudo apt update && sudo apt install unzip
curl -sLO $(curl https://www.terraform.io/downloads.html | grep "linux_amd64.zip" | cut -d\" -f 2) && unzip terraform*.zip && rm terraform*.zip && chmod 755 terraform

Starting coding your infrastructure

Before you can build your first virtual machine on AWS, you need to stand up the supporting infrastructure. These are:

An SSH Keypair (no password logins here!)
A VPC (“Virtual Private Cloud”, roughly the same as a VNet on Azure, or somewhat like a L3 switch in the Physical Realm).
An Internet Gateway (if your VPC isn’t classed as “the default one”)
A Subnet.
A Security Group.

Once we’ve got these, we can build our Virtual Machine on EC2 (“Elastic Cloud Compute”), and associate a “Public IP” to it.

To quote my previous post:

One quirk with Terraform, versus other tools like Ansible, is that when you run one of the terraform commands (like terraform init, terraform plan or terraform apply), it reads the entire content of any file suffixed “tf” in that directory, so if you don’t want a file to be loaded, you need to either move it out of the directory, comment it out, or rename it so it doesn’t end .tf. By convention, you normally have three “standard” files in a terraform directory – main.tf, variables.tf and output.tf, but logically speaking, you could have everything in a single file, or each instruction in it’s own file.
Getting Started with Terraform on Azure – Building the file structure

For the sake of editing and annotating the files for this post, these code blocks are all separated, but on my machine, they’re all currently one big file called “main.tf“.

In that file, I start by telling it that I’m working with the Terraform AWS provider, and that it should target my nearest region.

If you want to risk financial ruin, you can put things like your access tokens in here, but I really wouldn’t chance this!

Next, we create our network infrastructure – VPC, Internet Gateway and Subnet. We also change the routing table.

resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true tags = [ Name = "MainVPC" ] } resource "aws_internet_gateway" "igw" { vpc_id = "${aws_vpc.main.id}" tags = [ Name = "MainInternetGateway" ] } data "aws_route_table" "route" { vpc_id = "${aws_vpc.main.id}" } resource "aws_route" "clouddev_default_out" { route_table_id = "${data.aws_route_table.route.id}" destination_cidr_block = "0.0.0.0/0" gateway_id = "${aws_internet_gateway.igw.id}" } resource "aws_subnet" "main" { vpc_id = "${aws_vpc.main.id}" cidr_block = "10.0.0.0/24" depends_on = ["aws_internet_gateway.igw"] tags = [ Name = "MainSubnet" ] }

I suspect, if I’d created the VPC as “The Default” VPC, then I wouldn’t have needed to amend the routing table, nor added an Internet Gateway. To help us make the routing table change, there’s a “data” block in this section of code. A data block is an instruction to Terraform to go and ask a resource for *something*, in this case, we need AWS to tell Terraform what the routing table is that it created for the VPC. Once we have that we can ask for the routing table change.

AWS doesn’t actually give “proper” names to any of it’s assets. To provide something with a “real” name, you need to tag that thing with the “Name” tag. These can be practically anything, but I’ve given semi-sensible names to everything. You might want to name everything “main” (like I nearly did)!

We’re getting close to being able to create the VM now. First of all, we’ll create the Security Groups. I want to separate out my “Allow Egress Traffic” rule from my “Inbound SSH” rule. This means that I can clearly see what hosts allow inbound SSH access. Like with my Azure post, I’m using a “data provider” to get my public IP address, but in a normal “live” network, you’d specify a collection of valid source address ranges.

data "http" "icanhazip" { url = "http://ipv4.icanhazip.com" } resource "aws_security_group" "my_ssh" { name = "my_ssh" vpc_id = "${aws_vpc.main.id}" ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["${trimspace(data.http.icanhazip.body)}/32"] } tags = [ Name = "my_ssh" ] } resource "aws_security_group" "all_egress" { name = "all_egress" vpc_id = "${aws_vpc.main.id}" egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } tags = [ Name = "all_egress" ] }

Last steps before we create the Virtual Machine. We need to upload our SSH key, and we need to find the “AMI” (AWS Machine ID) of the image we’ll be using. To create the key, in this directory, along side the .tf files, I’ve put my SSH public key (called id_rsa.pub), and we load that key when we create the “my_key” resource. To find the AMI, we need to make another data call, this time asking the AMI index to find the VM with the name containing ubuntu-bionic-18.04 and some other stuff. AMIs are region specific, so the image I’m using in eu-west-2 will not be the same AMI in eu-west-1 or us-east-1 and so on. This filtering means that, as long as the image exists in that region, we can use “the right one”. So let’s take a look at this file.

resource "aws_key_pair" "my_key" { key_name = "my_key" public_key = "${file("id_rsa.pub")}" } data "aws_ami" "ubuntu_18_04" { most_recent = true filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"] } filter { name = "virtualization-type" values = ["hvm"] } owners = ["099720109477"] # Canonical }

So, now we have everything we need to create our VM. Let’s do that!

resource "aws_instance" "main" { ami = "${data.aws_ami.ubuntu_18_04.id}" instance_type = "t2.micro" key_name = "${aws_key_pair.my_key.key_name}" user_data = "${file("CloudDev.sh")}" subnet_id = "${aws_subnet.main.id}" vpc_security_group_ids = [ "${aws_security_group.all_egress.id}", "${aws_security_group.my_ssh.id}" ] tags = [ Name = "MyVM" ] } resource "aws_eip" "main" { instance = "${aws_instance.main.id}" vpc = true tags = [ Name = "MyVM_EIP" ] }

In here, we specify a “user_data” file to upload, in this case, the contents of a file – CloudDev.sh, but you can load anything you want in here. My CloudDev.sh is shown below, so you can see what I’m doing with this file :)

#! /bin/bash sudo apt update 2>&1 | tee -a /home/ubuntu/log sudo apt full-upgrade -y 2>&1 | tee -a /home/ubuntu/log sudo apt install python3-pip git -y 2>&1 | tee -a /home/ubuntu/log sudo -H pip install ansible 2>&1| tee -a /home/ubuntu/log cd /tmp sudo git clone https://github.com/JonTheNiceGuy/clouddev.git clouddev 2>&1 | tee -a /home/ubuntu/log cd clouddev sudo ansible-playbook main.yml 2>&1 | tee -a /home/ubuntu/log touch /home/ubuntu/finished

So, having created all this lot, you need to execute the terraform workload. Initially you do terraform init. This downloads all the provisioners and puts them into the same tree as these .tf files are stored in. It also resets the state of the terraform discovered or created datastore.

Next, you do terraform plan -out tfout. Technically, the tfout part can be any filename, but having something like tfout marks it as clearly part of Terraform. This creates the tfout file with the current state, and whatever needs to change in the Terraform state file on it’s next run. Typically, if you don’t use a tfout file within about 20 minutes, it’s probably worth removing it.

Finally, once you’ve run your plan stage, now you need to apply it. In this case you execute terraform apply tfout. This tfout is the same filename you specified in terraform plan. If you don’t include -out tfout on your plan (or even run a plan!) and tfout in your apply, then you can skip the terraform plan stage entirely.

Once you’re done with your environment, use terraform destroy to shut it all down… and enjoy :)

Featured image is “code crunching” by “Ruben Molina” on Flickr and is released under a CC-ND license.

Getting Started with Terraform on Azure

2019-06-122019-06-13 JonTheNiceGuy Leave a comment

I’m strongly in the “Ansible is my tool, what needs fixing” camp, when it comes to Infrastructure as Code (IaC) but, I know there are other tools out there which are equally as good. I’ve been strongly advised to take a look at Terraform from HashiCorp. I’m most familiar at the moment with Azure, so this is going to be based around resources available on Azure.

Late edit: I want to credit my colleague, Pete, for his help getting started with this. While many of the code samples have been changed from what he provided me with, if it hadn’t been for these code samples in the first place, I’d never have got started!

Late edit 2: This post was initially based on Terraform 0.11, and I was prompted by another colleague, Jon, that the available documentation still follows the 0.11 layout. 0.12 was released in May, and changes how variables are reused in the code. This post now *should* follow the 0.12 conventions, but if you spot something where it doesn’t, check out this post from the Terraform team.

As with most things, there’s a learning curve, and I struggled to find a “simple” getting started guide for Terraform. I’m sure this is a failing on my part, but I thought it wouldn’t hurt to put something out there for others to pick up and see if it helps someone else (and, if that “someone else” is you, please let me know in the comments!)

Pre-requisites

You need an Azure account for this. This part is very far outside my spectrum of influence, but I’m assuming you’ve got one. If not, look at something like Digital Ocean, AWS or VMWare :) For my “controller”, I’m using Windows Subsystem for Linux (WSL), and wrote the following notes about getting my pre-requisites.

# Pre-requsites ``` mkdir -p ~/bin cd ~/bin sudo apt update && sudo apt install unzip ``` # Install AzureCLI [Source](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt) ``` curl -sL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/azure-cli.list > /dev/null sudo apt update && sudo apt install azure-cli ``` # Install Kubectl in WSL [Source](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-binary-with-curl-on-linux) ``` curl -sLO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod 755 kubectl ``` # Install Terraform in WSL [Source](https://techcommunity.microsoft.com/t5/Azure-Developer-Community-Blog/Configuring-Terraform-on-Windows-10-Linux-Sub-System/ba-p/393845) ``` curl -sLO $(curl https://www.terraform.io/downloads.html | grep "linux_amd64.zip" | cut -d\" -f 2) && unzip terraform*.zip && rm terraform*.zip && chmod 755 terraform ``` # Install terraform extension for VSCode https://marketplace.visualstudio.com/items?itemName=mauve.terraform # Define bash as Default VSCode Shell [Source](https://code.visualstudio.com/docs/editor/integrated-terminal) 1. ctrl+shift+p (Command palete) 1. Type: `default shell` and select `Terminal: Select Default Shell` 1. Choose "WSL Bash"

Building the file structure

One quirk with Terraform, versus other tools like Ansible, is that when you run one of the terraform commands (like terraform init, terraform plan or terraform apply), it reads the entire content of any file suffixed “tf” in that directory, so if you don’t want a file to be loaded, you need to either move it out of the directory, comment it out, or rename it so it doesn’t end .tf. By convention, you normally have three “standard” files in a terraform directory – main.tf, variables.tf and output.tf, but logically speaking, you could have everything in a single file, or each instruction in it’s own file. Because this is a relatively simple script, I’ll use this standard layout.

The actions I’ll be performing are the “standard” steps you’d perform in Azure to build a single Infrastructure as a Service (IAAS) server service:

Create your Resource Group (RG)
Create a Virtual Network (VNET)
Create a Subnet
Create a Security Group (SG) and rules
Create a Public IP address (PubIP) with a DNS name associated to that IP.
Create a Network Interface (NIC)
Create a Virtual Machine (VM), supplying a username and password, the size of disks and VM instance, and any post-provisioning instructions (yep, I’m using Ansible for that :) ).

I’m using Visual Studio Code, but almost any IDE will have integrations for Terraform. The main thing I’m using it for is auto-completion of resource, data and output types, also the fact that control+clicking resource types opens your browser to the documentation page on terraform.io.

So, creating my main.tf, I start by telling it that I’m working with the Terraform AzureRM Provider (the bit of code that can talk Azure API).

This simple statement is enough to get Terraform to load the AzureRM, but it still doesn’t tell Terraform how to get access to the Azure account. Use az login from a WSL shell session to authenticate.

Next, we create our basic resource, vnet and subnet resources.

resource "azurerm_resource_group" "rg" { name = var.resource_group_name location = var.location } resource "azurerm_virtual_network" "vnet" { name = var.vnet_name location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name address_space = ["10.0.0.0/16"] dns_servers = ["8.8.8.8", "8.8.4.4"] } resource "azurerm_subnet" "subnet" { name = var.subnet_name resource_group_name = azurerm_resource_group.rg.name virtual_network_name = azurerm_virtual_network.vnet.name address_prefix = "10.0.1.0/24" }

But wait, I hear you cry, what are those var.something bits in there? I mentioned before that in the “standard” set of files is a “variables.tf” file. In here, you specify values for later consumption. I have recorded variables for the resource group name and location, as well as the VNet name and subnet name. Let’s add those into variables.tf.

variable resource_group_name { default = "MFIOT201906" } variable vnet_name { default = "MFIOT201906_vnet" } variable subnet_name { default = "MFIOT201906_subnet" } variable location { default = "UK South" }

When you’ve specified a resource, you can capture any of the results from that resource to use later – either in the main.tf or in the output.tf files. By creating the resource group (called “rg” here, but you can call it anything from “demo” to “myfirstresourcegroup”), we can consume the name or location with azurerm_resource_group.rg.name and azurerm_resource_group.rg.location, and so on. In the above code, we use the VNet name in the subnet, and so on.

After the subnet is created, we can start adding the VM specific parts – a security group (with rules), a public IP (with DNS name) and a network interface. I’ll create the VM itself later. So, let’s do this.

resource "azurerm_network_security_group" "iaasnsg" { name = "iaas-nsg" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name } resource "azurerm_network_security_rule" "iaasnsgr" { name = "iaas-nsg-100" priority = 100 direction = "Inbound" access = "Allow" protocol = "Tcp" source_port_range = "*" destination_port_range = "22" source_address_prefix = "${trimspace(data.http.icanhazip.body)}/32" destination_address_prefix = "*" resource_group_name = azurerm_resource_group.rg.name network_security_group_name = azurerm_network_security_group.iaasnsg.name } resource "azurerm_public_ip" "iaaspubip" { name = "iaas-pubip" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name allocation_method = "Dynamic" domain_name_label = var.dns_prefix } resource "azurerm_network_interface" "iaasnic" { name = "iaas-nic" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name network_security_group_id = azurerm_network_security_group.iaasnsg.id ip_configuration { name = "iaas-nic-ip" subnet_id = azurerm_subnet.subnet.id private_ip_address_allocation = "Dynamic" public_ip_address_id = azurerm_public_ip.iaaspubip.id } }

BUT WAIT, what’s that ${trimspace(data.http.icanhazip.body)}/32 bit there?? Any resources we want to load from the terraform state, but that we’ve not directly defined ourselves needs to come from somewhere. These items are classed as “data” – that is, we want to know what their values are, but we aren’t *changing* the service to get it. You can also use this to import other resource items, perhaps a virtual network that is created by another team, or perhaps your account doesn’t have the rights to create a resource group. I’ll include a commented out data block in the overall main.tf file for review that specifies a VNet if you want to see how that works.

In this case, I want to put the public IP address I’m coming from into the NSG Rule, so I can get access to the VM, without opening it up to *everyone*. I’m not that sure that my IP address won’t change between one run and the next, so I’m using the icanhazip.com service to determine my IP address. But I’ve not defined how to get that resource yet. Let’s add it to the main.tf for now.

So, we’re now ready to create our virtual machine. It’s quite a long block, but I’ll pull certain elements apart once I’ve pasted this block in.

resource "azurerm_virtual_machine" "main" { name = "iaas-vm" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name network_interface_ids = [azurerm_network_interface.iaasnic.id] vm_size = "Standard_DS1_v2" delete_os_disk_on_termination = true delete_data_disks_on_termination = true storage_image_reference { publisher = "Canonical" offer = "UbuntuServer" sku = "18.04-LTS" version = "latest" } storage_os_disk { name = "iaas-os-disk" caching = "ReadWrite" create_option = "FromImage" managed_disk_type = "Standard_LRS" } os_profile { computer_name = "iaas" admin_username = var.ssh_user admin_password = var.ssh_password } os_profile_linux_config { disable_password_authentication = false } provisioner "remote-exec" { inline = ["mkdir /tmp/ansible"] connection { type = "ssh" host = azurerm_public_ip.iaaspubip.fqdn user = var.ssh_user password = var.ssh_password } } provisioner "file" { source = "ansible/" destination = "/tmp/ansible" connection { type = "ssh" host = azurerm_public_ip.iaaspubip.fqdn user = var.ssh_user password = var.ssh_password } } provisioner "remote-exec" { inline = [ "sudo apt update > /tmp/apt_update || cat /tmp/apt_update", "sudo apt install -y python3-pip > /tmp/apt_install_python3_pip || cat /tmp/apt_install_python3_pip", "sudo -H pip3 install ansible > /tmp/pip_install_ansible || cat /tmp/pip_install_ansible", "ansible-playbook /tmp/ansible/main.yml" ] connection { type = "ssh" host = azurerm_public_ip.iaaspubip.fqdn user = var.ssh_user password = var.ssh_password } } }

So, this is broken into four main pieces.

Virtual Machine Details. This part is relatively sensible. Name RG, location, NIC, Size and what happens to the disks when the machine powers on. OK.

name                             = "iaas-vm"
location                         = azurerm_resource_group.rg.location
resource_group_name              = azurerm_resource_group.rg.name
network_interface_ids            = [azurerm_network_interface.iaasnic.id]
vm_size                          = "Standard_DS1_v2"
delete_os_disk_on_termination    = true
delete_data_disks_on_termination = true

Disk details.

storage_image_reference {
  publisher = "Canonical"
  offer     = "UbuntuServer"
  sku       = "18.04-LTS"
  version   = "latest"
}
storage_os_disk {
  name              = "iaas-os-disk"
  caching           = "ReadWrite"
  create_option     = "FromImage"
  managed_disk_type = "Standard_LRS"
}

OS basics: VM Hostname, username of the first user, and it’s password. Note, if you want to use an SSH key, this must be stored for Terraform to use without passphrase. If you mention an SSH key here, as well as a password, this can cause all sorts of connection issues, so pick one or the other.

os_profile {
  computer_name  = "iaas"
  admin_username = var.ssh_user
  admin_password = var.ssh_password
}
os_profile_linux_config {
  disable_password_authentication = false
}

And lastly, provisioning. I want to use Ansible for my provisioning. In this example, I have a basic playbook stored locally on my Terraform host, which I transfer to the VM, install Ansible via pip, and then execute ansible-playbook against the file I uploaded. This could just as easily be a git repo to clone or a shell script to copy in, but this is a “simple” example.

provisioner "remote-exec" {
  inline = ["mkdir /tmp/ansible"]

  connection {
    type     = "ssh"
    host     = azurerm_public_ip.iaaspubip.fqdn
    user     = var.ssh_user
    password = var.ssh_password
  }
}

provisioner "file" {
  source = "ansible/"
  destination = "/tmp/ansible"

  connection {
    type     = "ssh"
    host     = azurerm_public_ip.iaaspubip.fqdn
    user     = var.ssh_user
    password = var.ssh_password
  }
}

provisioner "remote-exec" {
  inline = [
    "sudo apt update > /tmp/apt_update || cat /tmp/apt_update",
    "sudo apt install -y python3-pip > /tmp/apt_install_python3_pip || cat /tmp/apt_install_python3_pip",
    "sudo -H pip3 install ansible > /tmp/pip_install_ansible || cat /tmp/pip_install_ansible",
    "ansible-playbook /tmp/ansible/main.yml"
  ]

  connection {
    type     = "ssh"
    host     = azurerm_public_ip.iaaspubip.fqdn
    user     = var.ssh_user
    password = var.ssh_password
  }
}

This part of code is done in three parts – create upload path, copy the files in, and then execute it. If you don’t create the upload path, it’ll upload just the first file it comes to into the path specified.

Each remote-exec and file provisioner statement must include the hostname, username and either the password, or SSH private key. In this example, I provide just the password.

When I ran this, with a handful of changes to the variable files, I got this result:

$ terraform init Initializing the backend... Initializing provider plugins... 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.azurerm: version = "~> 1.30" * provider.http: version = "~> 1.1" 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.

$ terraform plan -out tfout Refreshing Terraform state in-memory prior to plan... [314/486] The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. data.http.icanhazip: Refreshing state... ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # azurerm_network_interface.iaasnic will be created + resource "azurerm_network_interface" "iaasnic" { + applied_dns_servers = (known after apply) + dns_servers = (known after apply) + enable_accelerated_networking = false + enable_ip_forwarding = false + id = (known after apply) + internal_dns_name_label = (known after apply) + internal_fqdn = (known after apply) + location = "uksouth" + mac_address = (known after apply) + name = "iaas-nic" + network_security_group_id = (known after apply) + private_ip_address = (known after apply) + private_ip_addresses = (known after apply) + resource_group_name = "20190611_JS_RG" + tags = (known after apply) + virtual_machine_id = (known after apply) + ip_configuration { + application_gateway_backend_address_pools_ids = (known after apply) + application_security_group_ids = (known after apply) + load_balancer_backend_address_pools_ids = (known after apply) + load_balancer_inbound_nat_rules_ids = (known after apply) + name = "iaas-nic-ip" + primary = (known after apply) + private_ip_address_allocation = "dynamic" + private_ip_address_version = "IPv4" + public_ip_address_id = (known after apply) + subnet_id = (known after apply) } } # azurerm_network_security_group.iaasnsg will be created + resource "azurerm_network_security_group" "iaasnsg" { + id = (known after apply) + location = "uksouth" + name = "iaas-nsg" + resource_group_name = "20190611_JS_RG" + security_rule = (known after apply) + tags = (known after apply) } # azurerm_network_security_rule.iaasnsgr will be created + resource "azurerm_network_security_rule" "iaasnsgr" { + access = "Allow" + destination_address_prefix = "*" + destination_port_range = "22" + direction = "Inbound" + id = (known after apply) + name = "iaas-nsg-100" [250/486] + network_security_group_name = "iaas-nsg" + priority = 100 + protocol = "Tcp" + resource_group_name = "20190611_JS_RG" + source_address_prefix = "89.101.76.85/32" + source_port_range = "*" } # azurerm_public_ip.iaaspubip will be created + resource "azurerm_public_ip" "iaaspubip" { + allocation_method = "Dynamic" + domain_name_label = "js-20190611-iaas-demo" + fqdn = (known after apply) + id = (known after apply) + idle_timeout_in_minutes = 4 + ip_address = (known after apply) + ip_version = "IPv4" + location = "uksouth" + name = "iaas-pubip" + public_ip_address_allocation = (known after apply) + resource_group_name = "20190611_JS_RG" + sku = "Basic" + tags = (known after apply) } # azurerm_resource_group.rg will be created + resource "azurerm_resource_group" "rg" { + id = (known after apply) + location = "uksouth" + name = "20190611_JS_RG" + tags = (known after apply) } # azurerm_subnet.subnet will be created + resource "azurerm_subnet" "subnet" { + address_prefix = "10.0.1.0/24" + id = (known after apply) + ip_configurations = (known after apply) + name = "20190611_JS_subnet" + resource_group_name = "20190611_JS_RG" + virtual_network_name = "20190611_JS_vnet" } # azurerm_virtual_machine.main will be created + resource "azurerm_virtual_machine" "main" { + availability_set_id = (known after apply) + delete_data_disks_on_termination = true + delete_os_disk_on_termination = true + id = (known after apply) + license_type = (known after apply) + location = "uksouth" + name = "iaas-vm" + network_interface_ids = (known after apply) + resource_group_name = "20190611_JS_RG" + tags = (known after apply) + vm_size = "Standard_DS1_v2" + identity { + identity_ids = (known after apply) + principal_id = (known after apply) + type = (known after apply) } + os_profile { + admin_password = (sensitive value) + admin_username = "tf_admin" + computer_name = "iaas" + custom_data = (known after apply) } + os_profile_linux_config { + disable_password_authentication = false } + storage_data_disk { + caching = (known after apply) + create_option = (known after apply) + disk_size_gb = (known after apply) + lun = (known after apply) + managed_disk_id = (known after apply) + managed_disk_type = (known after apply) + name = (known after apply) + vhd_uri = (known after apply) + write_accelerator_enabled = (known after apply) } + storage_image_reference { + offer = "UbuntuServer" + publisher = "Canonical" + sku = "18.04-LTS" + version = "latest" } + storage_os_disk { + caching = "ReadWrite" + create_option = "FromImage" + disk_size_gb = (known after apply) + managed_disk_id = (known after apply) + managed_disk_type = "Standard_LRS" + name = "iaas-os-disk" + os_type = (known after apply) + write_accelerator_enabled = false } } # azurerm_virtual_network.vnet will be created [144/486] + resource "azurerm_virtual_network" "vnet" { + address_space = [ + "10.0.0.0/16", ] + dns_servers = [ + "8.8.8.8", + "8.8.4.4", ] + id = (known after apply) + location = "uksouth" + name = "20190611_JS_vnet" + resource_group_name = "20190611_JS_RG" + tags = (known after apply) + subnet { + address_prefix = (known after apply) + id = (known after apply) + name = (known after apply) + security_group = (known after apply) } } Plan: 8 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ This plan was saved to: tfout To perform exactly these actions, run the following command to apply: terraform apply "tfout"

terraform apply tfout azurerm_resource_group.rg: Creating... azurerm_resource_group.rg: Creation complete after 1s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906] azurerm_network_security_group.iaasnsg: Creating... azurerm_virtual_network.vnet: Creating... azurerm_public_ip.iaaspubip: Creating... azurerm_public_ip.iaaspubip: Creation complete after 4s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/publicIPAddresses/iaas-pubip] azurerm_network_security_group.iaasnsg: Still creating... [11s elapsed] azurerm_virtual_network.vnet: Still creating... [11s elapsed] azurerm_virtual_network.vnet: Creation complete after 11s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/virtualNetworks/MFIOT201906_vnet] azurerm_network_security_group.iaasnsg: Creation complete after 12s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/networkSecurityGroups/iaas-nsg] azurerm_network_security_rule.iaasnsgr: Creating... azurerm_subnet.subnet: Creating... azurerm_network_security_rule.iaasnsgr: Creation complete after 1s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/networkSecurityGroups/iaas-nsg/securityRules/iaas-nsg-100] azurerm_subnet.subnet: Still creating... [10s elapsed] azurerm_subnet.subnet: Creation complete after 10s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/virtualNetworks/MFIOT201906_vnet/subnets/MFIOT201906_subnet] azurerm_network_interface.iaasnic: Creating... azurerm_network_interface.iaasnic: Creation complete after 0s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Network/networkInterfaces/iaas-nic] azurerm_virtual_machine.main: Creating... azurerm_virtual_machine.main: Still creating... [10s elapsed] azurerm_virtual_machine.main: Still creating... [20s elapsed] azurerm_virtual_machine.main: Still creating... [30s elapsed] azurerm_virtual_machine.main: Provisioning with 'remote-exec'... azurerm_virtual_machine.main (remote-exec): Connecting to remote host via SSH... azurerm_virtual_machine.main (remote-exec): Host: myfirstiaasonterraform.uksouth.cloudapp.azure.com azurerm_virtual_machine.main (remote-exec): User: tf_admin azurerm_virtual_machine.main (remote-exec): Password: true azurerm_virtual_machine.main (remote-exec): Private key: false azurerm_virtual_machine.main (remote-exec): Certificate: false azurerm_virtual_machine.main (remote-exec): SSH Agent: true azurerm_virtual_machine.main (remote-exec): Checking Host Key: false azurerm_virtual_machine.main (remote-exec): Connecting to remote host via SSH... azurerm_virtual_machine.main (remote-exec): Host: myfirstiaasonterraform.uksouth.cloudapp.azure.com azurerm_virtual_machine.main (remote-exec): User: tf_admin azurerm_virtual_machine.main (remote-exec): Password: true azurerm_virtual_machine.main (remote-exec): Private key: false azurerm_virtual_machine.main (remote-exec): Certificate: false azurerm_virtual_machine.main (remote-exec): SSH Agent: true azurerm_virtual_machine.main (remote-exec): Checking Host Key: false azurerm_virtual_machine.main (remote-exec): Connecting to remote host via SSH... azurerm_virtual_machine.main (remote-exec): Host: myfirstiaasonterraform.uksouth.cloudapp.azure.com azurerm_virtual_machine.main (remote-exec): User: tf_admin azurerm_virtual_machine.main (remote-exec): Password: true azurerm_virtual_machine.main (remote-exec): Private key: false azurerm_virtual_machine.main (remote-exec): Certificate: false azurerm_virtual_machine.main (remote-exec): SSH Agent: true azurerm_virtual_machine.main (remote-exec): Checking Host Key: false azurerm_virtual_machine.main: Still creating... [40s elapsed] azurerm_virtual_machine.main (remote-exec): Connecting to remote host via SSH... azurerm_virtual_machine.main (remote-exec): Host: myfirstiaasonterraform.uksouth.cloudapp.azure.com azurerm_virtual_machine.main (remote-exec): User: tf_admin azurerm_virtual_machine.main (remote-exec): Password: true azurerm_virtual_machine.main (remote-exec): Private key: false azurerm_virtual_machine.main (remote-exec): Certificate: false azurerm_virtual_machine.main (remote-exec): SSH Agent: true azurerm_virtual_machine.main (remote-exec): Checking Host Key: false azurerm_virtual_machine.main (remote-exec): Connected! azurerm_virtual_machine.main: Provisioning with 'file'... azurerm_virtual_machine.main: Provisioning with 'remote-exec'... azurerm_virtual_machine.main (remote-exec): Connecting to remote host via SSH... azurerm_virtual_machine.main (remote-exec): Host: myfirstiaasonterraform.uksouth.cloudapp.azure.com azurerm_virtual_machine.main (remote-exec): User: tf_admin azurerm_virtual_machine.main (remote-exec): Password: true azurerm_virtual_machine.main (remote-exec): Private key: false azurerm_virtual_machine.main (remote-exec): Certificate: false azurerm_virtual_machine.main (remote-exec): SSH Agent: true azurerm_virtual_machine.main (remote-exec): Checking Host Key: false azurerm_virtual_machine.main (remote-exec): Connected! azurerm_virtual_machine.main: Still creating... [50s elapsed] azurerm_virtual_machine.main (remote-exec): WARNING: apt does not have a stable CLI interface. Use with caution in scripts. azurerm_virtual_machine.main (remote-exec): WARNING: apt does not have a stable CLI interface. Use with caution in scripts. azurerm_virtual_machine.main: Still creating... [1m0s elapsed] azurerm_virtual_machine.main (remote-exec): Extracting templates from packages: 47% azurerm_virtual_machine.main (remote-exec): Extracting templates from packages: 95% azurerm_virtual_machine.main (remote-exec): Extracting templates from packages: 100% azurerm_virtual_machine.main: Still creating... [1m10s elapsed] azurerm_virtual_machine.main: Still creating... [1m20s elapsed] azurerm_virtual_machine.main: Still creating... [1m30s elapsed] azurerm_virtual_machine.main: Still creating... [1m40s elapsed] azurerm_virtual_machine.main: Still creating... [1m50s elapsed] azurerm_virtual_machine.main: Still creating... [2m0s elapsed] azurerm_virtual_machine.main: Still creating... [2m10s elapsed] azurerm_virtual_machine.main: Still creating... [2m20s elapsed] azurerm_virtual_machine.main: Still creating... [2m30s elapsed] azurerm_virtual_machine.main: Still creating... [2m40s elapsed] azurerm_virtual_machine.main (remote-exec): [WARNING]: No inventory was parsed, only implicit localhost is available azurerm_virtual_machine.main (remote-exec): azurerm_virtual_machine.main (remote-exec): [WARNING]: provided hosts list is empty, only localhost is available. Note azurerm_virtual_machine.main (remote-exec): that the implicit localhost does not match 'all' azurerm_virtual_machine.main (remote-exec): azurerm_virtual_machine.main (remote-exec): PLAY [localhost] *************************************************************** azurerm_virtual_machine.main (remote-exec): TASK [debug] ******************************************************************* azurerm_virtual_machine.main (remote-exec): ok: [localhost] => { azurerm_virtual_machine.main (remote-exec): "msg": "Hello world!" azurerm_virtual_machine.main (remote-exec): } azurerm_virtual_machine.main (remote-exec): PLAY RECAP ********************************************************************* azurerm_virtual_machine.main (remote-exec): localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 azurerm_virtual_machine.main: Creation complete after 2m50s [id=/subscriptions/decafbad-1234-abcd-5678-abcdef123456/resourceGroups/MFIOT201906/providers/Microsoft.Compute/virtualMachines/iaas-vm] Apply complete! Resources: 8 added, 0 changed, 0 destroyed. The state of your infrastructure has been saved to the path below. This state is required to modify and destroy your infrastructure, so keep it safe. To inspect the complete state use the `terraform show` command. State path: terraform.tfstate Outputs: host = myfirstiaasonterraform.uksouth.cloudapp.azure.com

Once you’re done with your environment, use terraform destroy to shut it all down… and enjoy :)

The full source is available in the associated Gist. Pull requests and constructive criticism are very welcome!

Featured image is “Seca” by “Olearys” on Flickr and is released under a CC-BY license.

Linux Distributions

Amazon Linux 2 or Amzn2

Amzn2 AMI Lookup

Amzn2 User Account

Amzn2 AWS Interface Configuration

Amzn2 user-data / Cloud-Init Troubleshooting

CentOS 7

CentOS AMI Lookup

CentOS User Account

CentOS AWS Interface Configuration

CentOS Cloud-Init Troubleshooting

Red Hat Enterprise Linux (RHEL) 7 and 8

RHEL7 AMI Lookup

RHEL8 AMI Lookup

RHEL User Accounts

RHEL AWS Interface Configuration

RHEL Cloud-Init Troubleshooting

Ubuntu 18.04

Ubuntu 18.04 AMI Lookup

Ubuntu 18.04 User Accounts

Ubuntu 18.04 AWS Interface Configuration

Ubuntu 18.04 Cloud-Init Troubleshooting

Windows

Windows 2012R2

Windows 2012R2 AMI Lookup

Windows 2012R2 Cloud-Init Troubleshooting

Windows 2016

Windows 2016 AMI Lookup

Windows 2016 Cloud-Init Troubleshooting

Windows 2019

Windows 2019 AMI Lookup

Windows 2019 Cloud-Init Troubleshooting

Share this:

What do you need?

Starting coding your infrastructure

Share this:

Pre-requisites

Building the file structure

Share this: