|
| 1 | +# Ruby - Lambda Builder |
| 2 | + |
| 3 | +## Scope |
| 4 | + |
| 5 | +For the basic case, building the dependencies for a Ruby Lambda project is very easy: |
| 6 | + |
| 7 | +```shell |
| 8 | +# ensure you are using Ruby 2.5, for example with rbenv or rvm |
| 9 | +bundle install # if no Gemfile.lock is present |
| 10 | +bundle install --deployment |
| 11 | +zip -r source.zip * # technically handled by `sam package` |
| 12 | +``` |
| 13 | + |
| 14 | +The basic scope of a `sam build` script for Ruby would be as a shortcut for this, while performing some housekeeping steps: |
| 15 | + |
| 16 | +- Skipping the initial `bundle install` if a Gemfile.lock file is present. |
| 17 | +- Ensuring that `ruby --version` matches `/^ ruby 2\.5\./` |
| 18 | +- Raising a soft error if there is already a `.bundle` and `vendor/bundle` folder structure, and giving an option to clobber this if desired. |
| 19 | + - I don't want this to be a default behavior, in case users are using the `vendor` or `.bundle` folder structures for other things and clobbering it could have destructive and unintended side effects. |
| 20 | + |
| 21 | +Having a unified command also gives us the ability to solve once the most common issues and alternative use cases in a way that follows best practices: |
| 22 | + |
| 23 | +1. Including dependencies that have native extensions, and building them in the proper environment. |
| 24 | + - An open question is how to help users represent binary dependencies, but that's not a Ruby concern per se so it should be solved the same way across all builds. |
| 25 | +2. Building and deploying the user dependencies as a layer rather than as part of the code package. |
| 26 | + - These also have slightly different folder pathing: |
| 27 | + - Bundled dependencies are looked for in `/var/task/vendor/bundle/ruby/2.5.0` which is the default result of a `bundle install --deployment` followed by an upload. |
| 28 | + - Layer dependencies are looked for in `/opt/ruby/gems/2.5.0`, so for a layer option would have to use a `--path` build or transform the folder structure slightly. |
| 29 | +3. Down the road, perhaps providing a way to bundle code as a layer, such as for shared libraries that are not gems. These need to go in the `/opt/ruby/lib` folder structure. |
| 30 | + |
| 31 | +## Challenges |
| 32 | + |
| 33 | +- Ensuring that builds happen in Ruby 2.5.x only. |
| 34 | +- Ensuring that builds that include native extensions happen in the proper build environment. |
| 35 | + |
| 36 | +## Interface/Implementation |
| 37 | + |
| 38 | +Off hand, I envision the following commands as a starting point: |
| 39 | +- `sam build`: Shorthand for the 2-liner build at the top of the document. |
| 40 | +- `sam build --use-container`: Provides a build container for native extensions. |
| 41 | + |
| 42 | +I also envision Ruby tie-ins for layer commands following the same pattern. I don't yet have a mental model for how we should do shared library code as a layer, that may be an option that goes into `sam init` perhaps? Like `sam init --library-layer`? Layer implementations will be solved at a later date. |
| 43 | + |
| 44 | +Some other open issues include more complex Gemfiles, where a user might want to specify certain bundle groups to explicitly include or exclude. We could also build out ways to switch back and forth between deployment and no-deployment modes. |
| 45 | + |
| 46 | +### sam build |
| 47 | + |
| 48 | +First, validates that `ruby --version` matches a `ruby 2.5.x` pattern, and exits if not. When in doubt, container builds will not have this issue. |
| 49 | + |
| 50 | +```shell |
| 51 | +# exit with error if vendor/bundle and/or .bundle directory exists and is non-empty |
| 52 | +bundle install # if no Gemfile.lock is present |
| 53 | +bundle install --deployment |
| 54 | +``` |
| 55 | + |
| 56 | +This build could also include an optional cleanout of existing `vendor/bundle` and `.bundle` directories, via the `--clobber-bundle` command or similar. That would behave as follows: |
| 57 | + |
| 58 | +```shell |
| 59 | +rm -rf vendor/bundle* |
| 60 | +rm -rf .bundle* |
| 61 | +bundle install # if no Gemfile.lock is present |
| 62 | +bundle install --deployment |
| 63 | +``` |
| 64 | + |
| 65 | +### sam build --use-container |
| 66 | + |
| 67 | +This command would use some sort of container, such as `lambci/lambda:build-ruby2.5`. |
| 68 | + |
| 69 | +```shell |
| 70 | +# exit with error if vendor/bundle and/or .bundle directory exists and is non-empty |
| 71 | +bundle install # if no Gemfile.lock is present |
| 72 | +docker run -v `pwd`:`pwd` -w `pwd` -i -t $CONTAINER_ID bundle install --deployment |
| 73 | +``` |
| 74 | + |
| 75 | +This approach does not need to validate the version of Ruby being used, as the container would use Ruby 2.5. |
| 76 | + |
| 77 | +This build could also include an optional cleanout of existing `vendor/bundle` and `.bundle` directories, via the `--clobber-bundle` command or similar. That would behave as follows: |
| 78 | + |
| 79 | +```shell |
| 80 | +rm -rf vendor/bundle* |
| 81 | +rm -rf .bundle* |
| 82 | +bundle install # if no Gemfile.lock is present |
| 83 | +docker run -v `pwd`:`pwd` -w `pwd` -i -t $CONTAINER_ID bundle install --deployment |
| 84 | +``` |
0 commit comments