-
Notifications
You must be signed in to change notification settings - Fork 12
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
Proposal to speed up repeated Docker based deploys #58
Comments
Regarding improving the performance of repeated work, I have other ideas like,
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 |
The Problem
When deploying with Docker we end up installing all the gems from scratch each time, even if the
Gemfile
hasn't changed. On my smallish demo project thebundle install
step inside the running container takes about 90 seconds.Proposed solution
If we moved the
bundle install
step (and thebundle config set ...
steps) into theDockerfile
then we could take advantage of Docker layer caching and we'd only have to install gems when theGemfile
changes.I've tested a very crude version of this change and in my demo project a second full deploy (without changes to
Gemfile
) takes about 2 min 30 seconds compared to it taking about 4 minutes with the currently implemented approach.Complicating factors
Since we currently allow people to choose between using their own
Dockerfile
or an auto-generated one we'd need to handle both cases, and we'd have to require people to handle thebundle config
andbundle install
steps in their ownDockerfile
. That would be non-backwards-compatible breaking change, so we'd probably want to consider bumping theMAJOR
portion of the version number (bump to2.0.0
).Example Dockerfile
Here's an example
Dockerfile
that is currently working with my demo project (and my hacked up modification toserverless-ruby-layer
). The bits about creating and moving into/var/gem_build
are there to accommodate other parts of the existing implementation, but since the resulting image won't be distributed for production it may not be necessary to do things in that directory, and we might be able to use the default working directory of/var/task
just to keep things simple.And here's the output of a first build taking almost 2 minutes:
And the output of a second build taking less than 1 second:
Lingering questions
Maybe there's some reason that I'm not aware of that doing
bundle install
as aDockerfile
layer won't work, or is problematic? Are there advantages to doing it after the container is built instead of as part of the container build process?@navarasu If this sounds like an approach that you're open to investigating I'd be happy to submit a PR.
The text was updated successfully, but these errors were encountered: