Terraform 1.0 and Terraform Cloud Workflows

In this demo session, see the new features of Terraform 1.0 in action and see them in a Terraform Cloud workflow as well, showcasing Terraform Cloud's updates. You'll also learn why Terraform 1.0 is a big step forward for the product.

Speaker: Kyle Ruddy

»Transcript

Hello and welcome to this HashiConf session. My name is Kyle Ruddy from the technical marketing group here at HashiCorp — and I am extremely excited to bring you this session; it's been a long time coming. That is, of course, because Terraform 1.0 is now. 

If you paid attention to HashiConfs prior, you've probably seen Kristin Laemmert's session about the path to 1.0, hitting several different criteria. But if you look at Terraform the language, it's been through quite the journey. 

»Terraform Past 

If we go back to 2011, this was the lightbulb moment about thinking through the workflow in which we wanted to provision and manage infrastructure in a declarative way. But we wanted to do that against several different services instead of maybe — perhaps — a singular dedicated service.

Fast forward a bit, nothing had hit the market that piqued this interest. So introduced was Terraform 0.1. Then there was so much excitement around it — and so much activity — that we were able to release 0.2 that same year.  It featured three new providers to start interacting with some of the various other services that had come along. 

Then fast-forwarding a couple versions and a couple of years, we get to Terraform 0.7. And the big milestone here was 500 different contributors, which is a massive amount for that small period of time. Then fast forwarding a single year — but yet a couple of different versions, we get to Terraform 0.10.  With this one, we hit another major milestone of more than 1,000 contributors.

If you'll remember, this also came with another change in how we access providers. That queued up the release of the Terraform Registry, which was introduced in 2017 as well. Then fast-forwarding, a couple more years, we get to 2019 — and with that came Terraform 0.12 — and the introduction of HCL2. That was a bit about Terraform's past.

»Terraform Present 

Let's look at Terraform present because we hit some significant milestones across that time. First and foremost contributors from the community — we've hit more than 1,500 contributors. This is massive to see the amount of adoption and support that's come in from the community — hopefully, some of you have started seeing some of those gift boxes that have been coming out — so thank you for all that you've done. 

We also have a vast expanse in the ecosystem itself. The Terraform Registry now features more than 1,000 different providers. It also features more than 5,000 different modules that have been contributed. Then we get into downloads. If we think about the Terraform binary itself, it's now being downloaded more than a million times per week — and overall it's been downloaded more than 100,000,000 times, which is insane. That's such a large amount of downloads — it's wild.

I also want to call out a special thank you and appreciation for our certification team.  This next metric couldn't be done without them, as well as more than 10,000 Terraform associates that are out there and have taken the exam and passed it. That's another fantastic milestone that Terraform has been able to reach. With that, let's get into Terraform 1.0.

»HashiCorp Terraform 1.0

Is this significant? If you have been wondering about the how we get from 0.X release into a 1.0 release a lot of this comes down to being able to support the scale of any company or organization — going from startups to the Global 2,000 or even individual DevOps practitioners. Millions of practitioners are choosing Terraform as the way to manage and provision their infrastructure. 

Then we get into some of the stability that comes with something like a Terraform 1.0 release because it ensures stability as well as improving that workflow — so that regardless of what workload is being provisioned and managed, it's going to be done consistently. Anybody on those DevOps teams can manage them in a straightforward manner.

And speaking of which, it comes down to usability as well — meaning that no matter what service is being interacted with, you still can interact, manage, and provision those resources —  regardless of whether it's an on-premise environment — like say maybe a Cisco ASA or perhaps a VMware-vSphere environment — to some of those cloud services such as an Amazon AWS or a Microsoft Azure or a Google Cloud Compute. Or maybe it could even be a mix of everything in between for either a hybrid environment or a multi-cloud environment as well. In the end, Terraform 1.0 is here to provide that stability and usability across the board for any of those services that we have providers for.

»Terraform 1.0 Maintenance 

Let's get into what's known as the maintenance side of Terraform 1.0. One of the key parts here is the upgrade process. Throughout the 1.x product life cycle, existing workflows are going to continue to work without a requirement for upgrade tools, refactoring, or other code changes. 

That's a tremendous improvement if you think about that Terraform past slide — from some of the things that we've gone through to get to this 1.0 release. Then we also have workflow support. We were planting a flag in the ground and saying that Terraform 1.0 will have a maintenance period of up to 18 months. Where we — here at HashiCorp — will investigate bugs and release features throughout the entire 1.x life cycle, which is a tremendous improvement.

»Terraform 1.0 Demo

Let's get into my favorite time of every session, and that's demo time. In this demo, we're going to talk about some of the newest features that are coming to Terraform 1.0. 

»Interoperability 

Here’s a Terraform Cloud environment where we've taken a fairly simple web application and deconstructed it into several different workspaces that we can run several different versions of Terraform. Here in our first one, we're going to be creating a resource group within Azure. Thanks to our new workspace overview page, we can see a lot of good information right off the bat — including that we're running Terraform 0.15.2 to create one single resource, which we assume is the resource group.

But if we click on the show details, we can go down to see the results of our apply finish  — and this is part of a beta program that's going on right now — we can see that we've created an Azure RM resource group that's called My Resource Group inside our Terraform configuration file. 

But then on the outside, we can see that's created a resource group name of Ruddy Demo as part of the outputs, as well as our Terraform version. That will be more important here in a second. But now, as we should try and build to get to that web application, we also need to create some network stuff. 

Here, we're using Terraform 0.13.6 and creating six resources. That seems like a lot. But thanks to some integration with our version control system, our workspace overview has our readme integrated into it. If we scroll down toward the bottom, we can see the resources that are created in here. It includes some security configurations such as access through SSH as well as HTTP. But it also features a public IP, which if we scroll back up, we’ll see a fully qualified domain name.

If we reference our outputs here, we can take that FQDN URL, open that up in a new tab, and here we have a default page for an Apache configuration that's been set up in a virtual machine that was pre-provisioned. 

Speaking of that virtual machine, let's head over to that workspace and see how that was configured. In this case, we're using Terraform 0.14.9 to create five different resources that make up that virtual machine that we saw the Apache default page for. 

In our outputs, we have our credentials that are being marked as sensitive, as well as our Terraform version and our virtual machine name. Here's where those outputs get important because we're going to switch to our web app workspace. As part of this, we're using Terraform 0.12.30 to populate the web page that we're going to see on that Ubuntu image.

So here we're going to queue up our plan — what's going to create all of our resources for that web page. However, because I want to show you that there's no magic going on behind the curtain or up my sleeve, here are our variables. 

We're not connecting to Azure in any way, shape, or form, we're not storing any SSH keys in there, everything is being done through our main configuration file, which we can click on through our workspace overview page. Then in our main configuration file here, we can see the usage of the Terraform remote state data source, which is reaching out to those other workspaces to grab those outputs so that we can populate the web page. We're able to SSH into that system, we're also able to pass it in those different Terraform versions, as well as some other information.

And we do that through a very simple shell script called deploy app. For the sake of clarity, let's take a brief look at our deploy app shell script. We're just creating a very simple index.html page, which is going to output some of those outputs that we stored in environmental variables — such as the Terraform version for each of our workspaces, as well as some other important information. 

Once we return back to Terraform Cloud, we can see that our latest operation has completed — it's been applied. And if we reconnect out to our FQDN, we can see that now we have a cat image, which is the end result of this web application. However, we can also see that this was all done through Terraform 0.12. We can see that our resource group name was sourced from 0.15.2, our FQDN was sourced from 0.13, as well as our virtual machine name was referenced from Terraform 0.14.  This all shows you the interoperability between all of those different Terraform versions to continue to support one another as we go through the upgrade process.

»Terraform 1.0 Upgrade Process

So speaking of the upgrade process, let's look at what that looks like for our different workspaces in this environment. Going back to our Terraform Cloud environment, we're going to switch back to our resource group, and once we're in there, we can change our Terraform version simply by clicking on the 0.15, which takes us to our general settings — which then we can choose our 1.0 Version. 

Once we click on save, we'll notice that our workspace has been updated to use that new version.  However, we want to run this against several different workspaces as well — so one of my favorite things is using Terraform to automate our Terraform environment.

So we're jumping over to our terminal session here, and we're running an apply against a configuration that set up that Terraform Cloud environment through the TFE provider. Once this completes, we're going to see that three of those workspaces are now using Terraform 1.0 instead of the prior versions. Then if we switch back to Terraform Cloud, we can see that even the description for this workspace has been updated to show that it's using Terraform 1.0 — because we want anyone who clicks into this workspace to know that ahead of time, so that it's not a surprise. 

We're going to cue a new plan because we have to generate those new outputs for that Terraform version Then we're going to make use of run triggers, which is a Terraform Cloud feature that runs each operation from each workspace throughout the next — as it's been configured to recreate all of those Terraform version outputs, as well as make any necessary changes to the configurations.

Now, we're going to use some movie magic to fast forward through this process so that we don't have to wait for each workspace to complete. But once we get to our web app that's been applying, we can click into that workspace and see our updates. 

This one is continuing to use 0.12.30, so keep that in mind. If we go down to our FQDN and open that up in a new tab. We can see our information has been updated. We can see that our resource group name is being sourced from Terraform 1.0, as well as our FQDN, as well as our virtual machine name. 

This shows how much a lot of these Terraform versions have improved the upgrade process throughout the years — even going back to 0.13. However, I will throw out a caveat, this was a simple configuration set up, so this may or may not work in your environment this way — definitely check the upgrade guides for the versions as you're upgrading through the entire process.

»Learn More

That was a great demo that took a look at the interoperability between the different Terraform versions, as well as the upgrade process as we go throughout the one 1.x lifecycle. To learn more, first and foremost, 1.0 is available today for download as well as usage in Terraform Cloud. 

If you're looking for some more information, check out the Terraform 1.0 announcement blog. Stay tuned for the Terraform 1.0 webinar coming in about a week. Then also right after this session, we have Kristin Laemmert's follow-up session to the path to Terraform 1.0 with an engineering look at how we got to where we are today. Thank you.