Jets Managed Dockerfile

The Jets Docker build process adds conveniences such as auto-detecting your web framework, building a managed Dockerfile, auto-tagging the image, and making sure the image is Lambda compatible.

Jets uses a multi-stage Docker build process to help keep the final deployment image small. Here is a simplified version of what the generated Dockerfile looks like:

Dockerfile

FROM ruby:3.2.3-slim as base
# ...
FROM base as build
RUN apt-get update && apt-get install -y build-essential
RUN bundle install
# ...

FROM base as deployment
RUN apt-get update && apt-get install -y curl
COPY --from=build /usr/local/bundle /usr/local/bundle
# ...

ENTRYPOINT [ "aws_lambda_ric" ]
CMD [ "handlers/controller.lambda_handler" ]

The Dockerfile is simplified to help understand. The managed Dockerfile is more complex and optimized. In the version above, you can see that Jets uses a multi-stage Docker build process. This keeps the final image size smaller for deployment.

Jets uses different Docker base images depending on the Lambda Package type:

• Image Package Type: Jets uses the official DockerHub Ruby image, IE: ruby:3.2.3-slim.
• Zip Package Type: Jets uses the official AWS Lambda Image, IE: public.ecr.aws/lambda/ruby:3.2

The Image Package Type is recommended and is the default. One reason for the default is that CloudFormation can only change package types by deleting and recreating the app. The default Image Package allows for large packages and is more flexible.

For the Zip Package Type, docker build is still used to gem dependencies, Jets create a Lambda Layer, and the final package is a zip.

Reference

The table below covers each setting. Each option is configured with config.OPTION. The config. portion is not shown for conciseness. IE: logger.level vs config.logger.level.

See Full Config Reference