`arm64` function support for `aws-lambda` deployments

[thiskevinwang]

Is your feature request related to a problem? Please describe.

(This feels like half feature request and half problem.)

I'm on an M1 Max macbook pro and running waypoint up

With 0 docker config, Waypoint appears to build an arm64 image

Image built: waypoint.local/waypoint-apollo-lambda:latest (arm64)

But Waypoint also appears to deploy a lambda function with a fixed x86_64 arch, regardless of the Docker image arch.

This is my waypoint.hcl

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" {
    }
  }
}

After deployment (and working around #2066), visiting the loadbalancer URL returns a 502 Bad Gateway.

Describe the solution you'd like

An option in the aws-lambda config, like platform

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

... and potentially a warning prompt if there is any arch mismatch between docker {} and aws-lambda {}

Describe alternatives you've considered

Alternative no. 1 — use amd64 Docker image

(This works in the build stanza, but is a compromise because the end result is an amd64 image on a x86_64 function)

  build {
    use "docker" {
      buildkit = true
      platform = "amd64"
    }

Alternative no. 2 — manually update lambda arch and additional follow up steps.

(This is closer to ideal — arm64 image on arm64 function — but there is manual clicking involved.)

1. [Lambda] Update arch to arm64 and find the proper arm64 ECR image
   
2. [Lambda] Publish new function version
3. [EC2] Find my loadbalancer; Find the listener's Target Group
4. [EC2] Deregister current Target
   This causes a temporary 503
5. [EC2] Register new Target
6. Wait for Loadbalancer to update
7. 👍

Explain any additional use-cases

• AWS Lambda Functions Powered by AWS Graviton2 Processor – Run Your Functions on Arm and Get Up to 34% Better Price Performance

Additional context

Here are some related logs for an arm64 image running on x86_64 function arch

2022-02-14T07:51:30.553-05:00	IMAGE Launch error: fork/exec /waypoint-entrypoint: exec format error Entrypoint: [/waypoint-entrypoint,/lambda-entrypoint.sh] Cmd: [index.handler] WorkingDir: [/var/task]
2022-02-14T07:51:30.604-05:00	START RequestId: 45e7e661-1c52-4654-bfbb-c69ae2237c5d Version: 26
2022-02-14T07:51:30.606-05:00	IMAGE Launch error: fork/exec /waypoint-entrypoint: exec format error Entrypoint: [/waypoint-entrypoint,/lambda-entrypoint.sh] Cmd: [index.handler] WorkingDir: [/var/task]
2022-02-14T07:51:30.607-05:00	END RequestId: 45e7e661-1c52-4654-bfbb-c69ae2237c5d
2022-02-14T07:51:30.607-05:00	REPORT RequestId: 45e7e661-1c52-4654-bfbb-c69ae2237c5d Duration: 1.69 ms Billed Duration: 2 ms Memory Size: 256 MB Max Memory Used: 3 MB
2022-02-14T07:51:30.607-05:00	RequestId: 45e7e661-1c52-4654-bfbb-c69ae2237c5d Error: fork/exec /waypoint-entrypoint: exec format error Runtime.InvalidEntrypoint
2022-02-14T07:51:30.760-05:00	START RequestId: 879bc157-fc05-42e3-985e-951bf7563ea6 Version: 26
2022-02-14T07:51:30.764-05:00	IMAGE Launch error: fork/exec /waypoint-entrypoint: exec format error Entrypoint: [/waypoint-entrypoint,/lambda-entrypoint.sh] Cmd: [index.handler] WorkingDir: [/var/task]
2022-02-14T07:51:30.765-05:00	END RequestId: 879bc157-fc05-42e3-985e-951bf7563ea6
2022-02-14T07:51:30.765-05:00	REPORT RequestId: 879bc157-fc05-42e3-985e-951bf7563ea6 Duration: 2.25 ms Billed Duration: 3 ms Memory Size: 256 MB Max Memory Used: 2 MB
2022-02-14T07:51:30.765-05:00	RequestId: 879bc157-fc05-42e3-985e-951bf7563ea6 Error: fork/exec /waypoint-entrypoint: exec format error Runtime.InvalidEntrypoint

[izaaklauer]

Hi @thiskevinwang,

Thanks for the report! In the short-term, we might just add an extra config variable to the lambda plugin, to allow you to specify arm.

Slightly longer term, we'll look into enriching the output of the build stage to expose the container architecture to downstream stages, which would enable the deploy stage to automatically set the correct architecture.

[thiskevinwang]

Nice! Also, I would love to work on this (the short-term approach) @izaaklauer