Terraform on David Hamann

Using the Hetzner Cloud Terraform Provider

Wed, 21 Jan 2026 00:00:00 +0000

I’m currently in the process of setting up several cloud servers for a new project. The whole infrastructure will run on Hetzner Cloud and be codified.

Since it’s the first time I’m using the Terraform provider for Hetzner Cloud, I want to write down some of the notes I took.

I’ll focus on creating a small, simplified, self-contained example to create a server, set up a firewall, and get a public IP assigned (no private network). If you want to manage multiple stacks and/or multiple projects, it generally makes sense to create your own modules and shared configurations. This is, however, out of scope for this post and not really any different when using Hetzner Cloud vs. other providers.

If you like to read a general overview of Terraform/Infrastructure as Code first, I’ve written a tutorial in 2020 which should still be mostly up-to-date.

Prerequisites

To tell Terraform we are going to work with the Hetzner cloud, we need to specify the relevant provider including a version number, and a token to use for interacting with the API:

terraform {
 required_providers {
 hcloud = {
 source = "hetznercloud/hcloud"
 version = "~> 1.45"
 }
 }
}

provider "hcloud" {
 token = var.hcloud_token
}

If you’ve used Terraform before this looks just like other provider configurations. We say we want to use the hcloud provider found at hetznercloud/hcloud in the Terraform registry. We set the version compatibility to ~> 1.45, i.e. allowing any higher version less than 2.0.

The token can be acquired through the Hetzner Cloud console (Your project -> Security -> API Tokens) and then passed in via a variable:

While not a requirement, a very helpful tool when setting up your Hetzner infrastructure is the hcloud CLI application. I use it mostly to look up things – for example to find the right image identifier to use for a new server:

$ hcloud image list | grep ubuntu
67794396 system ubuntu-22.04 Ubuntu 22.04 x86 - 5 GB 2022-04-21 15:32:38 CEST -
103908130 system ubuntu-22.04 Ubuntu 22.04 arm - 5 GB 2023-03-20 11:10:04 CET -
161547269 system ubuntu-24.04 Ubuntu 24.04 x86 - 5 GB 2024-04-25 15:26:27 CEST -
161547270 system ubuntu-24.04 Ubuntu 24.04 arm - 5 GB 2024-04-25 15:26:51 CEST -

Or to find the right server type:

$ hcloud server-type list
ID NAME CORES CPU TYPE ARCHITECTURE MEMORY DISK STORAGE TYPE
22 cpx11 2 shared x86 2.0 GB 40 GB local
23 cpx21 3 shared x86 4.0 GB 80 GB local
24 cpx31 4 shared x86 8.0 GB 160 GB local
25 cpx41 8 shared x86 16.0 GB 240 GB local
26 cpx51 16 shared x86 32.0 GB 360 GB local
45 cax11 2 shared arm 4.0 GB 40 GB local
93 cax21 4 shared arm 8.0 GB 80 GB local
94 cax31 8 shared arm 16.0 GB 160 GB local
95 cax41 16 shared arm 32.0 GB 320 GB local
96 ccx13 2 dedicated x86 8.0 GB 80 GB local
97 ccx23 4 dedicated x86 16.0 GB 160 GB local
98 ccx33 8 dedicated x86 32.0 GB 240 GB local
99 ccx43 16 dedicated x86 64.0 GB 360 GB local
100 ccx53 32 dedicated x86 128.0 GB 600 GB local
101 ccx63 48 dedicated x86 192.0 GB 960 GB local
...

Initializing

Let’s create a new directory, save the provider config from above in a file called main.tf and then initialize it:

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding hetznercloud/hcloud versions matching "~> 1.45"...
- Installing hetznercloud/hcloud v1.59.0...
- Installed hetznercloud/hcloud v1.59.0 (signed by a HashiCorp partner, key ID 5219EACB3A77198B)
Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://developer.hashicorp.com/terraform/cli/plugins/signing
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

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.

As you see, the version 1.45 we specified is already superseded, and we downloaded version 1.59.0 instead.

If you want to follow along, your directory should now look like this (or similar, depending on your architecture):

.
├── .terraform
│   └── providers
│   └── registry.terraform.io
│   └── hetznercloud
│   └── hcloud
│   └── 1.59.0
│   └── darwin_arm64
│   ├── CHANGELOG.md
│   ├── LICENSE
│   ├── README.md
│   └── terraform-provider-hcloud_v1.59.0
├── .terraform.lock.hcl
└── main.tf

If you prefer to build the provider yourself, please see these instructions on GitHub.

Setting up variables and outputs

To make it easier to experiment, let’s create a variables.tf and define a few variables for attributes we might want to change along the way:

variable "hcloud_token" {
 sensitive = true
 type = string
}

variable "project_name" {
 type = string
 description = "Identifier for naming resources"
}

variable "server_type" {
 type = string
 default = "cpx22" # check "hcloud server-type list" for a list of options
}

variable "server_image" {
 type = string
 default = "ubuntu-24.04" # check "hcloud image list" for a list of options
}

variable "location" {
 type = string
 default = "fsn1" # the data center at which you want to create the resources.
 # check "hcloud location list" for a list of options
}

variable "admin_ips" {
 type = list(string)
 description = "CIDR IP ranges for administrative access"
}

variable "ssh_keys" {
 type = list(string)
 description = "SSH key names or IDs"
}

Most of the variables should be self-explanatory, but I’ve also added a few comments and descriptions to explain the meaning.

To later find out the ID and IP of the server we provision, let’s also create an outputs.tf file with the following content:

output "server_id" {
 value = hcloud_server.example_server.id
}

output "server_ipv4" {
 value = hcloud_server.example_server.ipv4_address
}

I’ll explain where the hcloud_server.example_server comes from in the next step.

Setting up server, firewall and IP address

Now we can finally start creating our resources. Again, the plan is to simply create a server, a few firewall rules and an IP address and then attach the resources accordingly.

IP address

Let’s start with the IP address by creating a new file network.tf:

resource "hcloud_primary_ip" "example_ipv4" {
 name = "${var.project_name}-ipv4"
 type = "ipv4"
 location = var.location
 assignee_type = "server"
 auto_delete = false
}

To assign an IP address to servers on Hetzner Cloud you will need to create a hcloud_primary_ip resource.

In the above example, we give it a name, a type (one of ipv4 or ipv6), a data center location and a type saying what kind of resource we want to assign this IP to (server).

We set auto_delete to false such that the IP is not being deleted when the server is deleted (if you run terraform destroy later this will still delete the IP as expected).

You could also set assignee_id, but since we want to be able to create the IP before the server is created, I’ll just set the assignee_type.

The name (just a resource identifier) and location (data center) make use of the variables we specified before.

Firewall

On to the firewall configuration.

Since this example doesn’t really have a use-case for the server in mind, we just set a few common inbound rules.

Let’s create firewall.tf and start setting up an hcloud_firewall resource:

resource "hcloud_firewall" "example_fw" {
 name = "${var.project_name}-firewall"

 # ssh
 rule {
 direction = "in"
 protocol = "tcp"
 port = "22"
 source_ips = var.admin_ips
 }

 # icmp
 rule {
 direction = "in"
 protocol = "icmp"
 source_ips = var.admin_ips
 }

 # http
 rule {
 direction = "in"
 protocol = "tcp"
 port = "80"
 source_ips = ["0.0.0.0/0"]
 }

 # https
 rule {
 direction = "in"
 protocol = "tcp"
 port = "443"
 source_ips = ["0.0.0.0/0"]
 }
}

We give the firewall a name and use the rule argument to create rules.

Each rule must have a direction, protocol, source_ips, and a port (if it applies, i.e. for tcp and udp).

For SSH and ICMP I limit the source IPs to the ranges we can configure via the admin_ips variable. The HTTP ports I leave open for all.

Server

Now we can finally create our server resource:

resource "hcloud_server" "example_server" {
 name = "${var.project_name}-server"
 server_type = var.server_type
 image = var.server_image
 location = var.location

 ssh_keys = var.ssh_keys

 firewall_ids = [
 hcloud_firewall.example_fw.id
 ]

 public_net {
 ipv4_enabled = true
 ipv4 = hcloud_primary_ip.example_ipv4.id
 ipv6_enabled = false
 }

 user_data = templatefile("${path.module}/cloud-init.yml", {
 hostname = "${var.project_name}-example"
 })

 labels = {
 project = var.project_name
 role = "example-server"
 }
}

Most of the arguments should be clear, but let’s quickly go through them:

name - Obvious
server_type, image, location - These define the type of server, OS and data center, and are filled with the variable values set earlier
ssh_keys - Here, you can set names of SSH keys that you have set up in the Hetzner Cloud Console. They will be written into the authorized_keys file of the root user during initialization. Since we also do some cloud-init setup in the next step, this wouldn’t be strictly necessary, but it’s nice to have a backup access method in case the cloud-init fails. We are setting this argument from a variable defined earlier.
firewall_ids – Here, we attach the firewall resource created earlier. Since it’s a list, you can also combine firewalls (I do that for example, when I have a shared module with a few default rules and then a customer or project module with further more specific rules).
public_net – In this block, we can attach the IP address we created earlier. If you don’t set this, Hetzner will automatically create a new primary IPv4 (and IPv6, if enabled) for you.
user_data – This is where we can set cloud-init data for initialization of the VM. We load the initialization steps from a file cloud-init.yml. More on this later.
labels – Just a bunch of labels you can attach to the server

cloud-init

To initialize the server with a few commands, we can use cloud-init (just like on other platforms).

I usually do a bare minimum in the cloud config and then do the actual set up later on with ansible.

Here’s a sample config for completeness. However, it’s not specifically related to Hetzner Cloud:

#cloud-config

hostname: ${hostname}

package_update: true
package_upgrade: true

packages:
 - ufw
 - python3

users:
 - name: ansible
 groups: users, admin
 lock_passwd: true
 sudo: ALL=(ALL) NOPASSWD:ALL
 shell: /bin/bash
 ssh_authorized_keys:
 - ssh-ed25519 AAAA...

write_files:
 - path: /etc/ssh/sshd_config.d/ssh.conf
 content: |
 PermitRootLogin no
 PasswordAuthentication no
 Port 22
 MaxAuthTries 2
 AuthorizedKeysFile .ssh/authorized_keys
 AllowUsers ansible

runcmd:
 - ufw allow 22/tcp comment 'SSH'
 - ufw allow 80/tcp comment 'HTTP'
 - ufw allow 443/tcp comment 'HTTPS'
 - ufw --force enable
 - systemctl restart sshd

Creating and destroying the infrastructure

If you followed along, you should now have a directory with the following files:

.
├── cloud-init.yml
├── firewall.tf
├── main.tf
├── network.tf
├── outputs.tf
├── server.tf
└── variables.tf

We can now plan, apply and destroy the infrastructure as usual. Make sure to set the values for the variables (via the prompt, environment variables and/or a .tfvars file).

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

Outputs:

server_id = "11223344"
server_ipv4 = "1.2.3.4"

Further information

For further information check out the full documentation of the Hetzner Cloud provider on the Terraform Registry site.

Terraform: Change EC2 user_data without recreating instance

Thu, 09 Jun 2022 00:00:00 +0000

When you have set up your infrastructure with Terraform and then do any change to the user_data of a EC2 instance, Terraform will detect the change and generally do a force-replacement of the instance. In the planning stage this could look something like this:

 # aws_instance.web_backend must be replaced
-/+ resource "aws_instance" "web_backend" {
 [...]
 ~ user_data = "1c4e236bd5dec74fecc99d3a3d57679b9b12a927" -> "f8d9add08d4ead74d44af35452c6070dbfcb1576" # forces replacement
 + user_data_base64 = (known after apply)
 [...]

So what can you do when you want to make changes to user_data but don’t want to destroy your instance and create a new one?

For this case there is a lifecycle meta-argument in which you can customize certain resource behaviours.

The argument we are looking for is ignore_changes. You can declare this to tell Terraform to ignore changes to certain attributes of a resource that occur after its creation.

The user_data of a EC2 instance is just an example here – you may use it for any other data as well. But sticking with this example, let’s see how our modified EC2 instance could look like:

resource "aws_instance" "web_backend" {
 [...]
 user_data = local.ec2_user_data

 # don't force-recreate instance if only user data changes
 lifecycle {
 ignore_changes = [user_data]
 }
}

Making changes to user_data and then running terraform plan again, you will see that Terraform won’t pick up the change and thus won’t tell you that the resource must be replaced.

Getting started with Terraform and Infrastructure as Code

Wed, 20 May 2020 00:00:00 +0000

I recently worked with Terraform to codify IT infrastructure, i.e. server deployments, network configurations and other resources. Based on my working notes, I want to give an introduction on how to write infrastructure resource definitions and execute them using Terraform.

I’ll be using AWS as a cloud provider in my examples, but many more providers are available. In fact, one of the advantages of using a platform agnostic tool is that you can manage all your infrastructure in one place – not individually for every provider or on-premise platform you use.

As this is supposed to be a relatively high-level overview, we’re only going to create an EC2 instance and don’t involve other services or additional configuration management tools yet.

Prerequisites

If you want to follow along, you’ll need…

an AWS account
an IAM user you’d like to use
a default VPC for the AWS region you choose to use
the terraform cli tool installed (using a package manager, a pre-compiled binary, or by building it yourself)

The IAM user needs programatic access and should have permissions to create EC2 resources under your account. If you already have access credentials set up on your machine, I suggest adding the access key and secret for the new user as a separate profile in your credentials file (~/.aws/credentials).

It could look something like this:

[my-terraform-profile]
aws_access_key_id = ABC
aws_secret_access_key = DEF

For later reference, I’ve published a gist of the terraform configuration we are going to create in the next steps.

Why

Before we start setting up our initial configuration, let’s think about why would we would want to manage our infrastructure in code in the first place.

A couple of reasons:

not having to manually configure each VM deployment and thus reducing manual configuration errors (this is even more relevant when you’re dealing with lots of different VMs in multiple networks, many different security groups, etc. – not cool to do by hand)
making it easy to repeatedly and programatically set things up with a (hopefully) good baseline configuration
having a clearly defined and visible configuration and state of your resources
treating your infrastructure like your other code and benefiting from all the tools you’re already using, e.g. version control

In addition, codifying your infrastructure means you can (re)create and tear down resources very easily and basically not just start an idle resource when you need it, but actually only build it when you need it – which is exactly what we’re going to do in the next steps.

Having said that, not all is rosy. You still have many chances to mess up configurations and set up a whole park of insecure resources :-)

Main Terraform commands

For the following examples, keep in mind that we’re mostly dealing with these four terraform commands:

terraform init
terraform plan
terraform apply
terraform destroy

Basically, we’re going to init a configuration, plan the creation, and then apply it one or many times, and explicitely or implicitely destroy resources.

First configuration and initialization

Let’s create a folder terraform-ec2 with a file named main.tf. This is where our configuration, written in HCL (Hashicorp Configuration Language), goes.

main.tf:

provider "aws" {
 profile = "terraform"
 region = "eu-central-1"
}

We’re defining a provider with whom we want to interact to manage the resources. For AWS I’m using the profile “terraform”, which is the profile I defined earlier in ~/.aws/credentials, and the region “eu-central-1”.

Going to the directory and running terraform init will now make Terraform parse the file, check the defined provider and download a plugin for interacting with said provider (you’ll find it in .terraform/plugins).

The output will be something like this:

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.62.0...

[...]

Terraform has been successfully initialized!

[...]

Naturally, you can do this for other providers as well and create resources in multiple locations.

Defining resources

Now that we know which provider to target, let’s define an EC2 instance and a security group:

resource "aws_instance" "my_vm" {
 ami = "ami-0b6d8a6db0c665fb7"
 instance_type = "t2.micro"
 key_name = "terraform"
 security_groups = [aws_security_group.ssh_http.name]
}

resource "aws_security_group" "ssh_http" {
 name = "ssh_http"
 description = "Allow SSH and HTTP"

 ingress {
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = ["x.x.x.x/32"] # make this your IP/IP Range
 }
 ingress {
 from_port = 80
 to_port = 80
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
 egress {
 from_port = 0
 to_port = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

We’re defining a new EC2 instance in the first resource block and are naming it my_vm in this configuration.

ami refers to an ID of an Amazon Machine Image (AMI). We could make/pre-configure our own but to keep things simple in this tutorial, we’re going to use the ID of a public Ubuntu 18 image in the eu-central-1 region. Note that if you picked a different region in the provider configuration, you need to look for an AMI in your region instead (e.g. in the EC2 console -> Images -> AMI, or via the Ubuntu AMI Locator).

With instance_type we are choosing the vm configuration – in this case t2.micro, which gives us a 1 vCPU, 1 GB memory machine that is more than enough for playing around.

The key_name is another essential attribute. Here, we specify the name of a keypair that we previously created and uploaded to our AWS account (e.g. in the EC2 console -> Key pairs -> Import key pair). We could also create it in this configuration (resource "aws_key_pair"), but to not introduce too many new steps, we’ll be using an already existing one. Make sure to also have the private key readily available on your machine for later steps.

There are many more resources and configuration keys – have a look at the provider docs for more details. For now we are only going to define the security group before finally seeing what we are acutally creating with this config.

The security group is referenced in the aws_instance section by its name and defined in its own resource block aws_security_group (note that all aws resources have the aws_ prefix).

If you’re not familiar with security groups on AWS: it’s essentially a virtual firewall with rules for your ingress (inbound) and egress (outbound) network traffic.

So here we are defining an allow rule for inbound tcp traffic on port 22 and 80. If you don’t want to have 22 open to the world, add the IP address you’re coming from for the cidr_blocks key. “-1” in the egress section means “all”; the rest should be self-explanatory.

Plan execution

Now we’re finally ready to see what our configuration would do when being executed. Let’s run terraform plan, which will not yet create the resources but tell us if we have configured everything syntactically correct (there’s also terraform validate if you only want that), do a dry-run and then give us information that can be known from what we defined.

The output (shortened) will look like this:

[...]
Terraform will perform the following actions:

 # aws_instance.my_vm will be created
 + resource "aws_instance" "my_vm" {
 + ami = "ami-0b6d8a6db0c665fb7"
 + arn = (known after apply)
 + associate_public_ip_address = (known after apply)
 + availability_zone = (known after apply)
 [...]
 }

 # aws_security_group.ssh_http will be created
 + resource "aws_security_group" "ssh_http" {
 + arn = (known after apply)
 + description = "Allow SSH and HTTP"
 [...]
 }

Plan: 2 to add, 0 to change, 0 to destroy.

+ here means adding. Later when things are changed, we’ll see - for removing or ~ for updating in-place. Many keys show “known after apply” as these values are only determined at execution time.

With our dry-run we can see that we would create 2 new resources. Let’s go ahead and run terraform apply to make it reality.

Apply

Since we didn’t store the previous execution plan, a fresh one is created and we’re asked for confirmation.

The output of applying our configuration will look something like this:

aws_security_group.ssh_http: Creating...
aws_security_group.ssh_http: Creation complete after 5s [id=sg-xxx]
aws_instance.my_vm: Creating...
aws_instance.my_vm: Still creating... [10s elapsed]
aws_instance.my_vm: Still creating... [20s elapsed]
aws_instance.my_vm: Creation complete after 29s [id=i-xxx]

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

First, the security group was created and then the EC2 instance (which was depending on the group). We should now be able to ssh into the box with ssh -i our-private-key ubuntu@ip-of-new-instance.

Generally, dependencies are resolved automatically (as we have seen here), but can also be provided manually if Terraform cannot know them (depends_on).

Besides creating the resources, Terraform also created a local state file (terraform.tfstate) in our working directory. This file contains information about the state after creation (you’ll see that all previously unknown keys now have values) and is later used to check for changes to the real infrastructure and to know what to change/destroy when config adjustments are being applied. Generally, the state will always be refreshed (synced with the current actual state of your resources) when you plan/apply your next config. As a convenience, you can show the currently stored state with terraform show.

Change

For demonstration purposes, let’s change the instance_type to t2.nano:

resource "aws_instance" "my_vm" {
 ami = "ami-0b6d8a6db0c665fb7"
 instance_type = "t2.nano"
 [...]
}

And now run terraform apply again:

# aws_instance.my_vm will be updated in-place
~ resource "aws_instance" "my_vm" {
 [...]
 instance_state = "running"
 ~ instance_type = "t2.micro" -> "t2.nano"
[...]
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

We successfully changed our instance type and can also see that the terraform.tfstate file has changed (compare to terraform.tfstate.backup, which was automatically created).

Generally, Terraform will always tell you if an in-place change is possible or if it will destroy/re-create your resources (important in case you would need to extract data before destruction).

Destroy

Knowing what we created, we can now just as easily destroy all our resources by executing terraform destroy (again, after a confirmation of the execution plan).

aws_security_group.ssh_http: Refreshing state... [id=sg-xxx]
aws_instance.my_vm: Refreshing state... [id=i-xxx]
[...]
Destroy complete! Resources: 2 destroyed.

Further provisioning

While we could work with our own pre-configured images (instead of using a public AMI like we did above), it is also possible to define some initialization steps after creation of a resource – both locally (on the machine running the terraform command) and remote (on the created system).

Let’s keep things simple and just define a couple of remote commands that will be executed via SSH after creation of our VM. Note that this will only be possible if the machine is already configured to receive connections. If the remote service (such as SSH or WinRM) needs to be configured/started first, you might want to first have a look at cloud initialization configs, such as writing your script in a user_data section for EC2 instances. For the Ubuntu image we chose, everything is already set up for us.

Since we earlier configured our security group to allow inbound traffic at port 80, let’s install an Apache webserver on our instance by just using commands executed with the remote-exec provisioner for demonstration purposes.

Add the following block into the aws_instance resource block:

provisioner "remote-exec" {
 inline = [
 "sleep 10",
 "sudo apt-get update",
 "sudo apt-get -y install apache2"
 ]
 connection {
 type = "ssh"
 user = "ubuntu"
 private_key = file("~/.ssh/terraform")
 host = self.public_ip
 }
}

The inline steps will be invoked after resource creation and be executed over SSH using the specified key and the IP of the newly created instance. I’ve added a short delay as a quick hack to let the cloud init finish and prevent dpkg locks.

For further convenvience we’ll also add an output block at the very end of our main.tf that will show us the public IP (hint: you can also access these output values later on with terraform output as they are stored as part of the state file).

output "instance_ip" {
 value = aws_instance.my_vm.public_ip
}

Let’s terraform apply and watch the install fly by. At the end, we get the public IP:

Outputs:

instance_ip = x.x.x.x

If everything worked well, navigating to that IP with a browser will show us the Apache default page.

Making it a bit nicer

Let’s destroy our resources again (terraform destroy) and then do one last thing before wrapping up: making the config a bit nicer by using variables, instead of sprinkling hardcoded values everywhere.

To create default values for our variables, we’re creating a new file terraform.tfvars (if named like this, it’ll be read by default):

ssh_source_ips = ["x.x.x.x/28", "x.x.x.x/32"]
ami_owner_id = "099720109477"
key = ["terraform", "~/.ssh/terraform"]

Here, we define two source CIDR blocks with a couple of addresses that we allow for SSH, an owner ID of the AMI we want and our keypair values from before (name and local path).

The AMI owner ID is that of Canonical (also see Ubuntu’s AMI locator) so that we can dynamically select the latest ubuntu 18 image (see the following changes) and make our script work for regions other than eu-central-1 (as we don’t have the hardcoded ami ID anymore).

This is how our final main.tf will look:

variable "region" { type = string }
variable "ssh_source_ips" { type = list(string) } # list of CIDR blocks
variable "ami_owner_id" { type = string }
variable "key" { type = tuple([string, string]) } # key_name and path to local private key

provider "aws" {
 profile = "terraform"
 region = var.region
}

data "aws_ami" "ubuntu_18" {
 most_recent = true
 owners = [var.ami_owner_id]

 filter {
 name = "name"
 values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
 }
}

resource "aws_instance" "my_vm" {
 ami = data.aws_ami.ubuntu_18.id
 instance_type = "t2.micro"
 key_name = var.key[0]
 security_groups = [aws_security_group.ssh_http.name]

 provisioner "remote-exec" {
 inline = [
 "sleep 10",
 "sudo apt-get update",
 "sudo apt-get -y install apache2",
 ]
 connection {
 type = "ssh"
 user = "ubuntu"
 private_key = file(var.key[1])
 host = self.public_ip
 }
 }

}

resource "aws_security_group" "ssh_http" {
 name = "ssh_http"
 description = "Allow SSH and HTTP"

 ingress {
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = var.ssh_source_ips
 }
 ingress {
 from_port = 80
 to_port = 80
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
 egress {
 from_port = 0
 to_port = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

output "instance_ip" {
 value = aws_instance.my_vm.public_ip
}

output "chosen_ami" {
 value = data.aws_ami.ubuntu_18.id
}

All variables are defined at the top. Besides source_ips, key and ami_owner_id, we have region which we haven’t given a default value in the terraform.tfvars file. Once we execute our config, we’ll be asked for a value (alternatively, we could also pass it with a -var flag with the apply command).

The image selection is now done in a data source block; we’re basically filtering for the most recent bionic image from owner Canonical and then using its ID in the instance block.

At the very end we additionally output the chosen AMI.

Let’s now run the new config by executing terraform plan. Enter a desired region and check the ami-id in the execution plan. It’ll differ when you run another plan and choose a different region.

Finally, apply the config and check that everything works. At the time of writing, for eu-central-1 the output should look like this:

Outputs:

chosen_ami = ami-0b6d8a6db0c665fb7
instance_ip = x.x.x.x

Explore further

Obviously, you can do much, much more and also do things better than outlined here. I hope my notes gave you enough information to start exploring Terraform, or “infrastructure as code” in general, further. Especially once you start dealing with more resources, you’ll appreciate this more transparent and more actionable way of managing resources. Like with any automation, it just feels good once everything is set up and works by just pushing a few keys :-)