Daniel Maher phrawzty

What it is

Problem: Terraform doesn't play nicely with pre-existing infrastructure.

Solution: Officially there isn't one - but here's a work-around that does the trick.

Summary

Declare a new, temporary resource in your Terraform plan that is nearly identical to the extant resource.
Apply the plan, thus instantiating the temporary "twinned" resource and building a state file.

Managing multiple user accounts within the cloud-based Socorro infrastructure is a fool's errand; instead, the plan is use a single login (role acccount) with multiple accepted SSH keys (one per user). These keys are managed from the Source of Truth and implanted during the node provisioning step.

In order to keep track of things, however, it will be helpful to tag the public SSH keys with an identifier of the user that possesses the associated private key. Normally this is what the "comment" field is for:

ssh-rsa <big_ol_key> [comment]

The issue here is that the "comment" section isn't exported, announced, or otherwise relevent at all from a system perspective. Instead, I propose adding a small environment variable that does the job:

environment="SSH_KEY=happyuser" ssh-rsa <big_ol_key> [comment]

Roles and Types

There are a number of "roles" in the Socorro infra. The resource profiles for these roles are not identical, ergo there will be different AWS instance types for different roles.

The roles are:

Admin
Collectors
Crash-Analysis
Elasticsearch
Middleware

S3 as Yum repo

There are two parts to this:

Managing access to non-public S3 resources.
Building RPM repositories in an automated, deterministic way that Yum can use.

Environment

In general, a CentOS 7 x86_64 box in AWS EC2; in specific, this Packer profile.

AWS ELBs have a series of "policies" which group different HTTPS (read: TLS and SSL) profiles together. It is possible that the "2011-08" policy would be appropriate for this purpose (remains to be verified), otherwise we can define a custom policy that fits our needs. Unfortunately for us, these policies cannot currently be managed in Terraform, so this may end up be trickier than we'd first envisioned.

One possible workaround is to use local-exec to apply the policy manually, as suggested by t0m on IRC: http://paste.scsys.co.uk/488127

  provisioner "local-exec" {
    command = "aws elb create-load-balancer-policy --region ${var.region} --profile ${var.account} --load-balancer-name ${aws_elb.extelb.name} --policy-name EnableProxyProtocol --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=Tru

	(socorro-virtualenv)[vagrant@localhost ~]$ cat /etc/centos-release
	CentOS release 6.4 (Final)


	(socorro-virtualenv)[vagrant@localhost ~]$ sudo yum install centos-release-SCL
	[...]
	================================================================================
	Package Arch Version Repository Size
	================================================================================
	Installing:

	#!/usr/bin/env python2

	import SimpleHTTPServer
	import SocketServer
	import logging

	PORT = 8000

	class GetHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):

	variable "environment" {}
	variable "access_key" {}
	variable "secret_key" {}
	variable "secret_bucket" {}
	variable "subnets" {}
	variable "collector_cert" {
	default = {
	prod = ""
	stage = ""
	}

	#!/usr/bin/env bash

	set -e

	TFORM_VERSION="0.5.3_linux_amd64"

	gem install puppet puppet-lint
	puppet-lint --with-filename --no-80chars-check --no-autoloader_layout-check --fail-on-warnings puppet/
	puppet parser validate `find puppet/ -name '*.pp'`

	// See photo of whiteboard.

	digraph model {
	"Firefox" -> "CDN / Cloudfront";
	"Kinto Origin" [label="Kinto Origin (ELB & EC2)"];
	"CDN / Cloudfront" -> "Kinto Origin";
	"Kinto Origin" -> "Heka";
	"Kinto Origin" -> "PG" [label="RO"];
	"Kinto Admin" [label="Kinto Admin (EC2 & EIP)"];
	"Kinto Admin" -> "PG" [label="RW"];