Skip to content

Instantly share code, notes, and snippets.

View smithclay's full-sized avatar

Clay Smith smithclay

View GitHub Profile
@smithclay
smithclay / aws.tf
Created July 19, 2017 19:57
Multi-Cloud New Relic Blog Post: Terraform Configuration of AWS, Azure and GCP Load Balancers with Instance Groups (Autoscaling enabled)
variable "aws_region" {
description = "EC2 Region for the VPC"
default = "us-west-2"
}
variable "aws_availability_zones" {
default = "us-west-2a,us-west-2b,us-west-2c"
description = "List of availability zones, use AWS CLI to find your "
}
@smithclay
smithclay / weird-lambda-binaries-recipe.md
Created July 28, 2017 02:59
Recipe for Getting Strange Binaries Running in AWS Lambda

Recipe for running strange binaries in AWS Lambda

In general, the command ldd and the environment variable LD_LINKER_PATH is your best friend when running new, untested binaries in Lambda. My process (which I want to get around to automating one day, maybe using Packer), goes like this:

  1. Run an EC2 instance with the official AWS Lambda AMI.
  2. Get binary you want to run in AWS Lambda running on the instance (either by installing from a package manager or compiling). 
  3. Run ldd -v ./the-binary. Note all of the shared libraries it requires. You’ll need to remember these.
  4. Copy the binary to your local machine. Upload the binary with your AWS Lambda function code that runs the ldd command inside the handler function using the process execution library from your language of choice. In node, this works just fine: console.log(require('child_process').execSync('ldd -v ./the-binary'))
  5. Note any shared libraries that are missing in the function output. Copy those over from the EC2 instance to a direct
@smithclay
smithclay / faucet.txt
Created September 3, 2017 22:49
0xA81320fC784C52F757b79EB21Dd8206f59259C51
0xA81320fC784C52F757b79EB21Dd8206f59259C51
@smithclay
smithclay / rinkelby
Created October 16, 2017 03:41
rinkelby faucet
0xA81320fC784C52F757b79EB21Dd8206f59259C51