- Notifications
You must be signed in to change notification settings - Fork52
Simple and idiomatic examples of various Terraform functions and features.
ContainerSolutions/terraform-examples
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
A reference repository of Terraform with canonical and as-simple-as-possible demonstrations of Terraform functionality and features.
See here for a searchable front-end:https://containersolutions.github.io/terraform-examples/
At Container Solutions we find we regularly need chunks of Terraform to demonstrate something specific, such as:
A simple EC2 instance
A bespoke VPC
A Windows EC2 instance with an EBS volume
This might be to do a basic test of something, find an example to tinker with, or send to someone to get them going.
To help get started with these examples, there are scripts available inbin and in local folders.
Here's an example run:
$ git clone https://github.com/ContainerSolutions/terraform-examples$ cd terraform-examples$ cd aws/aws_vpc$ ./run.shInput AWS_ACCESS_KEY_IDKEYInput AWS_SECRET_ACCESS_KEY<secret>...If you want to skip the manual key/id inputs, then export them.
Seebin/README.md for more information.
If you want to look for a specific example, try theindex.
The code is generally divided up by provider, then resource, then whatever the example illustrates, eglocal/null_resource/for_each, oraws/aws_instance/remote-exec/inline.
Other basic language features may be illustrated in their own folders, egoutputs/local_file/module.
The examples seek to be:
As simple as possible to illustrate the functionality
Self-contained (ie limited to one
.tffile)Clear (eg resource names are verbose and unambiguous)
Naming examples:
simple- for minimal functionality demonstration<functionality>- when demonstrating something more than minimal- directory structure:
<provider>/<resource_type>/<example_name>
Where it makes sense, items that can be changed are prefaced with
changeme_In general, underscores are used in Terraform names over dashes
Naming Terraform resources, data, and variables:
- use only lower case letters, numbers, and underscore
- names should be unique between all examples (but across resources items only if a resource; data items only if data, etc)
- prefixed with:
changeme_<example_name>_
name =attribute within the resource:- use only lower case letters, numbers, and dash
- same as resource name, but with:
s/_/-/g
For help with automated testing
- where possible, add some way to enable 'left-over' resources to be cleaned up, eg provider
default_tagsofcs_terraform_examplesin AWS provider blocks
- where possible, add some way to enable 'left-over' resources to be cleaned up, eg provider
Add inline documentation for each Terraform code block
# Summary:– 1-line summary of what this example does# Documentation:– add link to documentation before each block (terraform, provider, variable, resource, etc.)# Explanation:– add only where some extra explanation is needed
Contributions to terraform-examples project are welcome. You can find detailed information aboutcontributing here.
On every commit/push, the following tests run on all branches:
A
tflinton all files ending withtfA
terraform validateon allA series of checks to test the code against standards
Using slash command /test, a maintainer can run Cloud Testing jobs.This includes:
All AWS provider examples are run against an AWS account
All GCP provider examples are run against a GCP account
All Linode provider examples are run against a Linode account
All DigitalOcean provider examples are run against a DigitalOcean account
All 'local' provider examples are run locally on the GitHub Actions runner
Cloud Environment tests are long and/or cost money and they won't work without the necessary auth information being set up correctly.
The auth information for the provider accounts are stored in secrets in the repository, accessible to the admin.
Slash commands can be used to approve/merge the PR, '/approve' or '/merge'.
The Flow:
PR is opened
Contributor commits/pushes on-demand and triggers the Statis Tests
Once ready, and maintainer runs the Full-CI, which includes Cloud Tests '/test'
If everything goes well, the maintainer uses the command '/approve' to mark as reviewed/approve
The last step, after everything is checked, '/merge' to perform the merge to the main branch
Note: All the slash commands are performed by Github Actions BOT with GITHUB_TOKEN
You can force a test for a given provider (onmain branch only) by adding a.forcetest file to the relevant folder.
For example, if you want to ensure that the aws tests run, then add an empty file inaws/.forcetest. On a successfully completed test run, these files are removed as part of the 'success commit' in the github action workflow.
## Maintainer Information
For information for maintainers of this repository at ContainerSolutions, seemaintainers
About
Simple and idiomatic examples of various Terraform functions and features.
Topics
Resources
Contributing
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Releases
Packages0
Uh oh!
There was an error while loading.Please reload this page.