# This functionality is deprecated. Moving forward, lock tables should not be required and all of the ones contained in this repo have been deleted.

# terraform-state-lock
Terraform repository for state locking resources

The purpose of this repository is to manage state-locking resources (e.g. S3 buckets, DynamoDB tables) with Terraform separately from the resources that require them. Centrally, Terraform backend instantiation happens before any other resources can be managed, so creating the DynamoDB lock table in the same Terraform file that requires it for locking results in errors. 

State lock reference: https://www.terraform.io/docs/backends/types/s3.html#dynamodb_table

## Usage

### Directory Structure
This summarizes the directory structure of this repository:

```
/
    dev
        application_1
            main.tf
        application_2
            main.tf
        application_3
            main.tf
    qa
        application_1
            main.tf
        application_2
            main.tf
    prod
        application_2
            main.tf
    modules
        state_lock_bucket
            main.tf
            variables.tf
        state_lock_iam
            main.tf
            variables.tf
        state_lock_table
            main.tf
            variables.tf
```

In this example:
* There are three environments, `dev`, `qa`, and `prod`.
* There are three modules supporting state-locking resources for Terraform. Those modules are: `state_lock_bucket`, `state_lock_iam`, and `state_lock_table`.
* There are three applications for which state-locking has been configured - `application_1`, `application_2`, and `application_3`.
* Only `application_2` is configured for state-locking in the `prod` environment.
* Only `application_1` and `application_2` are configured for state-locking in the `qa` environment.
* `application_3` is only configured for state-locking in the `dev` environment.

Suppose you are ready to add `application_3` to the `qa` environment. You would add a directory `qa/application_3` containing `main.tf` to describe the state-locking behavior of `application_3` in the `qa` environment.

### Provisioning resources

Suppose you are ready to provision the `application_3` state-locking resources for the `qa` environment - your changes to main.tf and variables.tf are peer-reviewed AND merged.

You would do the following:

```sh
cd qa/application_3
terraform init
terraform apply
```

#### `terraform.tfstate` File

This generates a `terraform.tfstate` file. Because this `terraform-state-lock` repository is trying to solve the chicken-and-egg problem of managing state-locking AND using code as infrastructure, IT IS THE SOURCE OF TRUTH/VERSION CONTROL system for state-lock `terraform.tfstate` files. Do check in the `terraform.tfstate` that is generated by running `terraform apply`. THIS IS THE ONLY REPOSITORY WHERE YOU SHOULD EVER BE CHECKING IN `.tfstate` FILES.

### De-provisioning resources

Similarly if you would like to de-provision a state-locking environment for an application, you would need to do it per environment-application. To de-provision `application_3` from the `qa` environment, you would do the following:

```sh
cd qa/application_3
terraform init
terraform destroy
```

Note that in order for this to work as intended, the `terraform.tfstate` file must be present. Upon deprovisioning, do make a PR to update `terraform.tfstate` file for this environment-application.