awslabs
Add adapter in Dockerfile and lunch it locally (or CI) for integration test
Hello everyone,
We need to run the adapter locally (or in CI) in order to run integration test.
Specifically the flow that we want to cover is apigateway invocation event -> web-adapter -> code
Specifically we want to test how the lambda receive the invocation message and how this is going to be handled by the adapter and the http framework below.
for example with a request like this
We are trying to test with the go-gin example
FROM golang:1.18-alpine AS build_base
RUN apk add --no-cache git
WORKDIR /tmp/gin
COPY . .
RUN go mod download
RUN GOOS=linux CGO_ENABLED=0 go build -o bootstrap .
FROM alpine:3.9
RUN apk add ca-certificates
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.1 /lambda-adapter /opt/extensions/lambda-adapter
COPY --from=build_base /tmp/gin/bootstrap /app/bootstrap
ENV PORT=8000 GIN_MODE=release
EXPOSE 8000
CMD ["/app/bootstrap"]
We are building the image as following and running with these commands
docker build -t gin-web-adapter-test:latest .
docker run -p 127.0.0.1:8080:8000 gin-web-adapter-test:latest
However we see that in this way we run directly the code and not the layer that should be used for converting the invocation to the http request.
Thank you for you support 👍
As I see the web-adapter extension defined here
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.1 /lambda-adapter /opt/extensions/lambda-adapter
is not executed locally since the execution of the extension is an internal lambda mechanism:
https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/
so how to run this in a CI/CD to run integration test? 🤔
Lambda Web Adapter is an external extension. Lambda service will automatically start it during function init.
You can use sam local start-api to simulate Lambda and API Gateway. It works in CI/CD as well.
HI @bnusunny thanks for the answer.
We don't use sam in our project. Is there a way to run the adapter in a docker container?
Our service tests are based on testcontainer. At the moment we are testing using the gin adapter that is deprecated and we are planning to move from zip to container and use this adapter. I'm not sure, is it correct testing http request instead that invocation in this scenario? is it the correct approach?
However, I see something similar have been attempted here (to run the layer locally)
https://github.com/awslabs/aws-lambda-web-adapter/issues/19
I'm not familiar with testcontainer. Give me some time to look into it.
You don't have to simulate the Lambda execution environment for local dev/test. Test the gin app normally gives you the best local development experience.
For integration testing in CI/CD pipeline, it makes sense to simulate the Lambda execution environment. But some customers prefer to test against the real cloud services. They deploy the applications as real Lambda functions and run tests with them.
Hi @bnusunny, it would be great if you can take a look into it 👍
at the moment I've tried this approach but still the adapter seems is not executed.
FROM golang:1.22-alpine AS build_base
RUN apk add --no-cache git
WORKDIR /tmp/gin
COPY . .
RUN go mod download
RUN GOOS=linux CGO_ENABLED=0 go build -o main .
FROM alpine:latest
RUN apk add --no-cache bash
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.2 /lambda-adapter /opt/extensions/lambda-adapter
ADD https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie /usr/bin/aws-lambda-rie
RUN chmod 755 /usr/bin/aws-lambda-rie
COPY ./entry.sh /
RUN chmod 755 /entry.sh
COPY --from=build_base /tmp/gin/main /main
ENV PORT=8081 READINESS_CHECK_PORT=8081 READINESS_CHECK_PATH=/ping
ENTRYPOINT ["/entry.sh"]
#!/bin/sh
# Start the first process
./main &
status=$?
if [ $status -ne 0 ]; then
echo "Failed to start my server: $status"
exit $status
fi
if [ -z "${AWS_LAMBDA_RUNTIME_API}" ]; then
exec /usr/bin/aws-lambda-rie "$@"
else
exec "$@"
fi
Plese let me know if you need any help with it!
