Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lamby v4, Dev Containers, & More! #21

Merged
merged 24 commits into from
Dec 3, 2022
Merged

Lamby v4, Dev Containers, & More! #21

merged 24 commits into from
Dec 3, 2022

Conversation

metaskills
Copy link
Member

Official Ruby Containers

Switch to the official Ruby Images. Specifically the Debian Bullseye variant. We are doing this because AWS Lambda & SAM's Build base images only go to Ruby 2.7. Waiting for AWS to publish updated Amazon Linux 2 images or open source their building methods will likely never happen or in a timely manner. Thankfully the open-source Ruby Runtime Interface Client allows any container to be used and works just fine with Ruby 3.1.

Of note, Debian is also the base image for Microsoft/GitHub Dev Containers and hence Codespaces's features are all built on Debian as the primary base image. This will make using the same image easier for our dev container easier. Like how we used SAM's build image for dev, CI/CD.

Development Containers. No Docker-in-Docker (Sorta)

Prior to this change, we leveraged docker-compose via the AWS SAM build docker image as our development container. This caused us to work around Mac's file performance issues and rely on cross-platform patterns to allow SSH Agent forwarding on top of sharing AWS credentials with the development image. Cooking up unique docker compose patterns is not in our best interest and solved by Dev Containers and Codespaces.

This project leans into these technologies. The generated project's README covers how to use Codespaces which is freely available to everyone or how to use VS Code to run the dev container's locally. The GitHub Actions even use the Devcontainer CLI via the devcontainers/ci GitHub Action which builds the same dev container to run tests, build, and deploy your application with AWS CLI & SAM. This means we get to remove all the docker-compose run scripts which call their matching bin/_ counterparts.

Lamby v4

A lot has happened since Lamby was first released. Most notable is Lambda now supports OCI containers via the image package type. Though Lamby work for both zip and images, as well as any Ruby Rack application, Lamby v4 makes it really easy to install the gem and get up and running with a container. We no longer require a lengthy app.rb file as a command handler. Instead Lamby will leverage the Ruby Runtime Interface Client support to have a file/path.Class.method be your command handler. Combine this with Lamby's new default rack builder for your application we can now do the following:

  1. Bundle the Lamby gem.
  2. Install the RIC in your image. Set ENTRYPOINT.
  3. Set the CMD to config/environment.Lamby.cmd
FROM ruby:3.1-bullseye
RUN gem install 'aws_lambda_ric'
ENTRYPOINT [ "/usr/local/bundle/bin/aws_lambda_ric" ]
CMD ["config/environment.Lamby.cmd"]

Since Lamby auto detects if you are using Function URLs, API Gateway (HTTP or REST), or Application Load Balancer integrations, no other work needs to be done via our old app.rb file.

Crypteia

We have dropped promoting Dotenv and shipping .env.production files with secrets into your zip or container image. Instead we want to promote using Crypteia which transparently pulls SSM-backed secrets when your function initializes and injects them as native environment variables.

Function URLs

All Rails need for Lambda is a dumb proxy. API Gateway costs money. Function URLs are free. Default to using them.

Cookiecutter Usage

Update the Usage section in the README to leverage a lamby-cookiecutter which has been published to this repo using the cc-in-docker Dockerfile and build utility within this project repo as well.

Previously this was done with the sam command since it bundled the cookiecutter python package. This means we are using directly now. Maybe one day we will find a better project template system.

Miscellaneous

Will make comments below and call out any interesting points on top of these:

  • Remove puma from the final Gemfile in favor of Webrick for dev.
  • Promote the usage of a relational database. Picked MySQL. Could be any supported.
  • Cookiecutter's project will leverage the dev container's compose support for MySQL v8.
  • Production container creates a secure app user and /app directory.
  • Move ECR find or create CLI to the bin/deploy file.

@metaskills
Copy link
Member Author

This commit should have been part of the pull request. Reference it if you are looking to update your Rails CI/CD pipeline to be more like the latest cookiecutter. 4945ed2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant