Occasionally one needs to do a terraform force-unlock and I’m wondering does Gitlab managed terraform help in this use case?
We currently use S3 / DynamoDB, but I think I could convince the team to move to Gitlab managed Terraform if it’s easier to manage the lock from the Gitlab UI.
Many thanks!
The GitLab Terraform state backend works pretty well.
It’s UI is not the greatest in terms of usability (especially with a lot of states) but it does allow you to (un)lock state files from there.
One downside is that one needs “maintainer” permissions in order to write the state (produced when running terraform apply) and for locking/unlocking.
In my experience it is definitively easier to work with than the S3/DynamoDB combination for statefiles.
Yep, we also migrated from Azure backed state files to Gitlab.
The one real feature that’s missing from the UI (available via API though) is retrieving the older state file versions. There’s no way to do so from the UI, so if you need to roll back your state file, you have go through a bit of a process by migrating state to the local backend, overwriting the local state, and then migrating back to the Gitlab backend. Note, we don’t use Terraform workspaces at my org, so I can’t speak to whether the above is an option if you are using workspaces.
Fortunately, it’s rarely needed, but when you inevitably need to make a big change that affects many resources, and something breaks, it is possible to do assuming the above circumstances regarding workspaces apply to you.