Developing with Docker at IFTTT

Post by davexunit » Wed, Oct 07, 2015, 7:41 PM UTC

emailgregn wrote: post #10

silvamerica wrote: post #7

Earlier quoted context omitted.

Thanks! We experienced that exact same pain. Whether it's pip or Bundler, I can't tell you how many times I've installed and reinstalled requirements. Sharing data volumes is kind of a hack to make it really easy to keep part of a container around when you delete and recreate a container. I would love to see persistent data volumes become first class citizens so you don't have to create a separate container for them.…

Install each of the pip/bundler requirements with a separate dockerfile RUN command. Each gets cached into its own container filesystem layer that way and only new requirements are pulled. Use your favourite templating tool to generate the dockerfile with multiple run commands. I wrote djtempl ( https://github.com/emailgregn/djtempl ) for my purposes.

Post by emailgregn » Wed, Oct 07, 2015, 7:51 PM UTC

davexunit wrote: post #11

emailgregn wrote: post #10

Earlier quoted context omitted.

Install each of the pip/bundler requirements with a separate dockerfile RUN command. Each gets cached into its own container filesystem layer that way and only new requirements are pulled. Use your favourite templating tool to generate the dockerfile with multiple run commands. I wrote djtempl ( https://github.com/emailgregn/djtempl ) for my purposes.

But let's say a dependency is changed. Won't modifying that RUN directive invalidate the cache for everything after it, potentially rebuilding a ton of stuff anyway?

Post by buss » Wed, Oct 07, 2015, 8:08 PM UTC

silvamerica wrote: post #9

siliconc0w wrote: post #8

Very cool, we use boot2docker and a slightly modified fork of docker compose but have yet to automate installing everything. To avoid reinstalling dependencies you can use multiple dependency files to separate your slowest building dependencies (i.e for ruby you can use a Gemfile and Gemfile.tip) and a git hook script to set the modified time of all files in the repo to their last change in git: https://gist.github.c…

Thanks! We looked at the approach of adding a Gemfile.tip, however we like the data volume approach because it doesn't require any changes to the Dockerfile and it is more like what our developers are familiar with. A Gemfile.tip can become basically another Gemfile eventually, so separating the bundle step from the build step (in Development) gives us more flexibility as well as keeping things more in line with what…

Post by silvamerica » Wed, Oct 07, 2015, 9:28 PM UTC

mathewpeterson wrote: post #12

It seems like using .dev TLD is a bad idea since Google owns it[1]. How many people use the .dev or .local TLD? What's the best practice here? [1] https://www.iana.org/domains/root/db/dev.html

Post by silvamerica » Wed, Oct 07, 2015, 9:33 PM UTC

buss wrote: post #15

silvamerica wrote: post #9

Earlier quoted context omitted.

Thanks! We looked at the approach of adding a Gemfile.tip, however we like the data volume approach because it doesn't require any changes to the Dockerfile and it is more like what our developers are familiar with. A Gemfile.tip can become basically another Gemfile eventually, so separating the bundle step from the build step (in Development) gives us more flexibility as well as keeping things more in line with what…

I'm a bit confused by your bundler-cache. It seems you must be running `bundle install` at runtime, because you can't mount that volume during build. Am I misunderstanding?