Alson Kemp

Hackfoofery

Archive for the ‘Best Practices’ Category

Organizing Terraform Projects

without comments

At Teckst, we use Terraform for all configuration and management of infrastructure.  The tidal boundary at the intersection of infrastructure and application configuration is largely determined by which kinds of applications will be deployed on which kinds of infrastructure.  Standing up a bunch of customized EC2 instances (e.g.Cassandra)?  Probably something that Ansible or Chef is better suited to as they’re built to step into a running instance and create and/or update its configuration (though, certainly, this can be done via Terraform and EC2 User Data scripts).

Teckst uses 100% AWS services and 100% Lambda for compute so we have a much more limited need.  We need Lambda Functions, API Gateways, SQS Queues, S3 Buckets, IAM Users, etc to be created and wired together; thereafter, our Lambda Function are uploaded by our CI system and run over the configured AWS resources.  In this case, Terraform is perfect for us as it walks our infrastructure right up to the line at which our Lambda Functions take over.

Terraform’s documentation provides little in the way of guidance on structuring larger Terraform projects.  The docs do talk about modules and outputs, but no fleshed-out examples are provided for how you should structure your project.  That said, many guides are available on the web ([1][2][3] are the top three Google results as of this writing).

Terraform Modules

Terraform Modules allow you to create modules of infrastructure which accept/require specific Variables and yield specific Outputs.  Besides being a great way to utilize third-party scripts (e.g. a script you find on Github to build a fully configured EC2 instance with Nginx fronting a Django application), Modules allow a clean, logical separation between environments (e.g. Production and Staging).  A good example of organizing a project using Terraform Modules is given in this blog post.  Initially, we approached organizing scripts similarly:

/prod/main.tf
/prod/vpc.tf - production configs for VPC module 
/staging/main.tf
/staging/vpc.tf - staging configs for VPC module
/modules/vpc/main.tf - contains staging configs for VPC module
/modules/vpc/variables.tf
/modules/vpc/outputs.tf

Now all of our prod configuration values are separate from our staging configuration values.  The prod and staging scripts could reference our generic vpc Module.  Initially, this seemed like a huge win.  Follow on to find out how it might not be a win for in-house-defined infrastructure.

Read the rest of this entry »

Written by alson

February 14th, 2018 at 11:26 am

Posted in Best Practices

Pretty URLs – how-tos & guides

without comments

Since we run a membership-fee-based service, we’ve focused on providing security for our inside-the-walled-garden URLs. It’s been important to protect the content generated by our members for our members from being scooped out by unscrupulous operators. That said, we’re probably getting to the point at which we should pretty up our URLs, if only to enhance our member experience and ease with which members can find their content.

In searching around for guidance on how to go about switching to pretty URLs, I’ve found the following helpful:

  • A Report on one company’s experience with switching to pretty URLs
  • An analysis of that report here.
  • A bunch of solid advice on how to think about pretty URLs.
  • Nuts & bolts about setting up Apache for URL rewriting.

Written by alson

September 10th, 2008 at 2:09 pm

Posted in Best Practices

Tagged with , , ,