Closed metaskills closed 1 year ago
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. https://github.com/customink/lamby-cookiecutter/commit/4945ed2ef3ccc276763aa43c32714bc4bb9251bc
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 matchingbin/_
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 afile/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:ENTRYPOINT
.CMD
toconfig/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:
app
user and/app
directory.bin/deploy
file.