Deploying a GraphQL Docker Container to AWS Lambda with Waypoint

Just want a TL;DR? I used waypoint to build, deploy, and release a containerized GraphQL server to Lambda. waypoint builds the image with Docker, publishes it to ECR, and points an ALB at the lambda function.

Just here to see some code? Skip ahead ↓

---

Changelog:

• February 23, 2022: Added links to #3032 and #3035 under Final thoughts

Backstory

When I hear about new tech that piques my interest or old patterns that are simply new to me, I take note and add them to my list of things to try out. However, this list has grown large and I have a bad habit of not actually getting around to many of those things, because you know... work, life, and everything else.

Somedays I do get lucky and am blessed with a streak of diligence, discipline, or just that one thing that helps triggers the domino effect in checking items off.

express.js inside lambda

Ever since listening to “JavaScript Deployments” (March 2020) and learning that you can put an express.js app inside a lambda function, I’ve been curious about exactly what that looked like... I just never got around to figuring it out for myself.

Docker container inside lambda

Ever since AWS announced container image support for Lambda back in December 2020, I’ve been curious about it as well, but never got around to using it since Docker wasn’t really a tool that I used regularly.

My method to date for deploying something to lambda has been using the aws-cdk-lib/aws_lambda_nodejs package, which uploads some compiled JavaScript to a Node.js lambda function. But this is still just JavaScript and not a containerized app.

Beyond terraform...

And... Ever since joining HashiCorp in August 2021, I’ve telling myself to go learn more about all the core products. Terraform has been the only product I’ve really used and not even very in-depth. I don’t have significant infrastructure needs, and when I have, the AWS TypeScript CDK has been both sufficient as well as educational with its compiler hinting and documentation support.

The tipping point — waypoint

A week ago, I decided to hunker down and see how far I could get with trying out waypoint.

Waypoint allows developers to deploy, manage, and observe their applications through a consistent abstraction of underlying infrastructure. Waypoint works with Kubernetes, ECS and many other platforms.

I referenced the AWS Lambda Tutorial, worked around some hiccups (like image and function architecture mismatch ¹) and to my surprise, I ended up ticking off the previous 3 items on my todo list. Thank you, waypoint!

The following section is essentially the whole project.

The code

The amount of code needed to get this project up and running is pretty light.

Containerized Application

The secret to running express.js on lambda is @vendia/serverless-express, which handles the mapping of a few supported AWS event objects (API Gateway, ALB, and Lambda@Edge) to and from the express.js Request and Response objects.

The GraphQL portion is handled by apollo-server-lambda, which simply wraps @vendia/serverless-express.

# from an empty dir
npm init -y
touch Dockerfile index.js waypoint.hcl
echo node_modules >> .gitignore
npm i apollo-server-lambda apollo-server-core apollo-datasource-rest

Dockerfile

It’s worth noting the special /var/task directory, which is where Lambda expects container code to exist, by default. ²

###########
# Builder #
###########
FROM public.ecr.aws/lambda/nodejs:14 as BUILDER

WORKDIR /var/task
COPY index.js package*.json ./

RUN npm install npm@latest -g
RUN npm install
RUN npm prune --production

###########
# Runtime #
###########
FROM public.ecr.aws/lambda/nodejs:14

WORKDIR /var/task
COPY --from=BUILDER /var/task ./

CMD [ "index.handler" ]

Application code

This is a minimal GraphQL server implementation, with one RESTDataSource to prove out external data fetching.

const { ApolloServer, gql } = require("apollo-server-lambda");
const {
  ApolloServerPluginLandingPageGraphQLPlayground,
} = require("apollo-server-core");
const { RESTDataSource } = require("apollo-datasource-rest");

class HealthCheckAPI extends RESTDataSource {
  constructor() {
    super();
    this.baseURL = "https://thekevinwang.com/api/health";
  }

  async getHealth() {
    return this.get(`/`);
  }
}

const typeDefs = gql`
  type HealthCheckResponse {
    message: String
  }

  type Echo {
    message: String!
    echo(message: String): Echo!
  }

  type Query {
    getHealthCheck: HealthCheckResponse!
    echo(message: String!): Echo!
  }
`;

const resolvers = {
  Echo: {
    echo: (parent, args, { dataSources }, info) => {
      const parentMessage = parent.message;
      const { message } = args;

      if (message) {
        return { message };
      } else {
        return { message: parentMessage };
      }
    },
  },
  Query: {
    echo: (parent, args, context, info) => {
      const { message } = args;
      return { message };
    },
    async getHealthCheck(parent, args, { dataSources }, info) {
      const { healthCheckAPI } = dataSources;
      const res = await healthCheckAPI.getHealth();

      return {
        message: res,
      };
    },
  },
};

const server = new ApolloServer({
  typeDefs: typeDefs,
  resolvers: resolvers,
  introspection: true,
  dataSources: () => ({
    healthCheckAPI: new HealthCheckAPI(),
  }),
  plugins: [ApolloServerPluginLandingPageGraphQLPlayground],
});

exports.handler = server.createHandler();

waypoint.hcl

waypoint, similar to terraform, uses HCL to define the resources you want.

The highlighted lines were required for me since I’m using an M1 Macbook. ¹

project = "waypoint-apollo-lambda"

app "waypoint-apollo-lambda" {
  build {
    use "docker" {
      buildkit = true
      platform = "amd64"
    }

    registry {
      use "aws-ecr" {
        region     = "us-east-1"
        repository = "waypoint-apollo-lambda"
        tag = gitrefpretty()
      }
    }
  }

  deploy {
    use "aws-lambda" {
      region = "us-east-1"
      memory = 256
    }
  }

  release {
    use "aws-alb" {
      # default
      // port = 80

      # optional
      // port = 443
      // certificate = <certificate-arn>
      // domain_name = <domain-name-that-you-own>
    }
  }
}

Deploying

Deploying was more or less simple.

I did go down some rabbit holes afterwards:

• How to resolve a DuplicateListener error ³
• How to enable HTTPS on an Application Load Balancer

Install waypoint v0.7.1

brew tap hashicorp/tap
brew install hashicorp/tap/waypoint

Run the Waypoint server and run waypoint up

waypoint install -platform=docker -accept-tos
waypoint up

Waypoint should output a load balancer URL which is where the public can view the containerized app. It takes a few minutes for a brand new load balancer to be fully provisioned.

After doing some additional digging into Target Groups, Security Groups, SSL Certificates, I was able to add a pretty URL to the waypoint deployment. (I’ll try write about this endeavor in another blog post.)

...This URL may or may not work as I may tear down the deployment in the future.

Grok’ing the infrastructure

Here’s a brain dump of notes I took on the infrastucture that Waypoint created.

ECR

Waypoint builds a Docker image, and publishes it to your image registry.

Lambda

Waypoint creates or publishes a new lambda function version that uses the previous image.

EC2

Waypoint creates...

• a Security Group with a default inbound rule, like “allow all traffic on port 80”.
• a Target Group that targets the previously created lambda function.
• an Application Load Balancer in some VPC (?) and the previously created security group.
• a Listener on port 80 that forwards traffic to the previously created Target Group.

Final thoughts

Waypoint is slick but has tons of room for polishing. As a developer, I feel like Waypoint resonates with me. I like being hands-on (...mostly) with every part of my stack, especially the cloud infrastructure portion. So I appreciate that Waypoint doesn’t rely on a 3rd party platform or abstraction over AWS, GCP, Azure, etc. — it’s still just you and your cloud infra.

I’ve been building and running Waypoint from source to get a feel for the codebase, as well its general architecture.

I’m also hoping to chip away at the following issue on my free time I opened a pull request, #3032, for: arm64 function support for aws-lambda deployments #3026,

I’ve written a go-script to workaround I opened another pull request, #3035, for another existing issue: Lambda DuplicateListener error when releasing a 2nd time #2066.

package main

import (
	"context"
	"encoding/json"
	"log"
	"strings"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	elbv2 "github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2"
	elbv2types "github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2/types"
)

const (
	// LoadBalancerArn; This is provisioned by Waypoint
	LoadBalancerArn = "arn:aws:elasticloadbalancing:us-east-1:058050752201:loadbalancer/app/waypoint-waypoint-apollo-lambda/16233bf7c89d48b1"
)

func main() {
	// Using the SDK's default configuration, loading additional config
	// and credentials values from the environment variables, shared
	// credentials, and shared configuration files
	cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion("us-east-1"))
	if err != nil {
		log.Fatalf("unable to load SDK config, %v", err)
	}

	elbService := elbv2.NewFromConfig(cfg)

	// Describe listeners on our load balancer to grab the ARN of the 443 listener
	resp3, _ := elbService.DescribeListeners(context.TODO(), &elbv2.DescribeListenersInput{
		LoadBalancerArn: aws.String(LoadBalancerArn),
	})

	var listenerToModifyArn *string
	for _, l := range resp3.Listeners {
		// I have a listener on port 443, I'll use that one
		if *l.Port == 443 {
			listenerToModifyArn = l.ListenerArn
		}
	}

	// Modify the listener to use the new Lambda function version
	elbService.ModifyListener(context.TODO(), &elbv2.ModifyListenerInput{
		ListenerArn:    listenerToModifyArn,
		DefaultActions: []elbv2types.Action{},
	})

	// LIST ALL TARGET GROUPS
	// 💭 Are these sorted by created time?
	// It seems like we'd need to list all target groups, in order to find
	// a waypoint-created one, that wasn't able to be attached to a listener
	targetGroupsResponse, _ := elbService.DescribeTargetGroups(context.TODO(), &elbv2.DescribeTargetGroupsInput{
		Names: []string{},
	})

	// get all our target groups for our app, filter by name
	appTargetGroups := []elbv2types.TargetGroup{}
	for _, tg := range targetGroupsResponse.TargetGroups {
		if strings.Contains(*tg.TargetGroupName, "waypoint-apollo-lambda") {
			appTargetGroups = append(appTargetGroups, tg)
		}
	}

	// Find the final Target Group that was created by Waypoint and check if it
	// has an associated Load Balancer
	// If it does not, then attach it via the Listener
	for i, tg := range appTargetGroups {
		if len(tg.LoadBalancerArns) == 0 && i == len(appTargetGroups)-1 {
			if res, err := elbService.ModifyListener(context.TODO(), &elbv2.ModifyListenerInput{
				ListenerArn: listenerToModifyArn,
				DefaultActions: []elbv2types.Action{
					{Type: "forward", TargetGroupArn: tg.TargetGroupArn},
				},
			}); err != nil {
				log.Fatal(err)
			} else {
				buf, _ := json.Marshal(res)
				log.Printf("✅ ModifyListener: %+v\n", string(buf))
			}
		}
	}
}