stateful_provisioning resource for using provisioners as deployment steps #2696
Conversation
|
I'm hoping to use this mechanism to help us adopt Terraform for deployment across the board even though some of our apps are currently not ready to be deployed as immutable, throwaway instances. Since I realize this is a rather unconventional resource I tried to write some detailed docs on it to help explain, but I lack the Ruby toolchain needed to render the site so I've not actually tested that I've got all the layouts and links right. |
|
Wow this looks really interesting @apparentlymart! Focusing on bugfixes at the moment to get a v0.6.1 release out the door, but will definitely circle back for a full review. 👍 |
|
I noticed that there's a Vagrantfile in the repo to get a middleman server running so I have now tested the docs and fixed one issue I found in the process. (needed to add a new selector to the _docs.scss file) |
|
@phinze for this one I'm currently counting on having a feature like this available to move some of our applications onto Terraform, so if you have a moment it'd be good to have an opinion on whether this is a reasonable approach or whether I should make a new plan for deployment of these applications. Thanks! |
|
👍 This would be really helpful when doing bare metal provisioning where you can't just blow away the the server |
When using immutable architecture, deployment by creating, updating and deleting resources is sufficient. However, some applications are better suited to deployment via arbitrary provisioning that does not result in a managed resource, such as running chef on an existing host with particular arguments. The stateful_provisioning resource provides an "escape hatch" to allow Terraform to be used for this sort of deployment, by allowing the user to manually identify the intended state with an arbitrary string and having Terraform simply re-run a set of provisioners each time that string changes.
|
This is great work - we're moving in a similar but slightly-different direction. See #3244 for details. |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
When using immutable architecture, deployment by creating, updating and deleting resources is sufficient. However, some applications are better suited to deployment via arbitrary provisioning that does not result in a managed resource, such as running chef on an existing host with particular arguments.
The
stateful_provisioningresource provides an "escape hatch" to allow Terraform to be used for this sort of deployment. It allows the user to manually identify the intended state with an arbitrary string (the state key) and then Terraform simply re-runs a set of provisioners each time that string changes.This is intended as a bridge into the "old world" of app deployment via provisioning scripts, so organizations can embrace Terraform as their primary deployment orchestrator without having to find an entirely separate solution for apps that don't fit well into the resource model.
The "state_key" artificially turns an imperative set of steps into a convergent configuration, allowing it to fit into Terraform's model as long as the user is able to adequately describe the desired state via interpolations into a string.
stateful_provisioningResourceAcceptance Tests(skipping these for this one since this resource doesn't actually really do anything, it's just exploiting existing behavior inhelper/schemato get a useful side-effect.)