silvamerica

Will there be an easy way to switch / upgrade from docker-machine with vbox without having to recreate all of my images and containers over again?

I know it's a small thing, but it's kind of a pain sometimes.

That looks like a great way to handle it!

Yes, I'm looking forward to it! It will still be a little ways off before we can use it with Compose, however.

That's correct. You build the image and then run (from inside a container) bundle install. This mapped well with our current flow, where you need to run bundle install after fetching new code anyway. This way, when you fetch new code, you don't need to rebuild the image and launch new containers, unless something changes in the Dockerfile or the docker-compose.yml file. That now happens fairly rarely, and, when it does, it's a pretty quick process.

You don't have to run it at runtime, however, as the data volume for a container sticks around until the container has been deleted. If you don't delete the bundler-cache container, your bundler cache sticks around. If you want to clear the cache, just remove the container.

It seems to me that .local is reserved for purposes within a local network, not necessarily local to an individual computer itself. You could, for example, set up an internal server on your network and have it resolve with storage.local. You could argue that a collection of containers is basically the same thing, though.

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.

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 our developers expect to do.

What does setting the modified time of all files do?

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.

For now, though, it's saved us from having to put everything directly into the image in development.

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.