Skip to content
This repository was archived by the owner on Aug 19, 2021. It is now read-only.

Commit 35dcf49

Browse files
authored
Merge pull request #46 from objectrocket/readme-updates
Add some more examples and info to the README
2 parents 567b02a + 86b4c18 commit 35dcf49

File tree

1 file changed

+46
-0
lines changed

1 file changed

+46
-0
lines changed

README.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -62,6 +62,52 @@ Build and publish the package to PYPI:
6262
% poetry publish --build
6363
```
6464

65+
## Configuration
66+
67+
A project is configured through a worker config, a yaml file that specifies the definitions, inputs, outputs, providers and all other necessary configuration. The worker config is what specifies how state is shared among your definitions. The config support jinja templating that can be used to conditionally pass state or pass in env variables through the command line via the `--config-var` option.
68+
69+
*./worker.yaml*
70+
```yaml
71+
terraform:
72+
providers:
73+
aws:
74+
vars:
75+
region: {{ aws-region }}
76+
version: "~> 2.61"
77+
78+
# global level variables
79+
terraform_vars:
80+
region: {{ aws-region }}
81+
environment: dev
82+
83+
definitions:
84+
# Either setup a VPC and resources, or deploy into an existing one
85+
network:
86+
path: /definitions/aws/network-existing
87+
88+
database:
89+
path: /definitions/aws/rds
90+
remote_vars:
91+
subnet: network.outputs.subnet_id
92+
```
93+
94+
In this config, the worker manages two separate terraform modules, a `network` and a `database` definition, and shares an output from the network definition with the database definition. This is made available inside of the `database` definition through the `local.subnet` value.
95+
96+
`aws-region` is substituted at runtime for the value of `--aws-region` passed through the command line.
97+
98+
## Troubleshooting
99+
100+
Running the worker with the `--no-clean` option will keep around the terraform files that the worker generates. You can use these generated files to directly run terraform commands for that definition. This is useful for when you need to do things like troubleshoot or delete items from the remote state. After running the worker with --no-clean, cd into the definition directory where the terraform-worker generates it's tf files. The worker should tell you where it's putting these for example:
101+
102+
```
103+
...
104+
building deployment mfaitest
105+
using temporary Directory: /tmp/tmpew44uopp
106+
...
107+
```
108+
109+
In order to troubleshoot this definition, you would cd /tmp/tmpew44uopp/definitions/my_definition/ and then perform any terraform commands from there.
110+
65111
## Background
66112

67113
The terraform worker was a weekend project to run terraform against a series of definitions (modules). The idea was the configuration vars, provider configuration, remote state, and variables from remote state would all be dynamically generated. The purpose was for building kubernetes deployments, and allowing all of the configuration information to be stored as either yamnl files in github, or have the worker configuration generated by an API which stored all of the deployment configurations in a database.

0 commit comments

Comments
 (0)