Question about the terragrunt experimental "IaC engines" support

[mattwilder]

Apologies if this is the wrong place for this, but I did not see a section under the "Experiments" section.

I was looking at the documentation for the experimetnal IaC Engines functionality, specifically the client/server example.

It looks to me like the code in the example is designed in a way so that the client and server have to run on the same machine, as they both have to have access to the working directory. Has there been any thought given to how this might work when the client/server are on different machines?

For example, is there any way using the engine framework to communicate the rendered terraform state (ex: output from a terraform {} block, along with a generate {} block, and a remote_state {} block) from the client to the server so that commands can be executed even if they are not on the same machine?

I ask because this functionality looks incredibly promising to resolve an issue we are facing with IaC provisioning in customer environments, where we don't want to ship our entire terragrunt code base (with configs for many other environments) just to provision the single provider. I just don't see how we could communicate the rendered terraform environment across the client/server boundary.

Was this not the designed use case of engines, or am I missing something?

Thanks.

[yhakbar]

Hey @mattwilder ,

Great question. This is the right place for it, and so is the Terragrunt Discord.

The reason the IaC Engines feature isn't documented in the experiments section is that it predates the experiments system. I've been meaning to add it, but I haven't had the time to justify going through what will end up providing little value to end users.

Yes. IaC Engines were built to support running with the client and server running on different machines. Anything that makes it less than ideal for doing that right now is something we'd love to learn more about.

At a high level, the design philosophy for IaC Engines is as follows:

The responsibility for IaC Engines start right when Terragrunt would normally invoke tofu / terraform. Anything that is appropriate to do at that point in time is a good thing to do with an IaC engine. That might involve reading a terragrunt.hcl file, and it might involve initiating a gRPC connection with a remote server.

The fact that the IaC engine always starts running on the same host as Terragrunt (although it, in turn, could start a remote connection with a different host), is what lead us to design the interface for IaC Engines to be as minimal as possible, and to expect plugin authors to handle acquiring any data they need from the host before they establish a remote connection. We've left open the generic meta attribute as a mechanism for sending arbitrary data down to the plugin, which might be used on remote servers.

That being said, the reason that IaC Engines are in experimental status is that we haven't had a lot of users willing to try it out and give us feedback on real world usage. We've left it in experimental status to leave open the possibility of changing the interface between Terragrunt and engines.

If you do start adopting IaC Engines, and you find that there's a really good case to be made to expand the interface between Terragrunt and IaC Engines, we're open to making adjustments.

[mattwilder]

Looking through the code, I am fairly confident that this is the case.

Dependency resolution is done through getTerragruntOutputJSON, which either calls getTerragruntOutputJSONFromInitFolder or getTerragruntOutputJSONFromRemoteState*, both of which call RunCommandWithOutput but with new instance of TerragruntOptions that loses whether the engine functionality was enabled or not.

Do you see anything wrong with passing the correct options through to these functions so that the engine codepath can be taken for dependency blocks?

We would need dependencies to go through the engine for this to work for our intended use case, which is to have the only access to the AWS account go through the engine

* There is also a code path that calls runTerragruntOutputJSON, but it isn't entirely clear to me how you can get that to actually trigger

[mattwilder]

Looking at this a bit further, it looks more like support for the engine functionality would need to be added to the partial config parsing functionality used by dependency blocks

[mattwilder]

After further examination, it turns out that simply adding support for parsing the engine config in PartialParseConfigFile was enough to make terragrunt use the engine for dependencies!

I am putting together a pull request and will send it out for review shortly.

[mattwilder]

I created an issue for this and also submitted a PR that parses the engine block when reading terragrunt configs for dependencies.

With the changes in the above PR, our dependency blocks now go through the IaC engine as expected.

[mattwilder]

Thanks @denis256 and @yhakbar for your help!