-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Fix multiple image builds when starting docker #760
Fix multiple image builds when starting docker #760
Conversation
The docker-compose setup includes a persistent volume intended to serve as a cache for bundler and rubygems. However, the volume mount contains a small error which is causing gems to be installed on the ephemeral filesyste - IE the gem cache is lost when a container exits. This means that every request to start an app container needs to re-install rubygems - and therefore re-run every step that comes after in the Dockerfile. This leads to longer than necessary wait times for the image to come up since the `bundle install` instruction of the Docerfile will never produce a cache-able layer. This fixes the path so that gems are stored on the persistent volume and significantly decreases the amount of time one needs to wait for app images and containers to become available.
In development, the app and webpacker services run in the same context. Instead of building an image for each service, we now build one image and share it - then let docker-compose figure out what to run, which ports to expose, etc. This uses Docker multi-stage builds to create the "base" image, then the app and webpacker services both use the "base" image as a starting point for their containers. References ---------- - https://docs.docker.com/develop/develop-images/multistage-build/
Looking great @indiebrain ! 💯 . I see its a draft PR; what's left to do? |
Thanks for the kind words, my friend.
I got to a sleepy Code Complete last night. Wanted to give it a once over with rested eyes before I subjected other human beings to it - specifically the PR write up; I tend to ramble, even more so when I'm sleepy. ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐳
Thanks, mate! |
Why
The current Docker-based development setup essentially does the same things multiple times to produce images for the
app
andwebpacker
services. The goal of this body of work is to produce images for these services and allow the to reuse existing, cached artifacts to prevent the build phase from doing unnecessary work.Pre-Merge Checklist
What
app
andwebpacker
servicesapp
andwebpacker
servicesHow
Share ruby gems cache between
app
andwebpacker
servicesThe docker-compose setup includes a persistent volume intended to serve as a cache for bundler and rubygems. However, the volume mount contains a small error which is causing gems to be installed on the ephemeral filesystem - IE the gem cache is lost when a container exits. This means that every request to start an app container needs to re-install rubygems - and therefore re-run every step that comes after in the Dockerfile. This leads to longer than necessary wait times for the image to come up since the
bundle install
instruction of the Docerfile will never produce a cache-able layer.This fixes the path so that gems are stored on the persistent volume and significantly decreases the amount of time one needs to wait for
app
/webapcker
images and containers to become available.Reuse cached Docker images layers between
app
andwebpacker
servicesIn development, the app and webpacker services run in the same context. Instead of building an image for each service, we now build one image and share it - then let docker-compose figure out what to run, which ports to expose, etc.
This uses Docker multi-stage builds to create the "base" image, then the
app
andwebpacker
services both use the "base" image as a starting point for their containers.Pre-build all local development images as part of the development environment setup
Instead of deferring image builds until the last possible moment, this changes theA separate body of work to address this problem was completed and merged intobin/dev/bootstrap
script to pre-build all locally produced images for development.main
as THIS body of work was still evolving. Instead, focus for this change set shifted to providing a small reorganization to the work done in #757.Testing
bin/dev/bootstrap
, one should see thatbundle install
is performed only once between theapp
andwebpacker
as they build their images.bin/dev/serve
notice that thedocker-compose up --build
step reuses layer caches for theapp
,webpacker
, andemail
services