That's a fair point. I had been using .dev for this purpose for years, and just applied it to this project out of habit. It still doesn't fully resolve to anything from Google, but I see that ICANN is now resolving it to 127.0.53.53 to indicate a name collision. Many other projects (like Boxen) also use .dev, so it seems to still be something that people do.
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:
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 our developers expect to do.
What does setting the modified time of all files do?
As Devin said, we're using Mesos, Marathon, and Chronos, but we're pretty excited about Kubernetes too. The networking layer, in particular, seems very innovative.
Nice to see a post that covers the various aspects of using Docker in place of some like Vagrant for local development.
The biggest pain I've run into when using Docker for local dev is waiting for pip to install dependencies on rebuilds. This offers an interesting strategy for mitigating that and I look forward to digging into this more.
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.
For now, though, it's saved us from having to put everything directly into the image in development.
I'm not sure if this address your specific pain point, but if your issue is around building images, if you first COPY requirements.txt and then do `pip install` before COPYing the rest of your code into the image, Docker caching will actually cache that layer for you.
mathewpeterson|10 years ago
[1] https://www.iana.org/domains/root/db/dev.html
icebraining|10 years ago
silvamerica|10 years ago
tdkl|10 years ago
siliconc0w|10 years ago
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.com/siliconcow/d5c991f49b7550360465
silvamerica|10 years ago
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 our developers expect to do.
What does setting the modified time of all files do?
greenleafjacob|10 years ago
silvamerica|10 years ago
devinfoley|10 years ago
bndw|10 years ago
The biggest pain I've run into when using Docker for local dev is waiting for pip to install dependencies on rebuilds. This offers an interesting strategy for mitigating that and I look forward to digging into this more.
silvamerica|10 years ago
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.
For now, though, it's saved us from having to put everything directly into the image in development.
zenlikethat|10 years ago
wstrange|10 years ago
Link the to github project: https://github.com/IFTTT/dash