Closed brunoocasali closed 3 years ago
I looked at this, and I can confirm there are cases where this makes docker-compose up
work (when running with a Gemfile
and Gemfile.lock
that have been modified after the last time the user ran docker-compose build
). So there is certainly some value to this approach.
I'm still trying to make sure there are no downsides, but it's difficult to find time to thoroughly test this. I'm trying to prioritize some other pull requests that impact the quality or features of the site itself, although this could be an improvement to the developer experience if it works well.
Particularly, I want to investigate if this has any chance of making docker-compose up
not work when it would have without this volume. (And to a lesser extent, I want to be sure this volume isn't likely to become extremely large on disk, though this seems unlikely and the size should be reasonable. Maybe even smaller than having multiple "throwaway" volumes from doing docker-compose run
, which are frequently created and then not used again.)
Hi @DeeDeeG I've created an image that shows what this PR does:
In the first terminal I've ran a down command just to clean up everything, then I open a docker-compose run, as you can see no volumes where created. In the second terminal, the same command was executed. And the last terminal I've check if there are multiple volumes but just one was found!
This kind of approach is nice because we can just ran a bundle install in any open terminal of the app and everything will work, without this every change we must to regenerate the docker image. Even if we ran multiple times the docker-compose up, everytime will ask about the gems, so you are obligated to regenerate :D.
About the size of the volume, excluding the possibility of the docker image having a better compression than the volume option, the size must be the same in both ;)
@brunoocasali I need to test whether the volume with the gems can be made inadequate to launch the server.
For example:
docker-compose build
docker-compose up
docker-compose up
/docker-compose run web [command]
?docker-compose build
docker-compose up
/docker-compose run web [command]
)I haven't gotten around to testing this yet, sorry. But I mean to test that first before merging this.
If step 6 that I described above gives errors, then this improves one scenario but makes another scenario worse, and I will have to weigh the benefits in one case against the regression in the other case.
Ah, okay. I just tested this...
The change in setup/entry
is a good idea. Much more flexible than what we had before. And takes good advantage of the caching this Pull Request adds.
The following output is what happened when I rebuilt with a newer Ruby version (docker-compose build
) and then ran an instance of bash in the container (docker-compose run --rm web bash
):
It mostly reused packages from the volume. It only had to reinstall gems that have native extensions. It works great. 👍
At first glance, the number of jobs for bundler seems high (bundle install --jobs=20
). But In practice, this did not seem to run slowly on my computer.
Overall, I can see that this doesn't cause any new situations where Docker can't start. And it properly ensures that docker-compose run
will pretty much always work. Also saves on network usage. I think this is worth merging.
Context
Summary of Changes
Checklist