silvamerica

5 ms·

1.
by silvamerica 11y ago
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.
2.
by silvamerica 11y ago
That looks like a great way to handle it!
3.
by silvamerica 11y ago
Yes, I'm looking forward to it! It will still be a little ways off before we can use it with Compose, however.
4.
by silvamerica 11y ago
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 co
5.
by silvamerica 11y ago
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. Yo
6.
by silvamerica 11y ago
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.
7.
by silvamerica 11y ago
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 b
8.
by silvamerica 11y ago
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
9.
by silvamerica 11y ago
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.