DevOps: Programming the Terraformer
• Mark Eschbach
We’ve decided we’re going to run with Terraform as our tool to create and maintain our AWS infrastructure. The tool looks interesting, maintaining the state of the managed resources and ensuring they are in compliance with the declaraed sepcs. Terraform scripts are an interesting structured format following the general form of:
resource "type_of_resource" "name-of-resource" {
property = "value"
some_property = "a-value"
...
}
You declare the configuration of these resources. When a plan is generated the Terraform system will decided on the order of create and modification of the existing system based on interal heuristics. If my expeirence in Prolog is any indication then this will fall apart at some point but should work well enough.
Although Terraform may configure individual hosts, the general gist of the documentation seems to indicate a host configuration management system should be used and their system is only intended to boostrap those systems. From the examples I’ve encountered so far Terraform works well for building and configuring the network. This includes VPCs, ELBs, Routers, and hosts. The hosts would then execute whatever boostraping process is normal for the configuration management system.
There is an interesting question regarding the scope of a Terrform instance: what is the level of responsibility. In a simple deployment it’s easy to say your configuration is responsible for all elements of the account. Beyond the simplest case there are several levels of interest. There is generally account wide settings which should be applied such as security pocilies and groups which should be created. There is some question on the creation of user accounts which I would venture towards being hand created and managed for the devops, although the groups I would argue fall under the perview of the scripts.
For a durable production system you should be running in multiple availability zones. Each zone will have similar node types and probably configured within the same autoscaling groups.
Authorizing AWS work
I generated a new SSH key for AWS and uploaded the key. From here I need to configure the credentials to use. I grabbed the tools from Installing the AWS Command Line Interface in hopes of generating the credentails files. I have the constraints that I don’t want the default credentials because we desire to be very careful about the environment we connect to. The configuration file looks fairly straight forward. Looks like the best way that I can come up with right now is to avoid having a default profile and name each one, then set AWS_DEFAULT_PROFILE
to the target. Easy enough; time to test.
Alrighty, looks like you need to use the following to target a different profile: export TF_VAR_aws_profile=other
. Also, the MFA stuff doesn’t easily integrate with Terraform sadly so I will need to check that out later. I’ve pulled it for now.
With this I was able to get the plan from Terraform. Awesome possium. And my first run failed. Time to figure out how to rollback. Learned don’t run terraform apply plan
twice in a row as it stops terraform plan --destory -out rollback && terraform apply rollback
from working as one would expect. Have fun crawling through the information. Actually resource groups are a great way to go about that. I wonder if we could automate the creation of resource groups. Our goal is to tag each resource with environment name so we can easily take and manage inventory.