New Terraform Features Manage Migrations, Modules
BOSTON — During his keynote at HashiConf Tuesday, HashiCorp co-founder and CTO Armon Dadgar showed audiences a picture of a room full of empty computer workspaces.
“What is this a picture of?” he asked the audience, before quipping, “If you guessed a room of developers that care about patching, you’d be correct.”
A bit unfair to developers, perhaps, but it played well in this audience of systems engineers, architects, consultants and others who manage infrastructure.
Dadgar introduced a slew of new offerings designed to simplify management of infrastructure by simplifying Terraform modules and migrations.
He also shared a new offering that will help organizations manage GPUs for AI and generative AI use across the organization.
It’s all part of what Dadgar called the delivery application tree, which he defined as having four categories of solutions:
- The application lifecycle management, which includes GitHub, GitLab and other repositories;
- The infrastructure lifecycle;
- The security lifecycle; and
- The monitoring lifecycle.
HashiCorp’s solutions focus on the middle two, he added.
“We’ve been increasingly focused on how do we make that simpler for organizations? … How do we start integrating the various workflows when you think about those life cycles around infrastructure and security management?’” Dadgar said. “Obviously, there are many different products in the HashiCorp portfolio, but ultimately, they’re in service of these two different challenges.”
Terraform Stacks
He provided more details about Terraform Stacks, a new public beta feature that helps with provisioning and managing multiple resources across multiple Terraform configurations and environments. For instance, it can be used to manage across multiple cloud environments. It can be used with Kubernetes as well.
He used an example of defining an underlying Kubernetes cluster on Amazon to deploy an app on top of the cluster.
“Now, in classic Terraform, you almost have to break this into two different configurations, because the planning phase of your Kubernetes app would almost always fail when the cluster doesn’t exist,” he said. “Now, we can model these as two different components, and …the fact that the second component depends on the Kubernetes cluster created the first TerraForm automatically figures out these things implicitly have a dependency. I have to create the first before the second.”
Terraform is aware of the fact that you now have these multiple environments, he said, so this becomes a first-class concept that can be orchestrated.
The UI for Terraform Stacks allows user to see what environment components belong to, he explained.
“If I click into one of these [environments] like the development environment, I can see the multiple components, and I can see that multiple planning and execution phases have to take place to get that thing to where it is,” he said. “Already, this allows us to now have a much more first-class modeling of how we think about more complicated application environments. But more than that, it starts to unlock us doing much more interesting types of orchestration.”
He delved into deferred change, a feature of stacks that helps differentiate it from “classic” Terraform. Whereas classic Terraform would, if a Kubernetes app was dependent on a cluster that wasn’t created, it would trigger an error message that.
“Now, we’re creating it now with Stacks,” he said. “It figures out, actually, I won’t be able to do this in one plan, because you’re sort of crossing an impossible plan threshold, right? I have to first create the cluster before I can talk to a cluster. So I’m going to split this into multiple plans. That is what we call a deferred change.”
It allows infrastructure teams to create an incremental plan and apply it.
Incremental Plans
Orchestration rules is the second feature of Stacks, he continued.
“Because we have a first-class concept of environments, and you have a first-class concept of these components, you can now bring various logic,” he said. “So this is a very simple orchestration rule that basically says, As long as it’s my development environment, and it’s a non-destructive change, auto approve, right? I don’t want to have to even look at the plan. Just run the plan. Go directly into apply.”
He ran a demo showing how Stacks creates and implements an incremental plan.
“We approved the underlying cluster that ran for completion, then we can see it did another plan to create the Kubernetes app,” he said. “It’s going to ask us to approve that as well, and then when that finishes executing, both the underlying cluster and the application have now been successfully deployed, and you have the entirety of the stack now running so very similar in terms of having to plan an execute style, but now you have this higher level abstraction of the stack that allows us to have this richness.”
Beyond Stacks: Terraform New Features
Dadgar also introduced Terraform module lifecycle management now.
It supports managing patches and upgrades by creating notifications — by email and within the developer’s workspace — of deprecated assets. For instance, if there’s an old version of a Java module and the organization needs to move to the new version because of a vulnerability, it will identify the right service owner and automatically notify them to update.
“This starts to complete that cycle of how do we provide visibility to platform teams and organizations that are managing a broad infrastructure state?” He said. “How do we give you a way to interface with all those different teams as you’re managing that lifecycle, and how do the applicants get notified to actually respond and do something, take some action.”
That led to Dadgar’s second “pop quiz” with the picture of the empty developer room.
“What does this room represent? If you guessed developers that love cleaning up after themselves, you got this one right as well,” he joked, adding that the common problem is to see dev-test environments that are left up and running forever.
To deal with this issue, HashiCorp introduced the idea of ephemeral workspaces.
“You could tag a workspace and say, auto destroy if nobody touches this thing after some period of time,” he said. “Now we’ve introduced that at the project level as well. Now we can create a project, maybe it’s a development project where we have many different workspaces, and we can set up auto destroy at that level.”
Instead of having to tag every workspace or development or test project individually a development project or a test project, the infrastructure team can set an automated destroy time of an hour or whatever and it will clean it up, he said.
“Now it’s been about an hour, the system goes through and automatically triggers a Terraform destroy operation and says, Hey, you haven’t touched this in an hour,” he said. “The workspace is still there, but we’ve automatically run Terraform destroy and clean everything up, right? So you can see an auto destroy, automatically triggered. There’s no longer any resources associated.”
What this means is that instead of chasing down developers, infrastructure teams can enforce policies automatically.
“You can spin up on Monday, if you’re not using it by the next Monday, great, we’ll clean up and reap all those resources, no manual action required,” he said.
Finally, he introduced Terraform Migrate, which is designed to help Terraform community users upgrade to enterprise.
“It’s quite meta,” he said. “It’s using Terraform to do the Terraform migration to Terraform.”
The migrate tool looks at an organization’s existing configuration and state files. It allows you to tell it what your intended target state is, then it generates the Terraform coded to handle the migration. It creates workspaces, project hierarchies, moves the state files over and then creates the appropriate pull requests, he added.
“There’s a custom Terraform migrate provider that itself then allows Terraform to run the migration as part of a standard plan apply cycle, and then ultimately, it will result in migration of the configuration and state and resources into your target state,” he said.
Nomad 1.9 Manages GPUs
Finally — he gave his last “pop quiz” with the picture of the empty computer workroom.
“What are we dealing with today?” He asked. “Now we’re dealing with the developers who’ve never heard of AI.”
That led to groans from the audience but created a segue for Dadgar to discuss Nomad 1.9 with multi-instance GPUs.
“Speaking of AI, obviously very top of mind for people, also very expensive for most people,” he said. “One of the things we’ve been focused on with Nomad 1.9 is really improving the experience of managing large scale GPU environments, making effective use of those resources and really unlocking the power of the hardware.”
GPUs are expensive, and often organizations are supporting multiple instances of GPUs with multiple applications running on them, “effectively virtualizing access to the same hardware having multiple slots on it,” he said.
Nomad 1.9 is aware of multi instance GPUs and can detect how many slots a GPU has.
“Now within your job specification, you can actually ask for the number of slots you want, and Nomad is aware of that, so it’s actually doing Bin packing of the GPU hardware as well to make sure you’re maximizing resource utilization,” he said.
Additionally, Nomad 1.9 allows infrastructure teams to allocate GPU within the organization, for instance, saving a set amount for the data scientist team.
“You can impose different amounts of quotas to restrict how much of these resources are consumed by different teams and applications,” he said. “All this stuff makes it easier to manage these large scale GPU environments, do it in a way that’s cost effective and efficient.”
