Speed up Docker based builds by installing gems as a Docker layer

[jagthedrummer]

This PR implements the proposal from #58.

In my local test project this takes about 90 seconds off of the time for a full sls deploy (after the first deploy, and when the Gemfile and Gemfile.lock hasn't changed).

For apps that are already using a Dockerfile this will introduce a breaking change that will require updates to the Dockerfile.

A file that looked like this before:

FROM lambci/lambda:build-ruby2.5

RUN yum install -y postgresql-devel
RUN gem update bundler

CMD "/bin/bash"

Will need to be updated to look like this:

FROM lambci/lambda:build-ruby2.5

RUN yum install -y postgresql-devel
RUN gem update bundler

# Begin new stuff
RUN bundle config set --local path build
RUN bundle config set --local without test development

COPY Gemfile* .

RUN bundle install
# End new stuff

CMD "/bin/bash"

[navarasu]

@jagthedrummer Give me sometime. Let me release 1.6.0 by cleaning up gemfury related stuff and replacing 2.5 with 2.7 examples.

Regarding improving the performance of repeated work, I have other ideas like,

• Skip Repeated Deployment: It is not only building time even deploying layer is slower. So i planned to add skip deploy layer option
• Deploy only on any change Finally skip deploy if there is no change in gemfile.
• Alternatively we can also cache the gemlayer zip itself like in other serverless plugins

I like the caching docker idea but it does not support non docker use cases.

Assuming that most of them uses docker option, we can include this. But we need to see how to implement this without breaking existing use case.

After releasing the current version, I will come up with plan to add this without breaking exiting use case or implement no deploy option directly or both option with some config control Thanks

[zaguiini]

Would love to have this.

Maybe it is not the right place to say this, but I think we should drop non-Docker support because you're always going to be constrained by the Lambda environment anyways. And not having a way to specify a specific environment when downloading the gems locally so you can create the layer, makes it very easy to pick a different architecture or ruby version, hence allowing version mismatch between the local environment and the remote one. It's hell debugging that situation so I'm all for consistency. Thanks and let me know if this is not the right place to discuss that.