I hope you have seen the movie Now you see me, it has a famous quote The closer you think you are, the less you’ll actually see. Well, this blog is not about this movie but how I got stuck into an issue, because I was not paying attention and looking at the things closely and seeing less hence not able to resolve the issue.
There is a lot happening in today’s DevOps world. And HashiCorp has emerged out to be a big player in this game. Terraform is one of the open source tools to manage infrastructure as code. It plays well with most of the cloud provider. But with all these continuous improvements and enhancements there comes a possibility of issues as well. Below article is about such a scenario. And in case you have found yourself in the same trouble. You are lucky to reach the right page.
I was learning terraform and performing a simple task to launch an
Ubuntu EC2 instance in
us-east-1 region. For which I required the
AMI Id, which I copied from the AWS console as shown in below screenshot.
Once I got the AMI Id, I tried to create the instance using terraform, below is the screenshot of the code
provider “aws” {
region = “us-east-1”
access_key = “XXXXXXXXXXXXXXXXXX”
secret_key = “XXXXXXXXXXXXXXXXXXX”
}
resource “aws_instance” “sandy” {
ami = “ami-036ede09922dadc9b“
instance_type = “t2.micro”
subnet_id = “subnet-0bf4261d26b8dc3fc”
}
I was expecting to see the magic of Terraform but what I got below ugly error.
Terraform was not allowing to spin up the instance. I tried couple of things which didn’t work. As you can see the error message didn’t give too much information. Finally, I thought of giving it a try by doing same task via AWS web console. I searched for the same ubuntu AMI and selected the image as shown below. Rest of the things, I kept to default. And well, this time it got launched.
And it confused me more. Through console, it was working fine but while using Terraform it says not allowed. After a lot of hair pulling finally, I found the culprit which is a perfect example of how overlooking small things can lead to blunder.
Culprit
While copying the AMI ID from AWS console, I had copied the 64-bit (ARM) AMI ID. Please look carefully, the below screenshot
But while creating it through console I was selecting the default configuration which by is 64-bit(x86). Look at the below screenshot.
To explain it further, I tried to launch the VM with 64-bit (ARM) manually. And while selecting the AMI, I selected the 64-bit (ARM).
And here is the culprit. 64-bit(ARM) only supports a1 instance type
Conclusion
While launching the instance with the terraform, I tried using 64-bit (ARM) AMI ID mistakenly, primarily because for same AMI there are 2 AMI IDs and it is not very visible to eyes unless you pay special attention.
So folks, next time choosing an AMI ID keep it in mind what type of AMI you are selecting. It will save you a lot of time.
Like this:
Like Loading...
Related
It is very informative